e7500 and ich2rom

[Ronald G Minnich]

some output from printks I added:

init_ich2rom Found: 0x8086 0x2480
ich2rom: set 0x4e to 0x1
ich2rom: val 0x4e IS NOW  0x1
ioremap 0xff000000 size 0x1000000 result 0xf886d000

it finds the part
it sets the 0x4e register to 1 for enabling write
    hey! same register as the piix4e -- think this is a coincidence?
it does the ioremap of the last (BIG) 16 MB of memory (WOW!)
Then it does a JEDEC probe.

Do JEDEC probes really work with this 82802AB part?

They must have but ... Eric?

ron

[steven james]

Greetings,

I've been playing with this as well. Depending on the motherboard,
etc. the full size of the flash may not be mapped in.

It's probably worthwhile to look around in user space using /dev/mem to
try to find the actual size of the mapped in portion. The flash part will
respond to a JEDIC probe.

G'day,
sjames

On Thu, 5 Sep 2002, Ronald G Minnich wrote:
> some output from printks I added:
>
> init_ich2rom Found: 0x8086 0x2480
> ich2rom: set 0x4e to 0x1
> ich2rom: val 0x4e IS NOW  0x1
> ioremap 0xff000000 size 0x1000000 result 0xf886d000
>
> it finds the part
> it sets the 0x4e register to 1 for enabling write
>    hey! same register as the piix4e -- think this is a coincidence?
> it does the ioremap of the last (BIG) 16 MB of memory (WOW!)
> Then it does a JEDEC probe.
>
> Do JEDEC probes really work with this 82802AB part?
>
> They must have but ... Eric?
>
> ron
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

stpc-consumerII

[Steve M. Gehlbach]

Ron:

I have added the stpc consumer II chip and ST evaluation motherboard to the
linuxbios source and propose to add it to the repository.  The added code
supports a video console and sets up the integrated vga into alpha mode
(BIOS mode 3).  The graphics mode is not supported (yet anyway).

Remaining to be done is the pirq routing; I am not clear on how this is done
in linuxbios.  Maybe someone can point me in the right direction.  I know
how to do it for the stpc cpu/integrated bridge, but I don't understand how
this is connected to the data structures of linux bios.

Also remaining to be dealt with is the mtd device on the mobo. Right now it
boots 2.2.21 fine from a floppy ( I changed the floppy code to read a track
at a time; way too slow the way it was.)

The following files/directories are proposd to be added:

freebios/src/cpu/stpc/consumer2/Config
freebios/src/cpu/stpc/consumer2/stpc_cache.inc
freebios/src/cpu/stpc/consumer2/stpc_chip.inc
freebios/src/cpu/stpc/consumer2/stpc_framebuffer.inc
freebios/src/cpu/stpc/consumer2/stpc_ioinit.inc
freebios/src/cpu/stpc/consumer2/stpc_memsize.inc
freebios/src/cpu/stpc/consumer2/stpc_ram_init.inc
freebios/src/cpu/stpc/consumer2/stpc_vga.c

freebios/src/include/cpu/stpc/consumer2/stpc.h
freebios/src/include/cpu/stpc/consumer2/vga_stpc.h

freebios/src/include/pc80/vga.h

freebios/src/mainboard/stpc/consumer2/Config
freebios/src/mainboard/stpc/consumer2/mainboard.c

freebios/src/northsouthbridge/stpc/consumer2/Config
freebios/src/northsouthbridge/stpc/consumer2/nsbridge.c

freebios/src/pc80/vga_load_regs.c
freebios/src/pc80/beep.c
freebios/src/pc80/font_8x16.c

freebios/src/superio/SMC/fdc37b78x/setup_serial.inc
freebios/src/superio/SMC/fdc37b78x/superio.c

freebios/util/config/stpc.config

The following files were modified:

RCS file: /cvsroot/freebios/freebios/src/arch/i386/lib/params.c,v
RCS file: /cvsroot/freebios/freebios/src/lib/floppy_subr.c,v
RCS file: /cvsroot/freebios/freebios/src/lib/linuxbiosmain.c,v
RCS file: /cvsroot/freebios/freebios/src/lib/video_subr.c,v
RCS file: /cvsroot/freebios/freebios/src/pc80/Config,v
RCS file: /cvsroot/freebios/freebios/src/rom/floppy_fill_inbuf.c,v

A config option was added:  VGA_HARDWARE_FIXUP.

Let me know if you want to add this to the project, and the best way to get
the files to you.  Would it be better to wait until the mtd and pirq are
working?

-Steve Gehlbach

