I have no idea if this helps. But there's been discussion of "DRAM
settings in DTS" and "where does CARBASE go" and so on, so I think we
need to try to document some rules. Here is a first cut.
The actual patch is
but that's huge and totally unreadable so I recommend reviewing
That's the only change to the buildrom code itself, the rest is just
replacing the whole scripts/kconfig/ dir with the new kconfig.
I used the coreinfo kconfig/ with only a handful of string replacements
a la s/coreinfo/buildrom/ so the diff to coreinfo's kconfig is tiny.
I did some ad-hoc testing with this, tried various kconfig targets
(menuconfig, xconfig, gconfig, ...) and various buildrom builds and
it seems to work fine so far, but some more testing by others is
http://www.hermann-uwe.de | http://www.holsham-traders.dehttp://www.crazy-hacks.org | http://www.unmaintained-free-software.org
#88: Add UHCI/OHCI/EHCI support to GRUB2
Reporter: uwe | Owner: oxygene
Type: enhancement | Status: new
Priority: critical | Milestone: Port GRUB2 to coreboot
Component: filo | Version:
Resolution: | Keywords:
Dependencies: | Patchstatus: there is no patch
Changes (by stepan):
* owner: => oxygene
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/88#comment:2>
I can't wait for this to happen :-)
Need some suggestions/help. I think I figured out why coreboot for RCA
RM4100 will not work on the Thomson IP1000. The only difference is that the
IP1000 only has 64MB of onboard memory and the RCA RM4100 has 128MB of
onboard memory. coreboot chokes because there is no onboard spd, so the spd
settings are manually set via an array (see spd_table.h). If you want to
see a high res pic of the boards, they are on my site: www.settoplinux.org
So I guess with that being the only difference, should we create a new
target for the Thomson IP1000 ???
On two boards, one MCP55 based and another CK804, if I flash the
proprietary BIOS with: flasrom -wv bios.bin
Verification fails and if I try to boot, it doesn't. Have to flash the
BIOS in another board based on K8T890 that I have. In that one all
works fine, with both BIOS chips I have - one winbond and a PMC.
Haven't tried flashing coreboot due to lack of support.
Since the chipsets are support, this isn't supposed to happen, right?
On 1/27/08, Stefan Reinauer <stepan(a)coresystems.de> wrote:
> * Tiago Marques <tiagomnm(a)gmail.com> [080127 16:21]:
> > Hi.
> > Both failed, tried with two different BIOS chips.
> > Flashing with AWDFlash works fine though.
> > Had to flash it again in a VIA K8T890 board, which works flawlessly.
> > Any ideas, fix?
> What's the problem?
> coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
> Tel.: +49 761 7668825 • Fax: +49 761 7664613
> Email: info(a)coresystems.de • http://www.coresystems.de/
> Registergericht: Amtsgericht Freiburg • HRB 7656
> Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
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
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.