On 27.01.2008 13:55, Stefan Reinauer wrote: > Carl-Daniel Hailfinger wrote: >> On 27.01.2008 03:01, Stefan Reinauer wrote: >> >>> * Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [080126 >>> 02:28]: >>> >>>> while I agree fully with renaming the project, we need to consider the >>>> point where we stop the renaming, also because some code >>>> referencing our >>>> code is outside of our control. >>>> We have LBTABLE structures and can rename them to CBTABLE. But will >>>> Linux kernel folks merge patches renaming the structs? >>>> >>> >>> what code in the linux kernel are you particularly referring to? Linux >>> should be pretty much coreboot agnostic. >>> >> >> Didn't the kernel have coreboot table parsing some time in the past? I'm >> not sure about current Linux code, though. > > Not that I know of. > > The current linux kernel does not, I verified that.
Good (or in that case bad) to know. > The bootloader (payload) is preparing e820 entries to make linux see > all of memory. Well, some of them do. Open Firmware does not. Which is > why Torsten Duwe saw weeird problems when booting > coreboot+openfirmware on a machine with 4G ram. I think Linux only saw > 28M or some such 8) So if we want to pass any new information to a Linux kernel, we have to teach the bootloader about a new LBTABLE element and the bootloader has to translate that to an e820 section Linux can understand? Painful. > The discussion reminds me we have to find a way to get the coreboot > messages into dmesg, at least in v3. Any hints how to do this > correctly? can it be done for the pre-ram code now that you improved > the cache as ram stuff? that would be really really cool. Via e820? I have some code which keeps all messages from the beginning of CAR up to payload handoff in a local buffer. If anyone wants to write code which copies the buffer to some place where Linux expects it and handles the glue logic, be my guest. Regards, Carl-Daniel -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
