I'm thinking about trying coreboot on the Compaq Evo T20 thin client. This is a Geode GX1 machine with CS5530 companion chip and National Semiconductor DP83815 ethernet card. It has 48MB of flash memory and 64 MB of RAM (soldered). The superiotool from coreboot can't find any evidence of super-I/O. The mainboard contains a chip that looks like a socketed PLCC BIOS chip, Winbond 29C020... with a sticker on top giving credit to Wyse Tech 01'V9.0. The keyboard and mouse use a USB 1.1 interface. `lspci` says 00:13.0 USB Controller: Compaq ... ZFMicro Chipset USB (rev 06)
Expert advice on these questions would be very welcome:
1. Does coreboot support this setup? (Particularly the USB devices?)
2. What advantages will coreboot offer over the manufacturer's original BIOS? E.g., will I get a BIOS control screen I can use to change settings until they work?
3. I don't have too much time to indulge in hardware hacking. I'm hoping for an approach that would not require me to even open the Evo's case! And this might be possible: like the Wyse Winterm, the Evo boots from on-board flash memory that can be rewritten using 'netxfer'. One of the files that netxfer delivers to the thin client is called "the BIOS" by people who know these things. Tradition among users like me is to treat that file with great respect, making sure an exact copy of the factory original is present whenever other files in the bundle are replaced. Here's my main question: can I replace that file (named ulc_code.ce, size 4 MB) with something from coreboot and use 'netxfer' to get a working alternative to the factory BIOS? What can I test before trying this to make sure I don't turn my little device into a brick? Are there some magic bytes or signatures to look for in the factory-file to confirm that it really is some kind of BIOS, and that program execution starts from the same location in the commercial file as it will in coreboot? What else should I be watching for?
Thanks in advance for any comments or pointers.
Philip
Hi,
On Mon, May 12, 2008 at 11:00:33AM -0700, Philip Loewen wrote:
I'm thinking about trying coreboot on the Compaq Evo T20 thin client.
Yep, nice box. I have one here, too, will port coreboot to it soonish.
This is a Geode GX1 machine with CS5530 companion chip and National Semiconductor DP83815 ethernet card. It has 48MB of flash memory
And/or on the SmartMedia card? At least there's such a socket and a card inserted on my T20.
and 64 MB of RAM (soldered).
Plus an SODIMM slot.
The superiotool from coreboot can't find any evidence of super-I/O.
Indeed, from a quick look I can't spot one on the board either (I opened the case), which is possible as this is a "legacy-free" board (sort of), no PS/2 keyboard etc... So maybe it's just not needed and there is indeed no Super I/O here, will investigate.
The mainboard contains a chip that looks like a socketed PLCC BIOS chip, Winbond 29C020... with
Yep, correct.
a sticker on top giving credit to Wyse Tech 01'V9.0. The keyboard and mouse use a USB 1.1 interface. `lspci` says 00:13.0 USB Controller: Compaq ... ZFMicro Chipset USB (rev 06)
Expert advice on these questions would be very welcome:
- Does coreboot support this setup? (Particularly the USB
devices?)
Mostly, yes. There's no specific board target in svn for this machine yet, but I can provide a patch soonish, as I have one of those boxes here and can test.
The chipset code (northbridge + southbridge) is supported by coreboot.
The main problem will be that there's no legacy PS/2 keyboard and serial port, i.e. debugging will be a bit harder than usual, and the keyboard might not work in FILO (a small bootloader we often use with coreboot). We'll see.
- What advantages will coreboot offer over the
manufacturer's original BIOS?
Various, depends on what your goals are. All the coreboot code is open-source would be one good advantage. Likely faster boot times can be expected usually, too, etc. etc.
E.g., will I get a BIOS control screen I can use to change settings until they work?
Not the kind of menu you're used to from proprietary BIOSes, at least not yet. There are various payloads you can use with coreboot, see http://www.coreboot.org/Payloads.
- I don't have too much time to indulge in hardware
hacking. I'm hoping for an approach that would not require me to even open the Evo's case!
_Might_ be possible, I can test this for you, I don't mind opening the box. But if something goes wrong you really want to replace the BIOS chip (not a problem, as it's in a socket) with a backup chip which you have created/tested _before_.
And this might be possible: like the Wyse Winterm, the Evo boots from on-board flash memory that can be rewritten using 'netxfer'. One of the files that netxfer delivers to the thin client is called "the BIOS" by people who know these things. Tradition among users like me is to treat that file with great respect, making sure an exact copy of the factory original is present whenever other files in the bundle are replaced. Here's my main question: can I replace that file (named ulc_code.ce, size 4 MB) with something from coreboot and use 'netxfer' to get a working alternative to the factory BIOS? What can I
Maybe, maybe not, depends on what exactly netxfer does and how. But either way, once you flashed the PLCC chip's contents there's no easy way to revert back (if something went wrong). I'm quite sure that netxfer will _NOT_ work anymore after you flashed coreboot.
So you'll have to open the box anyway in such a case.
test before trying this to make sure I don't turn my little device into a brick? Are there some magic bytes or signatures to look for in the factory-file to confirm that it really is some kind of BIOS, and that program execution starts from the same location in the commercial file as it will in coreboot? What else should I be watching for?
Uh, no idea about the above, I haven't yet looked into what the vendor BIOS (+ netxfer) does and how (and I really don't care much).
The usual way to flash coreboot is to use a spare ROM chip where you put the original vendor BIOS (and then store it in a safe place), and only working on another ROM chip.
HTH, Uwe.
Howdy,
Uwe Hermann wrote:
Hi,
On Mon, May 12, 2008 at 11:00:33AM -0700, Philip Loewen wrote:
I'm thinking about trying coreboot on the Compaq Evo T20 thin client.
Yep, nice box. I have one here, too, will port coreboot to it soonish.
I have a Compaq T30 I'd like to try coreboot on, as well. I think they are quite similar in design to the T20, although I don't have a T20 to directly compare it to.
All the coreboot code is open-source would be one good advantage. Likely faster boot times can be expected usually, too, etc. etc.
They both sound like good reasons to me. All open source is a good thing and I want to have several systems like that around. I bought the T30 for just this kind of testing.
the box. But if something goes wrong you really want to replace the BIOS chip (not a problem, as it's in a socket) with a backup chip which you have created/tested _before_.
...
The usual way to flash coreboot is to use a spare ROM chip where you put the original vendor BIOS (and then store it in a safe place), and only working on another ROM chip.
Is there a good source of inexpensive spare flash roms for this device? If so, I would like to order one to be prepared for the procedure you describe.
A quick follow-up question on this Geode GX1/CS5530 thin client before another lengthy silence:
Right now I only know how to access the 48M of onboard flash memory in this little box using the proprietary tools that run in the proprietary BIOS. If I replace the BIOS with coreboot, I will need some other way to access the NAND flash memory. Is there a known working method for this that runs on Linux? (I have tried adding support for Memory Technology Devices to my kernel, but don't know how to tell if they are working.) Given this, I would be willing to give coreboot a try.
Last week I said I was reluctant to open the case of my thin client. At the time I did not realize that a running thin client can itself be used as a BIOS-ROM programmer. I have extra copies of the machine around, so in fact I do have the hardware resources needed to recover completely from a bad flash experience. Now I am more receptive to the idea of trying something that is not fully guaranteed.
Thanks, Philip
Uwe Hermann wrote:
Hi,
On Mon, May 12, 2008 at 11:00:33AM -0700, Philip Loewen wrote:
I'm thinking about trying coreboot on the Compaq Evo T20 thin client.
Yep, nice box. I have one here, too, will port coreboot to it soonish.
This is a Geode GX1 machine with CS5530 companion chip and National Semiconductor DP83815 ethernet card. It has 48MB of flash memory
And/or on the SmartMedia card? At least there's such a socket and a card inserted on my T20.
and 64 MB of RAM (soldered).
Plus an SODIMM slot.
The superiotool from coreboot can't find any evidence of super-I/O.
Indeed, from a quick look I can't spot one on the board either (I opened the case), which is possible as this is a "legacy-free" board (sort of), no PS/2 keyboard etc... So maybe it's just not needed and there is indeed no Super I/O here, will investigate.
The mainboard contains a chip that looks like a socketed PLCC BIOS chip, Winbond 29C020... with
Yep, correct.
a sticker on top giving credit to Wyse Tech 01'V9.0. The keyboard and mouse use a USB 1.1 interface. `lspci` says 00:13.0 USB Controller: Compaq ... ZFMicro Chipset USB (rev 06)
Expert advice on these questions would be very welcome:
- Does coreboot support this setup? (Particularly the USB
devices?)
Mostly, yes. There's no specific board target in svn for this machine yet, but I can provide a patch soonish, as I have one of those boxes here and can test.
The chipset code (northbridge + southbridge) is supported by coreboot.
The main problem will be that there's no legacy PS/2 keyboard and serial port, i.e. debugging will be a bit harder than usual, and the keyboard might not work in FILO (a small bootloader we often use with coreboot). We'll see.
- What advantages will coreboot offer over the
manufacturer's original BIOS?
Various, depends on what your goals are. All the coreboot code is open-source would be one good advantage. Likely faster boot times can be expected usually, too, etc. etc.
E.g., will I get a BIOS control screen I can use to change settings until they work?
Not the kind of menu you're used to from proprietary BIOSes, at least not yet. There are various payloads you can use with coreboot, see http://www.coreboot.org/Payloads.
- I don't have too much time to indulge in hardware
hacking. I'm hoping for an approach that would not require me to even open the Evo's case!
_Might_ be possible, I can test this for you, I don't mind opening the box. But if something goes wrong you really want to replace the BIOS chip (not a problem, as it's in a socket) with a backup chip which you have created/tested _before_.
And this might be possible: like the Wyse Winterm, the Evo boots from on-board flash memory that can be rewritten using 'netxfer'. One of the files that netxfer delivers to the thin client is called "the BIOS" by people who know these things. Tradition among users like me is to treat that file with great respect, making sure an exact copy of the factory original is present whenever other files in the bundle are replaced. Here's my main question: can I replace that file (named ulc_code.ce, size 4 MB) with something from coreboot and use 'netxfer' to get a working alternative to the factory BIOS? What can I
Maybe, maybe not, depends on what exactly netxfer does and how. But either way, once you flashed the PLCC chip's contents there's no easy way to revert back (if something went wrong). I'm quite sure that netxfer will _NOT_ work anymore after you flashed coreboot.
So you'll have to open the box anyway in such a case.
test before trying this to make sure I don't turn my little device into a brick? Are there some magic bytes or signatures to look for in the factory-file to confirm that it really is some kind of BIOS, and that program execution starts from the same location in the commercial file as it will in coreboot? What else should I be watching for?
Uh, no idea about the above, I haven't yet looked into what the vendor BIOS (+ netxfer) does and how (and I really don't care much).
The usual way to flash coreboot is to use a spare ROM chip where you put the original vendor BIOS (and then store it in a safe place), and only working on another ROM chip.
HTH, Uwe.
Am Thu, 22 May 2008 23:58:35 -0700 schrieb Philip Loewen philip@tidepool.ca:
A quick follow-up question on this Geode GX1/CS5530 thin client before another lengthy silence:
Right now I only know how to access the 48M of onboard flash memory in this little box using the proprietary tools that run in the proprietary BIOS. If I replace the BIOS with coreboot, I will need some other way to access the NAND flash memory. Is there a known working method for this that runs on Linux? (I have tried adding support for Memory Technology Devices to my kernel, but don't know how to tell if they are working.) Given this, I would be willing to give coreboot a try.
Last week I said I was reluctant to open the case of my thin client. At the time I did not realize that a running thin client can itself be used as a BIOS-ROM programmer. I have extra copies of the machine around, so in fact I do have the hardware resources needed to recover completely from a bad flash experience. Now I am more receptive to the idea of trying something that is not fully guaranteed.
Thanks, Philip
On my Evo T30 the internal flash works as an hda Disk. The only bad thing on this. The fist partition is needed from the proprietary Bios. Are you able to boot an Linux and take a look?
Markus
On Friday 23 May 2008 09:19, Markus wrote:
Am Thu, 22 May 2008 23:58:35 -0700
schrieb Philip Loewen philip@tidepool.ca:
A quick follow-up question on this Geode GX1/CS5530 thin client before another lengthy silence:
Right now I only know how to access the 48M of onboard flash memory in this little box using the proprietary tools that run in the proprietary BIOS. If I replace the BIOS with coreboot, I will need some other way to access the NAND flash memory. Is there a known working method for this that runs on Linux? (I have tried adding support for Memory Technology Devices to my kernel, but don't know how to tell if they are working.) Given this, I would be willing to give coreboot a try.
Last week I said I was reluctant to open the case of my thin client. At the time I did not realize that a running thin client can itself be used as a BIOS-ROM programmer. I have extra copies of the machine around, so in fact I do have the hardware resources needed to recover completely from a bad flash experience. Now I am more receptive to the idea of trying something that is not fully guaranteed.
Thanks, Philip
On my Evo T30 the internal flash works as an hda Disk. The only bad thing on this. The fist partition is needed from the proprietary Bios. Are you able to boot an Linux and take a look?
This kind of NAND devices (DiskOnChip in my box) provides a simple BIOS extension. They hook themselves into the boot interrupt of a proprietary BIOS. So they can emulate a harddisk to boot from. IMHO for coreboot we need a different solution.
Juergen
Juergen Beisert wrote:
On Friday 23 May 2008 09:19, Markus wrote:
Am Thu, 22 May 2008 23:58:35 -0700
schrieb Philip Loewen philip@tidepool.ca:
Right now I only know how to access the 48M of onboard flash memory in this little box using the proprietary tools that run in the proprietary BIOS. If I replace the BIOS with coreboot, I will need some other way to access the NAND flash memory. Is there a known working method for this that runs on Linux? (I have tried adding support for Memory Technology Devices to my kernel, but I don't know how to tell if they are working.)
On my Evo T30 the internal flash works as an hda Disk. The only bad thing on this. The fist partition is needed from the proprietary Bios. Are you able to boot an Linux and take a look?
This kind of NAND devices (DiskOnChip in my box) provides a simple BIOS extension. They hook themselves into the boot interrupt of a proprietary BIOS. So they can emulate a harddisk to boot from. IMHO for coreboot we need a different solution.
Linux kernel 2.6.24-gentoo-r4 runs well for me, but I don't know where to look for internal flash memory access. There are no disk-like devices listed in /dev. (/dev is populated automatically by udev at boot time ... but being a gentoo user means never feeling quite sure everything is configured right.) The file /proc/devices shows 16 block devices of type 'sd': I don't know what these are, but none of the other possibilities listed in /proc/devices seem likely to me.
Thanks! - Philip
On Friday 23 May 2008 17:32, Philip Loewen wrote:
Juergen Beisert wrote:
On Friday 23 May 2008 09:19, Markus wrote:
Am Thu, 22 May 2008 23:58:35 -0700
schrieb Philip Loewen philip@tidepool.ca:
Right now I only know how to access the 48M of onboard flash memory in this little box using the proprietary tools that run in the proprietary BIOS. If I replace the BIOS with coreboot, I will need some other way to access the NAND flash memory. Is there a known working method for this that runs on Linux? (I have tried adding support for Memory Technology Devices to my kernel, but I don't know how to tell if they are working.)
On my Evo T30 the internal flash works as an hda Disk. The only bad thing on this. The fist partition is needed from the proprietary Bios. Are you able to boot an Linux and take a look?
This kind of NAND devices (DiskOnChip in my box) provides a simple BIOS extension. They hook themselves into the boot interrupt of a proprietary BIOS. So they can emulate a harddisk to boot from. IMHO for coreboot we need a different solution.
Linux kernel 2.6.24-gentoo-r4 runs well for me, but I don't know where to look for internal flash memory access. There are no disk-like devices listed in /dev. (/dev is populated automatically by udev at boot time ... but being a gentoo user means never feeling quite sure everything is configured right.) The file /proc/devices shows 16 block devices of type 'sd': I don't know what these are, but none of the other possibilities listed in /proc/devices seem likely to me.
"sd" are scsi hard disks, also used for all USB based mass storage devices. I think your kernel has no support for the DOC device. Else there should be some or at least one /dev/mtdblock? device(s) exist. Check if your kernel has the follwing symbols enabled: - CONFIG_MTD - CONFIG_MTD_DOC2000 or CONFIG_MTD_DOC2001 or CONFIG_MTD_DOC2001PLUS - CONFIG_NFTL (for a generic filesystem) or CONFIG_JFFS2_FS (flash specific filesystem)
If yes, you could try to load one of the DOC drivers and see if one is able to detect the DOC in your system.
Juergen
On Fri, 2008-05-23 at 09:19 +0200, Markus wrote:
Am Thu, 22 May 2008 23:58:35 -0700 schrieb Philip Loewen philip@tidepool.ca:
A quick follow-up question on this Geode GX1/CS5530 thin client before another lengthy silence:
Right now I only know how to access the 48M of onboard flash memory in this little box using the proprietary tools that run in the proprietary BIOS. If I replace the BIOS with coreboot, I will need some other way to access the NAND flash memory. Is there a known working method for this that runs on Linux? (I have tried adding support for Memory Technology Devices to my kernel, but don't know how to tell if they are working.) Given this, I would be willing to give coreboot a try.
Last week I said I was reluctant to open the case of my thin client. At the time I did not realize that a running thin client can itself be used as a BIOS-ROM programmer. I have extra copies of the machine around, so in fact I do have the hardware resources needed to recover completely from a bad flash experience. Now I am more receptive to the idea of trying something that is not fully guaranteed.
Thanks, Philip
On my Evo T30 the internal flash works as an hda Disk. The only bad thing on this. The fist partition is needed from the proprietary Bios. Are you able to boot an Linux and take a look?
Markus
I've been messing about with a couple of Evo T30 boxes (64M RAM/32M flash) trying to get them to do something more interesting than start Windows CE. I also have a T20 (32M RAM/16M NAND flash).
I've been able to get coreboot doing something on a T30 - it appears more or less identical to the T20 in IC terms with the following exceptions - it has a Super IO chip (NSC PC97307), a TI PCI1410APGE Cardbus controller, and a supporting TI PDU2211A (I'm convinced this is actually a TPS2211A - a single slot PC Card Power Interface Switch). The T30 has a 44pin IDE header on it that in NT embedded and XP embedded devices had the equivalent of a compact flash stuck on it, in CE.Net devices this header is empty and a NAND flash and controlling GAL are soldered to the board, this GAL and NAND flash look identical to that on the T20 (I am unable to confirm the contents of the GAL or NAND chip).
I have spotted that the bi-colour power LED is connected to GPIO10 & 11 on the Super IO, so there clearly are differences between the T20 & T30, and it's not just additional hardware.
Copying the Televideo TC7020 config I was able to get the display up (cute little PLCC/penguin logo in the bottom right) but no serial output. Having spent some time tracing the board I worked out that the NSC Super IO on the T30 has BADDR1 line pulled high, but BADDR0 is low which changes the config port to 0x15c, not 0x2e as it is for the TC7020, and changing the 0x2E in the SERIAL DEV PNP_DEV line I could get output on the serial port.
I've been able to load a FILO payload, but it seems oblivious to the presence of any IDE device. So I removed the 58F256 flash and GAL based on a picture of an NTe device (looking at the traces these are connected to the IDE bus), CF adapters and 2.5" drives are ignored, FILO stating that it's 'Detected floating bus', unfortunately I cannot trace the IDE controller to the 5530A southbridge as the 5530A is a BGA chip.
I then tried etherboot with moderate success - I compiled a very lean kernel and used wraplinux to wrap it and parameters for a serial console for netboot, I can download the kernel but it appears to fail to boot (there's no serial output) - I can netboot the same kernel from the same setup (on albeit (very) different hardware) with no issues.
Not yet giving up I tried memtest86 (and another T30!) memtest86 stops with an unexpected interrupt after a seemingly random period. The second device (with the GAL and NAND flash still onboard) hangs randomly throughout the execution of coreboot.
I cannot boot any of my devices into Linux and cannot run any arbitrary code on them in CE.Net!
I knocked up a PLCC32 adapter from an IOSS BIOS Saviour (I could not find one for a 5V 29C020) from my EPROM programmer/emulator so I can very quickly test new images, I don't believe that should cause an issues as I believe that virtually all the execution of coreboot and payload is from RAM once it has been initialised.
Does anyone have any suggestions on quite where I look next? I've tried several SODIMMs all fail memtest86 and work acceptably in CE.Net and memtest86 in other devices - do you agree it seems unlikely to be faulty hardware and likely to be a configuration issue in netboot? Should I remove the PCI Routing tables for the TC7020 - could this cause issues?
Sorry for such a long first email,
Nick
Hi,
I've been making reasonable progress on getting one of my T30s to boot. I can reliably get the thing to etherboot a 2.6.24 kernel I compiled and an ugly bodged up RAM disk I've created.
I've got what I think is a working irq_tables.c file for the mainboard, however when the kernel boots it says 'PCI: Guessed IRQ x for device 0000:00:y.0', where x is the IRQ in my irq_tables.c and y is the devfn (device? slot?) in the file, just before each device gets used for the first time. After a little prodding checkpir gave me what I assume to be a valid checksum, which seems to have made no difference. Is the kernel very good at guessing, or are these the symptom of a bad checksum in the table, or an incorrect kernel config?
I'm also a little stumped on the initialisation of the cardbus slot - it all looks good, but one of the GPIO lines on the super-IO is connected to the /shutdown line on the power controller, so no power seems to get through. It can detect insertions and removals of cards and correctly identify whether the inserted card is PCMCIA or Cardbus. Is it reasonable that the cardbus controller can see the type of card if the card is unpowered? I think the EPIA-MII is a very different animal, but would be thrilled to be wrong and benefit from someone's experiences with it!
Nick
On Tue, Jun 17, 2008 at 08:11:40PM +0100, Nick Innes wrote:
I'm also a little stumped on the initialisation of the cardbus slot
..
I think the EPIA-MII is a very different animal, but would be thrilled to be wrong and benefit from someone's experiences with it!
EPIA-MII has a Ricoh RL5c456 controller which is really buggy. Linux PCMCIA people have documented a unfixable (IIRC) problem with slot power.
Which controller is in the T30?
//Peter
On Tue, Jun 17, 2008 at 10:20:21PM +0200, Peter Stuge wrote:
On Tue, Jun 17, 2008 at 08:11:40PM +0100, Nick Innes wrote:
I'm also a little stumped on the initialisation of the cardbus slot
..
I think the EPIA-MII is a very different animal, but would be thrilled to be wrong and benefit from someone's experiences with it!
EPIA-MII has a Ricoh RL5c456 controller which is really buggy. Linux PCMCIA people have documented a unfixable (IIRC) problem with slot power.
Which controller is in the T30?
Never mind, just read your old post. No idea about the TI controller.
Can you look into that shutdown GPIO?
//Peter
Hi Peter,
I'll have a play - I've looked at the TI datasheets for both parts, and concluded that they don't give a sensible idea of when the signal should be asserted and when not. It reads as though other signals control the power to the card and this is an optional power switch, which I suspect may be used by the original BIOS/CE.Net firmware to enable/disable the slot for security reasons (I cannot find mention of this in the manual, but cannot think of any other reason).
Is there any way in coreboot v2 to run something mainboard specific just before starting the payload? I ask because on the T20 I have no output but a bicolour LED connected to the southbridge, and it'd be good to know when execution was about to be passed to the payload and that we'd found RAM etc OK - I tried post ram initialisation in auto.c, however this all happens before coreboot is copied to RAM and executed.
Nick
On Tue, 2008-06-17 at 22:21 +0200, Peter Stuge wrote:
On Tue, Jun 17, 2008 at 10:20:21PM +0200, Peter Stuge wrote:
On Tue, Jun 17, 2008 at 08:11:40PM +0100, Nick Innes wrote:
I'm also a little stumped on the initialisation of the cardbus slot
..
I think the EPIA-MII is a very different animal, but would be thrilled to be wrong and benefit from someone's experiences with it!
EPIA-MII has a Ricoh RL5c456 controller which is really buggy. Linux PCMCIA people have documented a unfixable (IIRC) problem with slot power.
Which controller is in the T30?
Never mind, just read your old post. No idea about the TI controller.
Can you look into that shutdown GPIO?
//Peter
-
Juergen Beisert -
Markus -
Nick Innes -
Nick Innes -
Peter Stuge -
Philip Loewen -
Ralph Green -
Uwe Hermann