Hi
I dug out my abandoned Epia to see if I could do something with it, and based the stuff on
http://www.coreboot.org/VIA_EPIA-MII
There were some things I found weird and I'm hoping someone could shed light on them..
The web says: "The configuration as set up by the buildtarget process will create a coreboot file which is exactly 196608 bytes long, which is exactly 64K bytes short of what needs to go into the 256K flash rom."
For me, that's not true. root@coraline:/usr/src/coreboot-v2-4046/targets/via/epia-m/epia-m# ls -l normal/coreboot.rom fallback/coreboot.rom -rw-r--r-- 1 root src 131072 Apr 2 20:46 fallback/coreboot.rom -rw-r--r-- 1 root src 131072 Apr 2 20:46 normal/coreboot.rom
Q1: Why is there a mismatch here?
Also, when encouraged to change the cat like cat fallback/coreboot.rom > coreboot.rom to cat /video.bios.bin fallback/coreboot.rom >coreboot.rom
it wasn't accurate; the line is cat normal/coreboot.rom fallback/coreboot.rom > ./coreboot.rom
Let's remember those two are 262144 bytes, because now the wiki tells us to add the 64k video.
It obviously doesn't fit in 256k, if we're there already, so what I actually did was cat the video bios TWICE(!!) and then the normal bios to make it 256k.
That seems kludgy but I got a FILO prompt :)
Q2: Ideas on why I had to do that?
Here's the Config.lb, where I just changed the FILO payload to /filo.nohting.elf (to reflect the fact nothing seems to fit in a rom this small ;)
Thanks!
# Sample config file for EPIA-M # This will make a target directory of ./epia-m
target epia-m
mainboard via/epia-m
option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEFAULT_CONSOLE_LOGLEVEL=8 option CONFIG_CONSOLE_SERIAL8250=1
option ROM_SIZE=256*1024
option HAVE_OPTION_TABLE=1 option CONFIG_ROM_PAYLOAD=1 option HAVE_FALLBACK_BOOT=1
### ### Compute the location and size of where this firmware image ### (coreboot plus bootloader) will live in the boot rom chip. ### option FALLBACK_SIZE=131072
## Coreboot C code runs at this location in RAM option _RAMBASE=0x00004000
# ### ### Compute the start location and size size of ### The coreboot bootloader. ###
# # EPIA-M #
romimage "fallback" option USE_FALLBACK_IMAGE=1 option ROM_IMAGE_SIZE=0x10000 option COREBOOT_EXTRA_VERSION=".0Fallback" # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf # payload ../../../../tg3--ide_disk.zelf # payload ../../../../../lnxieepro100.ebi payload /filo.nothing.elf end
romimage "normal" option USE_FALLBACK_IMAGE=1 option ROM_IMAGE_SIZE=0x10000 option COREBOOT_EXTRA_VERSION=".0Fallback" # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf # payload ../../../../tg3--ide_disk.zelf # payload ../../../../../lnxieepro100.ebi payload /filo.nothing.elf end
buildrom ./coreboot.rom ROM_SIZE "normal" "fallback"
2009/4/2 Markus Törnqvist mjt@nysv.org
Hi
I dug out my abandoned Epia to see if I could do something with it, and based the stuff on
http://www.coreboot.org/VIA_EPIA-MII
There were some things I found weird and I'm hoping someone could shed light on them..
The web says: "The configuration as set up by the buildtarget process will create a coreboot file which is exactly 196608 bytes long, which is exactly 64K bytes short of what needs to go into the 256K flash rom."
For me, that's not true. root@coraline:/usr/src/coreboot-v2-4046/targets/via/epia-m/epia-m# ls -l normal/coreboot.rom fallback/coreboot.rom -rw-r--r-- 1 root src 131072 Apr 2 20:46 fallback/coreboot.rom -rw-r--r-- 1 root src 131072 Apr 2 20:46 normal/coreboot.rom
Q1: Why is there a mismatch here?
Because with the open source xf86-unichrome and Luc Verhaegan's kernel driver, it's now possible for the kernel to initialize a framebuffer console and X video without the need for the VGA BIOS, so someone decided to change the default to build a 256k image and remove the commented out line with the 192k size. I believe the console driver is included with recent kernels, but I couldn't tell you the exact version. If you want to use a different driver, modify this line:
option ROM_SIZE=256*1024
to be
option ROM_SIZE=192*1024
Then, re-run buildtarget, make clean, and make. You should end up with a 128k fallback image and 64k normal image (yes, it's a nasty solution, part of the reason for v3), and a 192k image in build directory (the one you ran make from), that's the image you should probably use. If you want to continue using your current solution, you should probably use the fallback coreboot.rom, as there is code that will attempt to boot from the fallback image in the event of an error, and if there is no fallback image to boot from, nasty things could happen. If anything's not clear, let me know, I'm terrible at explaining things.
-Corey
Also, when encouraged to change the cat like cat fallback/coreboot.rom > coreboot.rom to cat /video.bios.bin fallback/coreboot.rom >coreboot.rom
it wasn't accurate; the line is cat normal/coreboot.rom fallback/coreboot.rom > ./coreboot.rom
Let's remember those two are 262144 bytes, because now the wiki tells us to add the 64k video.
It obviously doesn't fit in 256k, if we're there already, so what I actually did was cat the video bios TWICE(!!) and then the normal bios to make it 256k.
That seems kludgy but I got a FILO prompt :)
Q2: Ideas on why I had to do that?
Here's the Config.lb, where I just changed the FILO payload to /filo.nohting.elf (to reflect the fact nothing seems to fit in a rom this small ;)
Thanks!
# Sample config file for EPIA-M # This will make a target directory of ./epia-m
target epia-m
mainboard via/epia-m
option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEFAULT_CONSOLE_LOGLEVEL=8 option CONFIG_CONSOLE_SERIAL8250=1
option HAVE_OPTION_TABLE=1 option CONFIG_ROM_PAYLOAD=1 option HAVE_FALLBACK_BOOT=1
### ### Compute the location and size of where this firmware image ### (coreboot plus bootloader) will live in the boot rom chip. ### option FALLBACK_SIZE=131072
## Coreboot C code runs at this location in RAM option _RAMBASE=0x00004000
# ### ### Compute the start location and size size of ### The coreboot bootloader. ###
# # EPIA-M #
romimage "fallback" option USE_FALLBACK_IMAGE=1 option ROM_IMAGE_SIZE=0x10000 option COREBOOT_EXTRA_VERSION=".0Fallback" # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf # payload ../../../../tg3--ide_disk.zelf # payload ../../../../../lnxieepro100.ebi payload /filo.nothing.elf end
romimage "normal" option USE_FALLBACK_IMAGE=1 option ROM_IMAGE_SIZE=0x10000 option COREBOOT_EXTRA_VERSION=".0Fallback" # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf # payload ../../../../tg3--ide_disk.zelf # payload ../../../../../lnxieepro100.ebi payload /filo.nothing.elf end
buildrom ./coreboot.rom ROM_SIZE "normal" "fallback"
-- mjt
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Thu, Apr 02, 2009 at 06:46:47PM -0400, Corey Osgood wrote:
2009/4/2 Markus Törnqvist mjt@nysv.org
The web says: "The configuration as set up by the buildtarget process will create a coreboot file which is exactly 196608 bytes long, which is exactly 64K bytes short of what needs to go into the 256K flash rom."
root@coraline:/usr/src/coreboot-v2-4046/targets/via/epia-m/epia-m# ls -l normal/coreboot.rom fallback/coreboot.rom -rw-r--r-- 1 root src 131072 Apr 2 20:46 fallback/coreboot.rom -rw-r--r-- 1 root src 131072 Apr 2 20:46 normal/coreboot.rom
Q1: Why is there a mismatch here?
Because with the open source xf86-unichrome and Luc Verhaegan's kernel driver, it's now possible for the kernel to initialize a framebuffer console and X video without the need for the VGA BIOS, so someone decided to change
xf86-unichrome is about drivers for the mobo's integrated vga, right?
the default to build a 256k image and remove the commented out line with the 192k size. I believe the console driver is included with recent kernels, but I couldn't tell you the exact version. If you want to use a different driver, modify this line:
option ROM_SIZE=256*1024
to be
option ROM_SIZE=192*1024
So this should be safest as I'm hoping to use, at least for starters, a regular Ubuntu kernel, which might not be the latest one but saves me the trouble of compiling my own?
Then, re-run buildtarget, make clean, and make. You should end up with a 128k fallback image and 64k normal image
So I tried ROM_SIZE=192*1024
Payload: 36804 coreboot: 65536 ROM size: 131072 Left space: 28732
Both images are still 128k ...
(yes, it's a nasty solution, part of the reason for v3), and a 192k image in build directory (the one you ran make from), that's the image you should probably use. If you want to continue using your current solution, you should probably use the fallback coreboot.rom, as there is code that will attempt to boot from the fallback image in the event of an error, and if there is no fallback image to boot from, nasty things could happen.
... but the build dir coreboot.rom is 256k, not 192k!
I don't know what happened actually, but not surprisingly, it didn't boot, was just black and nonresponsive.
Maybe I should do the weird-yet-ugly vga-bios-twice hack then, for now.
If anything's not clear, let me know, I'm terrible at explaining things.
Heh, and this should end up on the wiki in some non-confusing format too so the next guy won't have to ask the same questions :)
Thanks!
Markus T�rnqvist wrote:
So I tried ROM_SIZE=192*1024
..
Heh, and this should end up on the wiki in some non-confusing format too so the next guy won't have to ask the same questions :)
The exact way the five or ten different SIZE options in v2 interact is still a mystery to me after many years of occasional tweaking. It's horrible.
//Peter
Am 03.04.2009 12:50, schrieb Peter Stuge:
The exact way the five or ten different SIZE options in v2 interact is still a mystery to me after many years of occasional tweaking. It's horrible.
A romfs capable target can hide most of the SIZE options from the user. That one is easy to do and can be done for every single target. In another step, after all targets are romfs, it could be fixed properly so that only one SIZE option remains: total image size. That one is more complex, but worth it in my opinion.
But there's still some small romfs patch pending, that I want to clean up and post soonish. After that, targets could be moved to romfs, and I'll try to post some guidelines for that when the infrastructure work is done.
Regards, Patrick
On Fri, Apr 03, 2009 at 12:50:00PM +0200, Peter Stuge wrote:
Markus T�rnqvist wrote:
So I tried ROM_SIZE=192*1024
..
Heh, and this should end up on the wiki in some non-confusing format too so the next guy won't have to ask the same questions :)
The exact way the five or ten different SIZE options in v2 interact is still a mystery to me after many years of occasional tweaking. It's horrible.
I'll try to test v3 when the epia-mii gets some support there :)
On 03.04.2009, at 13:29, wrote:
On Fri, Apr 03, 2009 at 12:50:00PM +0200, Peter Stuge wrote:
Markus T�rnqvist wrote:
So I tried ROM_SIZE=192*1024
..
Heh, and this should end up on the wiki in some non-confusing format too so the next guy won't have to ask the same questions :)
The exact way the five or ten different SIZE options in v2 interact is still a mystery to me after many years of occasional tweaking. It's horrible.
I'll try to test v3 when the epia-mii gets some support there :)
-- mjt
It's unlikely to ever see that happen.. The c3, unlike the c7, is said to be incapable of Cache As Ram... That's the reason v3 looks so much simpler, it will never support CPUs without CAR capability..
Stefan
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On 03.04.2009 13:54, Stefan Reinauer wrote:
On 03.04.2009, at 13:29, wrote:
On Fri, Apr 03, 2009 at 12:50:00PM +0200, Peter Stuge wrote:
Markus T�rnqvist wrote:
So I tried ROM_SIZE=192*1024
..
Heh, and this should end up on the wiki in some non-confusing format too so the next guy won't have to ask the same questions :)
The exact way the five or ten different SIZE options in v2 interact is still a mystery to me after many years of occasional tweaking. It's horrible.
I'll try to test v3 when the epia-mii gets some support there :)
It's unlikely to ever see that happen.. The c3, unlike the c7, is said to be incapable of Cache As Ram... That's the reason v3 looks so much simpler, it will never support CPUs without CAR capability..
I still hope CAR can be made to work on the C3. IIRC C3 CAR was "just" totally unreliable and not broken. To be honest, with our current CAR code, it is very easy to break it by accident (even in v3) and I suspect that happened when testing C3 CAR. And even if we get CAR to work reliably on the C3, it will be extremely _slow_ (maybe even slower than with ROMCC) until RAM is turned on.
Regards, Carl-Daniel