Hallo, thanks for your answer. I had the coreboot-read.bin from the
coreboot source "coreboot-v2-4475", it is just renamed (coreboot.rom). I
used the target for IEI_JUKI_511P board because it is near the same as I
have. I have two EEProm Chips ... it should be safe to test coreboot on
this board.
I changed the Config.lb, because I want to use seabios:
payload /root/coreboot/bios.bin.elf-0.4.1
And I had a problem with the Rom size. ... I changed this:
option CONFIG_COMPRESS=1
Then coreboot.rom compiled without an error.
The next Step was to add the VGA bios. But it dosnt worked.
Sorry for my bad english.
The latest SeaBIOS git now supports Post Memory Manager (PMM) calls.
These calls are used by optionroms to allocate memory during bootup.
If anyone has had trouble with the execution of an optionrom, I
suggest retrying with the latest SeaBIOS git. It's possible the
addition of PMM may improve execution.
Also, for those with working optionroms I suggest testing the latest
SeaBIOS git to verify there has been no regressions.
Finally, for further info on SeaBIOS with coreboot see:
http://www.coreboot.org/SeaBIOS
-Kevin
Hello, i want to add the VGA bios to my coreboot.rom. But it fails.
/root/coreboot/coreboot-v2-4475/util/cbfstool/cbfstool coreboot-read.bin
add vgabios.bin pci1078,0104.rom 0
(cbfstool) E: This does not appear to be a valid ROM
(cbfstool) E: Problem while reading the ROM
Thank you for your answers.
Hi,
The Multiboot spec is a bit too permissive about this, as it doesn't
specify the state of direction flag when payload is called. Some payloads
(we found this in ReactOS FreeLDR) assume it is cleared, and fail otherwise.
We adjusted GRUB to be sure it's always cleared. I think coreboot should do
the same. Here's a patch for v3.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
