ron minnich wrote: > On Jan 17, 2008 2:32 PM, Ronald Hoogenboom <[EMAIL PROTECTED]> wrote: > >> Now I'm looking at how to make the rom_stream read the flash chip like >> in the over512k_read_chip. >> But I'm a bit stuck on the overal mechanics of the initialization >> process and how to get hold of the assigned io port for the SPI serial >> flash controller in the IT8716. >> This is supposed to be configured by the GPIO Config registers (LDN 07) >> at index 0x64 and 0x65, but in the pnp_dev_info array in >> it8716f/superio.c, there is nothing listed after IT8716F_GPIO, while at >> other indexes, there is. Does this mean that the superio.c file fails to >> configure this io port? >> > > yes, it means that the port is not configured. There is a lot of TODO > in this file. > It may be time to fill it in. > > >> Suppose that this port IS configured correcly, what means should my >> rom_stream use to retrieve this port address? >> > > I think you make a new stream type, let's called it bad_stream, that knows > how to handle the addresses. The bad_stream would know that when the > address is in a certain range, i.e. below the address (0-512KB), it > will use I/O, and when it is above, it can use memory access. > > So in src/stream/Config.lb > you add something like this: > > uses CONFIG_BADROM_PAYLOAD > > if CONFIG_BADROM_PAYLOAD > object badrom_stream.o > end > > >> Is there some doc about these pnp functions? >> > > no, sorry. We are doing better in v3 ... we know the lack of docs is a > problem. > > >> Suppose I've figured it all out and created my new rom_stream_over512k >> (or so) object, how do I mingle it into the Config.lb files, so it will >> automatically get chosen when a ROM_SIZE of over 512k is selected in the >> target configuration (AND the superio is an IT8716F). >> > > I think you make those boards always use bad_stream (or whatever) in all > cases, > and not try to get the config tool to pick different types, as in the > example above. > > But, it might be possible to do this: > > if CONFIG_BADROM_PAYLOAD > if ROM_SIZE > 512*1024 > object badrom_stream.o > else > object rom_stream.o > end > end > > Something like this might work. > > The it8761f is NOT the worst thing we have seen, it's just really, really bad. > > So I guess we have to put in another kludge for badly design chipsets. > It's not the first time :-) > > >> In the targets/gigabyte/m57sli directory, there is a Config.lb.kernel >> file, which I used as a base for my build, but it only uses a 'fallback' >> and a 'failover' image. Why no 'normal' one? What is supposed to be the >> purpose of each image? (You see, I'm really missing some key parts of >> the big picture...) >> > > you're not missing anything. The picture, which was once, years ago, > pretty clean, has gotten grafitti-tagged by many authors and the > necessities of strange hardware. > > This will make no sense, but I'll try. Fallback is the image you can > ALWAYS use, even when normal does not work. Normal is an image you can > use unless something breaks, and you use fallback. > > So, what's the one image you must always have? fallback. What's the > optional image? normal. So, when there is only going to be one image, > it's called fallback. > > What people don't realize is that the images can have any name, so, > for instance, on single image ROMs, they should really not use the > name 'fallback' -- there is nothing sacred about the names. 'single' > would do. > > failover -- that snuck in at some point and I think YH Lu understands why. > > This is a bit messy as the guys who first put the fallback/normal in > never intended for bioses to be built WITHOUT fallback/normal. I > relied heavily on the fallback stuff at LANL but have since hardly > used it. Not all people think it is needed -- OLPC for example has > explicitly rejected a need for a fallback bios image. It's an open > question as to whether fallback bios images have real value for > people. >
Seems like this might be a good time to raise this question: what exactly is the difference between normal and fallback? I know part of the answer, but I don't think I know all of it. -Corey -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot