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 c-d.hailfinger.devel.2006@gmx.net [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