[coreboot] Thin Client Compaq Evo T20
philip at tidepool.ca
Fri May 23 08:58:35 CEST 2008
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.
Uwe Hermann wrote:
> 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:
>> 1. Does coreboot support this setup? (Particularly the USB
> 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
> 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.
>> 2. 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.
>> 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!
> _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.
More information about the coreboot