stpc-consumerII

[Ronald G Minnich]

for PIRQ, you run the program in freebios/util called getpir, which writes
a file called irq_tables.c. You have to run this on the standard bios.

Copy that file into the mainboard directory. In the mainboard Config file
add the line:
option HAVE_PIRQ_TABLE=1

and you should be fine.

Try to make this go before we commit. To commit, send my a unified diff of
your tree against the HEAD branch. I'll run patch and commit it.

ron

stpc-consumerII

[Hamish Guthrie (Mail Lists)]

Steve,

I have done a lot of work for LinuxBIOS with all of the STPC devices and am
in fact just waiting for the latest cloud of changes to filter through, and
for Ron to tell me things are relatively stable before comitting. What I
have been working on is a generic STPC support (there are now about 9
devices in the STPC family), which basically provides a small layer which
virtualises any STPC device (after initialising super-I/O's or built-in
devices to the same level) with a final jump vector in protected mode to
LinxBIOS code.

This little filter layer is accomplished in a maximum of about 4k of binary
code and includes pre-initialisation of the PCI stuff, so a PCI routing
table is not required.

Your inputs though are really welcome, maybe we should pool our efforts!

Regards

Hamish
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Steve M. Gehlbach
> Sent: 06 September 2002 05:25
> To: [e-mail]
> Cc: [e-mail]
> Subject: stpc-consumerII
>
> Ron:
>
> I have added the stpc consumer II chip and ST evaluation
> motherboard to the
> linuxbios source and propose to add it to the repository.  The added code
> supports a video console and sets up the integrated vga into alpha mode
> (BIOS mode 3).  The graphics mode is not supported (yet anyway).
>
> Remaining to be done is the pirq routing; I am not clear on how
> this is done
> in linuxbios.  Maybe someone can point me in the right direction.  I know
> how to do it for the stpc cpu/integrated bridge, but I don't
> understand how
> this is connected to the data structures of linux bios.
>
> Also remaining to be dealt with is the mtd device on the mobo.
> Right now it
> boots 2.2.21 fine from a floppy ( I changed the floppy code to
> read a track
> at a time; way too slow the way it was.)
>
> The following files/directories are proposd to be added:
>
> freebios/src/cpu/stpc/consumer2/Config
> freebios/src/cpu/stpc/consumer2/stpc_cache.inc
> freebios/src/cpu/stpc/consumer2/stpc_chip.inc
> freebios/src/cpu/stpc/consumer2/stpc_framebuffer.inc
> freebios/src/cpu/stpc/consumer2/stpc_ioinit.inc
> freebios/src/cpu/stpc/consumer2/stpc_memsize.inc
> freebios/src/cpu/stpc/consumer2/stpc_ram_init.inc
> freebios/src/cpu/stpc/consumer2/stpc_vga.c
>
> freebios/src/include/cpu/stpc/consumer2/stpc.h
> freebios/src/include/cpu/stpc/consumer2/vga_stpc.h
>
> freebios/src/include/pc80/vga.h
>
> freebios/src/mainboard/stpc/consumer2/Config
> freebios/src/mainboard/stpc/consumer2/mainboard.c
>
> freebios/src/northsouthbridge/stpc/consumer2/Config
> freebios/src/northsouthbridge/stpc/consumer2/nsbridge.c
>
> freebios/src/pc80/vga_load_regs.c
> freebios/src/pc80/beep.c
> freebios/src/pc80/font_8x16.c
>
> freebios/src/superio/SMC/fdc37b78x/setup_serial.inc
> freebios/src/superio/SMC/fdc37b78x/superio.c
>
> freebios/util/config/stpc.config
>
> The following files were modified:
>
> RCS file: /cvsroot/freebios/freebios/src/arch/i386/lib/params.c,v
> RCS file: /cvsroot/freebios/freebios/src/lib/floppy_subr.c,v
> RCS file: /cvsroot/freebios/freebios/src/lib/linuxbiosmain.c,v
> RCS file: /cvsroot/freebios/freebios/src/lib/video_subr.c,v
> RCS file: /cvsroot/freebios/freebios/src/pc80/Config,v
> RCS file: /cvsroot/freebios/freebios/src/rom/floppy_fill_inbuf.c,v
>
> A config option was added:  VGA_HARDWARE_FIXUP.
>
> Let me know if you want to add this to the project, and the best
> way to get
> the files to you.  Would it be better to wait until the mtd and pirq are
> working?
>
> -Steve Gehlbach
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

stpc-consumerII

[Ronald G Minnich]

steve and hamish, do you want to resolve on what patch we need and send it
in?

