> I'm currently working on porting coreboot to the Via EPIA-N(L) i.e. > C3/CN400/VT8237R/Winbond SuperIO.
Welcome! > I'm a fairly competent embedded systems designer/coder, and I'm aiming to > get to the point where I can use the EPIA to run a small linux kernel and > custom service from flash to act as a data logger from a custom perpheral to > a SATA disk. > > I'm not NDAd with Via (spent months trying to do this and gave up after > getting the run around for so long) but have aquired some data on the CN400 > that has allowed me to get this far. I don't have the BIOS Porting Guide, > which suspect would be quite illuminating, if there is anyone out there who > does have this and could review/correct my code for errors I'd appreciate > it. I'm not the right person for that, but hopefully this will help a little anyway. > I've got to the point where I have flashrom programming the board, I have a > working build environment for V2 which is running the early romcc compiled > code and seems to have done the CN400 meminit stuff OK, near as I can tell I > am able to access SDRAM OK from romcc code (the early serial stuff is up and > running OK, and i can get debug out that way), but I'm getting strange > things happening when jumping to copy_and_run_core. A log file would probably be helpful. > I think that the basic problem is a linking/location problem. > > Options.lb doesn't seem to let me turn on print_spew in the gcc code but > works OK in the romcc code, and > the .map file looks suspicious to me with > loads of constants all defined at the same location. It's probably fine, but you can compare with the map file of a working board to see what it looks like. There are several constants defined at the same location, and the build process will usually fail if they're wrong. > I'm happy to do the leg work if someone can give me a steer into how all of > the different ROM_SIZE, ROM_SECTION_SIZE PAYLOAD_SIZE, FALLBACK_SIZE etc. > etc. relate to the linking and location of code. I'm finding this a bit > impenetrable at the moment. Have you seen this page? http://www.coreboot.org/Anatomy_of_a_Failover_coreboot_v2_Image You probably want an image that only contains fallback, which makes life simpler anyway. Have you played around with qemu? It has a single image solution implemented with CBFS (which is new) or you can go back a few revisions to before CBFS. Thanks, Myles -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