I think this is a stable time to apply a patch.

ron

stpc-consumerII

[Steve M. Gehlbach]

Hamish:

Part of my reasoning in posting an intro was to find out just what was going
on.  I half expected to get a reply that it was already done, here's the
link, etc...  But I would be happy to co-ordinate in any way that makes
sense.  I suspect you have done a much more careful job that I, but my main
interest was a video console, which does not seem to be a focus of the
linuxbios project due to its prime interest in large clusters.  My prime
interest is in custom motherboards for embedded systems, and for my project,
alpha vga is essential.  The VGA (IMHO) is the hard part. Most of the code
was lifted and massaged from ST and from and the original stpc/freebios
archive, and the linux vga console drivers.  My stpc implementation puts the
stack of code in assy language after protected mode, e.g., Config
(mainboard):

arch i386
mainboardinit cpu/i386/entry16.inc
mainboardinit cpu/i386/entry32.inc
ldscript cpu/i386/entry16.lds
ldscript cpu/i386/entry32.lds
mainboardinit cpu/i386/reset16.inc
ldscript cpu/i386/reset16.lds

mainboardinit cpu/stpc/consumer2/stpc_chip.inc
mainboardinit cpu/stpc/consumer2/stpc_ram_init.inc

option SMC_BASE=0x370
mainboardinit superio/SMC/fdc37b78x/setup_serial.inc

mainboardinit pc80/serial.inc
mainboardinit arch/i386/lib/console.inc

mainboardinit cpu/stpc/consumer2/stpc_ioinit.inc
mainboardinit cpu/stpc/consumer2/stpc_memsize.inc
mainboardinit cpu/stpc/consumer2/stpc_framebuffer.inc
mainboardinit cpu/stpc/consumer2/stpc_cache.inc

# this links in stpc vga through displayinit() and VIDEO_CONSOLE option
option VGA_HARDWARE_FIXUP=1

northsouthbridge stpc/consumer2

nsuperio SMC/fdc37b78x com1={1} floppy=1  lpt=1 keyboard=1

cpu stpc/consumer2

object mainboard.o
-----------

Not sure of the best way to go about it, but obviously two different
approaches pulling at each other in the archive is not good.  In fact, it
may be that it is best for me to hang on to what I have and let you go ahead
since you have been working on it for some time, and my implementation is
restricted to the consumerII only.  Or I could send you a tarball of my
source tree.  I do think it is important to get something in the archive in
the near term so others can benefit, rather than waiting until it is perfect
(my philosophy anyway).

Any approach that makes sense is fine to me.  I just wanted to make sure I
contributed what I had in the event someone was interested.

-Steve
> I have done a lot of work for LinuxBIOS with all of the STPC
> devices and am
> in fact just waiting for the latest cloud of changes to filter
> through, and
> for Ron to tell me things are relatively stable before comitting. What I
> have been working on is a generic STPC support (there are now about 9
> devices in the STPC family), which basically provides a small layer which
> virtualises any STPC device (after initialising super-I/O's or built-in
> devices to the same level) with a final jump vector in protected mode to
> LinxBIOS code.
>
> This little filter layer is accomplished in a maximum of about 4k
> of binary
> code and includes pre-initialisation of the PCI stuff, so a PCI routing
> table is not required.
>
> Your inputs though are really welcome, maybe we should pool our efforts!
>
> Regards
>
> Hamish

stpc-consumerII

[Ronald G Minnich]

one thing --- we'd rather have it sooner now with imperfections -- Steve,
I thought your changes looked really good.

ron

stpc-consumerII

[Steve M. Gehlbach]

> one thing --- we'd rather have it sooner now with imperfections -- Steve,
> I thought your changes looked really good.
>
> ron

I tend to agree with "release it early and often" as long as it doesn't
break other working code.

If Hamish supports all stpc chips with an assy language .inc stack at the
head, that could work fine with my vga code, though.  Supporting all of the
stpc chips is very tedious, a real "ifdef" hell.  I am assuming the vga is
not setup in his code, but that may not be true. It also may be true that
his code could co-exist with mine fine, if it is simply an assy stack at the
head.  Not sure if we want to do this or not, though.

I guess the keeper of the archive gets to make the decision; I have no axes
to grind either way.  The big defficiency in my code is that it is
restricted to consumerII.

Hamish and I can exchange thoughts and work to a join agreement, I guess. In
the meantime, I will motor ahead.  If I get to the point that I am ready to
send it to you prior to a consensus, I will do that and maybe you can make a
judgement at that point.

-Steve