Hi,
attached patch removes: - CONFIG_CBFS - anything that's conditional on CONFIG_CBFS == 0 - files that were only included for CONFIG_CBFS == 0 In particular: - elfboot - stream boot code - mini-filo and filesystems (depends on stream boot code)
After this patch, there is no way to build an image that is not using CBFS anymore.
I might not have caught everything, but an abuild run over everything built fine, and there is no mention of "CBFS" in the tree anymore that doesn't belong there. Kconfig is almost not affected, as it's CBFS-only, anyway. I only had to remove the CBFS configuration variable that defaulted to "true".
I consider the tree ready for this as there are no known bugs anymore (except the one fixed by that other patch). Speak up if you disagree (I intend to wait with committing this patch until saturday evening CEST)
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Patrick Georgi wrote:
attached patch removes:
- CONFIG_CBFS
- anything that's conditional on CONFIG_CBFS == 0
- files that were only included for CONFIG_CBFS == 0
In particular:
- elfboot
Ok.
- stream boot code
Wasn't this used for accessing large flash on m57sli?
And does it have anything to do with the serial transfer stuff? (Xmodem)
- mini-filo and filesystems
Cleaning out the attic - great!
I consider the tree ready for this as there are no known bugs anymore (except the one fixed by that other patch). Speak up if you disagree
I agree! :)
//Peter
On Sep 30, 2009, at 22:56, Peter Stuge peter@stuge.se wrote:
Patrick Georgi wrote:
attached patch removes:
- CONFIG_CBFS
- anything that's conditional on CONFIG_CBFS == 0
- files that were only included for CONFIG_CBFS == 0
In particular:
- elfboot
Ok.
- stream boot code
Wasn't this used for accessing large flash on m57sli?
Yes.
Anyone with such a setup willing to fix CBFS for that?
And does it have anything to do with the serial transfer stuff? (Xmodem)
Not possible anymore with CBFS.. Maybe we should make a minipayload for the functionality?
//Peter
Stefan
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On 30.09.2009 23:08, Stefan Reinauer wrote:
On Sep 30, 2009, at 22:56, Peter Stuge peter@stuge.se wrote:
Patrick Georgi wrote:
attached patch removes:
- CONFIG_CBFS
- stream boot code
Wasn't this used for accessing large flash on m57sli?
Yes.
Anyone with such a setup willing to fix CBFS for that?
I don't have such a setup, but I remember the discussion about supporting this for LAR in v3 and back then it was the consensus that such boards would simply not be ported to v3. Given that v2 now has CBFS, we need to either abandon large flash on M57SLI and similar boards or fix CBFS somehow.
The horrible way out is to use accessor functions for every flash access made by CBFS code. It also means you get to write your own streaming version of memcmp, strstr, strlen etc. The easy way out is to simply copy all of flash to RAM, then walk the copy in RAM. It's a bit inefficient because you have to copy the whole flash chip to RAM, but the code stays readable. Of course RAMinit and bootblock have to be in the always-mapped region of the flash chip.
And does it have anything to do with the serial transfer stuff? (Xmodem)
Not possible anymore with CBFS.. Maybe we should make a minipayload for the functionality?
Interfacing the minipayload is probably going to be more pain than simply linking in the xmodem code and calling it if all other options fail.
Regards, Carl-Daniel
can anyone even buy an m57sli any more? Was it an unfortunate mistake -- never repeated -- that FLASH was not directly accessible? If the m57sli is an exception and we'll never see this problem again, I say we drop it. Copying all of flash into ram sounds bad. If we have to cope with this problem in future, maybe we're stuck with accessor functions.
But FLASH is so slow I doubt that the cost of an accessor function is going to kill us. Function calls run in nanoseconds, and if SPI really is only 40 MB/sec., then that's 25 ns/byte.
ron
ron minnich wrote:
can anyone even buy an m57sli any more?
No, they are out of production and out of stock really everywhere.
Was it an unfortunate mistake -- never repeated -- that FLASH was not directly accessible?
In the long term (a few years) the problem will go away as SPI masters move into every chipset, but as long as boards are using extra components between the CPU and the flash chip, there can be issues like this.
If the m57sli is an exception and we'll never see this problem again, I say we drop it. Copying all of flash into ram sounds bad.
It would be unfortunate to drop support for one of the most hack friendly boards that we've seen in a while.
But FLASH is so slow I doubt that the cost of an accessor function is going to kill us. Function calls run in nanoseconds, and if SPI really is only 40 MB/sec., then that's 25 ns/byte.
40 Mbyte/s seems way optimistic to me. In the ideal case it's possible to stream all of the data out of the chip without overhead, and even then it's CLK/8 Mbyte/s. I think the fastest CLK I've seen recently is 90 MHz but the superio SPI masters only run at 16 MHz. (=2Mbyte/s assuming no overhead, which is far from the norm, it's common to have several bytes overhead for each 256 bytes of data)
Chipsets could run faster, but not all flash chips can run super fast either. 25-33 somewhere would be the safe number. Max CLK seems to increase with size and each flash chip product generation though.
//Peter
On Wed, Sep 30, 2009 at 3:43 PM, Peter Stuge peter@stuge.se wrote:
40 Mbyte/s seems way optimistic to me
Yeah, I was going worst-case scenario (i.e. SPI is super-fast) and even in that case accessor functions would not hurt much if at all.
So if we absolutely *have* to do some sort of function interface, well, it won't exactly kill us.
ron
ron minnich wrote:
Yeah, I was going worst-case scenario (i.e. SPI is super-fast) and even in that case accessor functions would not hurt much if at all.
Ah!
So if we absolutely *have* to do some sort of function interface, well, it won't exactly kill us.
I think it would be great to not have to deal with that in the common case, but I think it can be useful for some boards - ie. if there is would I think it would be best to make it optional.
//Peter
Peter Stuge wrote:
If the m57sli is an exception and we'll never see this problem again, I say we drop it. Copying all of flash into ram sounds bad.
It would be unfortunate to drop support for one of the most hack friendly boards that we've seen in a while.
I agree. I don't see why we should drop the board support just because one hack does not work anymore. (A hack nobody around seems to be using to begin with)
There is no problem with unmodified boards, and there is no problem with modified boards with flash chips under a certain size. So unless someone with a larger amount of m57sli boards, or motivation to come up with a solution to get this fixed, I suggest we move on and improve life for the other 99.99% coreboot users.
Stefan
Yes, I'm sorry, we keep board support, but stop worrying about huge SPI anbd weird accessing of it.
As for fallback: we really need to bring it back at some point. I'm speaking as someone whose life was saved because I did not destroy a 1024-node cluster with a bad bios image.
CBFS will give us a normal/fallback setup that people can understand.
ron
On 01.10.2009 01:07, ron minnich wrote:
Yes, I'm sorry, we keep board support, but stop worrying about huge SPI anbd weird accessing of it.
As for fallback: we really need to bring it back at some point. I'm speaking as someone whose life was saved because I did not destroy a 1024-node cluster with a bad bios image.
CBFS will give us a normal/fallback setup that people can understand.
Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace lar->cbfs on that file? As a nice side benefit, we get global variables and similar stuff.
Regards, Carl-Daniel
On Wed, Sep 30, 2009 at 4:16 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace lar->cbfs on that file? As a nice side benefit, we get global variables and similar stuff.
I've looked into doing just that. It's not as simple as it sounds. I'd rather not open that can of worms just yet.
ron
On 01.10.2009 01:27, ron minnich wrote:
On Wed, Sep 30, 2009 at 4:16 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace lar->cbfs on that file? As a nice side benefit, we get global variables and similar stuff.
I've looked into doing just that. It's not as simple as it sounds.
I'm surprised. My stage1 SMP patch was never merged IIRC, so stack trashing is expected on any non-UP v3 boot. But other than that, v3 stage1 code worked pretty well. The ELFboot code in there should be dropped (was default off anyway) and then we have a pretty readable startup.
I'd rather not open that can of worms just yet.
If you're talking about doing too many things at once, I fully agree. Once the tree is CBFS-only and once Kconfig works for all actively developed boards, we will have a mostly stable tree again and it would be cool to look at importing stage1 (and possibly stage0) from v3.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 01.10.2009 01:07, ron minnich wrote:
Yes, I'm sorry, we keep board support, but stop worrying about huge SPI anbd weird accessing of it.
As for fallback: we really need to bring it back at some point. I'm speaking as someone whose life was saved because I did not destroy a 1024-node cluster with a bad bios image.
CBFS will give us a normal/fallback setup that people can understand.
Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace lar->cbfs on that file? As a nice side benefit, we get global variables and similar stuff.
No search and replace blind copy of non-fitting code please. The least we can use in v2 right now is a code quality drop to v3 level ..
One step after the other..
It's not enough to have one board running. If you have a solution to safely bring over 200 boards, please do it!
Stefan
Am Mittwoch, den 30.09.2009, 16:07 -0700 schrieb ron minnich:
Yes, I'm sorry, we keep board support, but stop worrying about huge SPI anbd weird accessing of it.
As for fallback: we really need to bring it back at some point. I'm speaking as someone whose life was saved because I did not destroy a 1024-node cluster with a bad bios image.
CBFS will give us a normal/fallback setup that people can understand.
It will, but right now, CBFS is worse off than old-style.
I dropped fallback/normal support in Kconfig deliberately, not because it is hard, but due to the current situation being a mess (~140 copies of the fallback-or-normal decision function with minor changes), and that we don't have a plan on how to safely update a CBFS image anyway.
Once we have a plan that's actually safe, does away with the copy&paste (and the fallback/normal // failover/fallback/normal duality while we're at it), I'm all for it. But please not now, with the mess we have.
My plan for it, pending any better solution: - unify the decision stuff into a single place - move everything but the decision stuff out of the bootblock (so it essentially becomes immutable across updates) - extend kconfig so it knows how to update existing images (by adding new files) - somehow make flashrom smart enough to safely update the flash
The idea is that Kconfig continues to build only one image, but allows to add to such an image later, when it's actually time to carry two images. The current approach of having two nearly identical images around made sense in the old memory layout, but not with CBFS, in my opinion.
I have a prototype of the moving-code-around part of it done, on the QEmu target. It runs raminit from a cbfs file, linked to a fixed address within cbfs, which avoids weird compiler tricks. CBFS is only used to allow multiple such images to coexist without the bootblock having to know their addresses.
Open issues are: We need early rom mapping and CMOS access for all boards. So far, only the boards with failover layout are somewhat guaranteed to have code for that.
Patrick
On 01.10.2009 09:09, Patrick Georgi wrote:
Am Mittwoch, den 30.09.2009, 16:07 -0700 schrieb ron minnich:
CBFS will give us a normal/fallback setup that people can understand.
It will, but right now, CBFS is worse off than old-style.
[...] My plan for it, pending any better solution:
- unify the decision stuff into a single place
Agreed.
- move everything but the decision stuff out of the bootblock (so it essentially becomes immutable across updates)
This means we either need a CBFS walker in ASM or compile it with ROMCC. Even if that is possible (and IIRC you already have code for this) it strikes me as a bad idea. I want to have as little asm code as possible and I want to keep ROMCC out of the CAR images. Others may disagree with me, but I thought I'd say this before the decision is finalized.
- extend kconfig so it knows how to update existing images (by adding new files)
Sorry, I don't understand this. Did you mean the makefiles? I see no relation between fallback/normal and Kconfig.
- somehow make flashrom smart enough to safely update the flash
Patches to add partial erase support for some chips are pending since quite some time. We need more flashrom reviewers.
The idea is that Kconfig continues to build only one image, but allows to add to such an image later, when it's actually time to carry two images.
Ah. I always thought of Kconfig as a configuration system, not a build system.
The current approach of having two nearly identical images around made sense in the old memory layout, but not with CBFS, in my opinion.
Agreed.
I have a prototype of the moving-code-around part of it done, on the QEmu target. It runs raminit from a cbfs file, linked to a fixed address within cbfs, which avoids weird compiler tricks. CBFS is only used to allow multiple such images to coexist without the bootblock having to know their addresses.
Is that the v3 model?
Open issues are: We need early rom mapping and CMOS access for all boards. So far, only the boards with failover layout are somewhat guaranteed to have code for that.
Early ROM mapping: Yes. Early CMOS access... hm maybe. Please note that CMOS access will not solve the issue of deciding which image to boot unless we decide to forbid clearing CMOS with a jumper. The information about which image part is newer needs to be somewhere in the ROM image. See my other mail in this thread for a bit more details.
Regards, Carl-Daniel
On 01.10.2009 09:44, Carl-Daniel Hailfinger wrote:
On 01.10.2009 09:09, Patrick Georgi wrote:
We need early rom mapping and CMOS access for all boards. So far, only the boards with failover layout are somewhat guaranteed to have code for that.
Early ROM mapping: Yes. Early CMOS access... hm maybe. Please note that CMOS access will not solve the issue of deciding which image to boot unless we decide to forbid clearing CMOS with a jumper. The information about which image part is newer needs to be somewhere in the ROM image. See my other mail in this thread for a bit more details.
Actually, the mail was not in this thread but rather in Subject: Re: [coreboot] [PATCH]Remove non-CBFS
Date: Thu, 01 Oct 2009 09:26:08 +0200
Sorry for the incorrect pointer.
Regards, Carl-Daniel
Am Donnerstag, den 01.10.2009, 09:44 +0200 schrieb Carl-Daniel Hailfinger:
- move everything but the decision stuff out of the bootblock (so it essentially becomes immutable across updates)
This means we either need a CBFS walker in ASM or compile it with ROMCC.
I have a CBFS walker in ASM, and I'd prefer using romcc for some things (eg. early HT init on K8).
Even if that is possible (and IIRC you already have code for this) it strikes me as a bad idea. I want to have as little asm code as possible and I want to keep ROMCC out of the CAR images.
ROMCC is bad if it's used for the entire ram init code. Early init is supposed to be a small piece of code, and that's what ROMCC is quite good at.
Others may disagree with me, but I thought I'd say this before the decision is finalized.
I won't force the issue - but there must be a better way than having 140 copies of "if cmos say good, run normal, otherwise run fallback" around. That's my main concern.
Having an immutable bootblock is only an attempt to have a more robust update mechanism. Given that I personally won't update systems without having recovery gear around, it doesn't actually affect me. But if we're trying to enable updates, I'd rather have them as safe as possible, and that's what this experiment is about.
- extend kconfig so it knows how to update existing images (by adding new files)
Sorry, I don't understand this. Did you mean the makefiles? I see no relation between fallback/normal and Kconfig.
If two images should be configurable in one pass, Kconfig must be adapted for that - and it won't be pretty.
I'd rather have the system build _one_ image in one pass, and allow the user to configure whether a new image is built, or an existing one is extended with a new image.
This issue is more about what we can express sensibly in Kconfig, than what the build system can do. The latter is more flexible, but it's outright lost without being told what it's supposed to do.
The idea is that Kconfig continues to build only one image, but allows to add to such an image later, when it's actually time to carry two images.
Ah. I always thought of Kconfig as a configuration system, not a build system.
Right, but the makefile will only build what can be configured, so they're really quite interdependent. I'm mixing up terminology there, I'm sorry about that.
I have a prototype of the moving-code-around part of it done, on the QEmu target. It runs raminit from a cbfs file, linked to a fixed address within cbfs, which avoids weird compiler tricks. CBFS is only used to allow multiple such images to coexist without the bootblock having to know their addresses.
Is that the v3 model?
The prototype has a ROMCC/assembly bootblock, and raminit in CBFS (where CAR would end up, too). So it's somewhat different from v3.
I started out from the QEmu decision code. In the end, it is an experiment, and it's mostly based around my opinions, as outlined above.
But the only thing I _really_ care about is getting rid of the jmp fallback_image junk in every single mainboard directory.
Early ROM mapping: Yes. Early CMOS access... hm maybe. Please note that CMOS access will not solve the issue of deciding which image to boot unless we decide to forbid clearing CMOS with a jumper. The information about which image part is newer needs to be somewhere in the ROM image. See my other mail in this thread for a bit more details.
While we need some other way to determine which is the newest image (ie. the one we'd preferably use), we also need a way to figure out that the newest version didn't actually work on the last attempt. I know no other place than CMOS to store such information (ie. mark boot as unclean, boot into coreboot stage, which marks boot as clean right before entering the payload - or maybe delegating that to the payload, not sure)
Patrick
On 01.10.2009 10:17, Patrick Georgi wrote:
Am Donnerstag, den 01.10.2009, 09:44 +0200 schrieb Carl-Daniel Hailfinger:
- move everything but the decision stuff out of the bootblock (so it essentially becomes immutable across updates)
This means we either need a CBFS walker in ASM or compile it with ROMCC.
I have a CBFS walker in ASM, and
I'd prefer using romcc for some things (eg. early HT init on K8).
Unless I'm mistaken, K8 HT init is done with gcc code in CAR in v3.
Even if that is possible (and IIRC you already have code for this) it strikes me as a bad idea. I want to have as little asm code as possible and I want to keep ROMCC out of the CAR images.
ROMCC is bad if it's used for the entire ram init code. Early init is supposed to be a small piece of code, and that's what ROMCC is quite good at.
I still worry about romcc bugs (like sometimes ignoring code lines if there is not enough whitespace before them) which I can't remember being fixed (mostly due to the ability to work around them).
Others may disagree with me, but I thought I'd say this before the decision is finalized.
I won't force the issue - but there must be a better way than having 140 copies of "if cmos say good, run normal, otherwise run fallback" around. That's my main concern.
OK, fully agreed. There is no need to duplicate (or even have 140 copies of) code which essentially never changes.
Having an immutable bootblock is only an attempt to have a more robust update mechanism. Given that I personally won't update systems without having recovery gear around, it doesn't actually affect me. But if we're trying to enable updates, I'd rather have them as safe as possible, and that's what this experiment is about.
I see your point.
- extend kconfig so it knows how to update existing images (by adding new files)
Sorry, I don't understand this. Did you mean the makefiles? I see no relation between fallback/normal and Kconfig.
If two images should be configurable in one pass, Kconfig must be adapted for that - and it won't be pretty.
True.
I'd rather have the system build _one_ image in one pass, and allow the user to configure whether a new image is built, or an existing one is extended with a new image.
Ah, that makes sense. Thanks for clarifying. I agree with this.
This issue is more about what we can express sensibly in Kconfig, than what the build system can do. The latter is more flexible, but it's outright lost without being told what it's supposed to do.
True.
The idea is that Kconfig continues to build only one image, but allows to add to such an image later, when it's actually time to carry two images.
Ah. I always thought of Kconfig as a configuration system, not a build system.
Right, but the makefile will only build what can be configured, so they're really quite interdependent. I'm mixing up terminology there, I'm sorry about that.
No problem. You explained everything in your followup mail and that's what counts. ;-)
I have a prototype of the moving-code-around part of it done, on the QEmu target. It runs raminit from a cbfs file, linked to a fixed address within cbfs, which avoids weird compiler tricks. CBFS is only used to allow multiple such images to coexist without the bootblock having to know their addresses.
Is that the v3 model?
The prototype has a ROMCC/assembly bootblock, and raminit in CBFS (where CAR would end up, too). So it's somewhat different from v3.
I started out from the QEmu decision code. In the end, it is an experiment, and it's mostly based around my opinions, as outlined above.
Given the current state of the tree, your plans are definitely a hige improvement. I can still send patches to make startup resemble v3 more closely on top of this.
But the only thing I _really_ care about is getting rid of the jmp fallback_image junk in every single mainboard directory.
Yes!
Early ROM mapping: Yes. Early CMOS access... hm maybe. Please note that CMOS access will not solve the issue of deciding which image to boot unless we decide to forbid clearing CMOS with a jumper. The information about which image part is newer needs to be somewhere in the ROM image. See my other mail in this thread for a bit more details.
While we need some other way to determine which is the newest image (ie. the one we'd preferably use), we also need a way to figure out that the newest version didn't actually work on the last attempt. I know no other place than CMOS to store such information (ie. mark boot as unclean, boot into coreboot stage, which marks boot as clean right before entering the payload - or maybe delegating that to the payload, not sure)
Right. So we need two variables: - One variable (in ROM) says which image is newer - One variable (in CMOS/NVRAM) helps decide whether to boot the new or the old image.
Regards, Carl-Daniel
On Thu, Oct 01, 2009 at 09:09:50AM +0200, Patrick Georgi wrote:
My plan for it, pending any better solution:
- unify the decision stuff into a single place
- move everything but the decision stuff out of the bootblock (so it essentially becomes immutable across updates)
- extend kconfig so it knows how to update existing images (by adding new files)
- somehow make flashrom smart enough to safely update the flash
Thanks - that sounds like a big improvement.
Open issues are: We need early rom mapping and CMOS access for all boards. So far, only the boards with failover layout are somewhat guaranteed to have code for that.
Proprietary BIOS have a cmos variable for a similar purpose - 0x0f (RESET CODE). Coreboot could probably use the same variable - defining one variable for all boards is probably simpler than having to define it on every board.
-Kevin
Am 02.10.2009 01:58, schrieb Kevin O'Connor:
Proprietary BIOS have a cmos variable for a similar purpose - 0x0f (RESET CODE). Coreboot could probably use the same variable - defining one variable for all boards is probably simpler than having to define it on every board.
That's not the issue, and our cmos.layout handling already takes care of writing to the "right" location without more effort. We need to have access to CMOS before CAR or raminit, or anything interesting happens, really. And I'm not sure if our code supports this everywhere already.
Patrick
On 02.10.2009 11:54, Patrick Georgi wrote:
We need to have access to CMOS before CAR or raminit, or anything interesting happens, really. And I'm not sure if our code supports this everywhere already.
IMHO access to CMOS before CAR is unnecessarily painful and I'd like to keep that out of the targets which don't need it (VIA/AMD).
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 02.10.2009 11:54, Patrick Georgi wrote:
We need to have access to CMOS before CAR or raminit, or anything interesting happens, really. And I'm not sure if our code supports this everywhere already.
IMHO access to CMOS before CAR is unnecessarily painful and I'd like to keep that out of the targets which don't need it (VIA/AMD).
Then how are we going to update CAR code in case a new CPU revision needs an update while still keeping normal/fallback alive?
Stefan
On 03.10.2009 18:08, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 02.10.2009 11:54, Patrick Georgi wrote:
We need to have access to CMOS before CAR or raminit, or anything interesting happens, really. And I'm not sure if our code supports this everywhere already.
IMHO access to CMOS before CAR is unnecessarily painful and I'd like to keep that out of the targets which don't need it (VIA/AMD).
Then how are we going to update CAR code in case a new CPU revision needs an update while still keeping normal/fallback alive?
This has never happened with any AMD or VIA CPU. And I highly doubt it happened with Intel CPUs. So why should we design for such an event?
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
IMHO access to CMOS before CAR is unnecessarily painful
Why?
//Peter
On 03.10.2009 18:34, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
IMHO access to CMOS before CAR is unnecessarily painful
Why?
Because you either introduce a dependency on ROMCC or you need additional assembler code. mmxstack/xmmstack+GCC is not an option here because a microcode update may be required before using floating point stuff.
If I had stood up a year ago and said "Let's introduce a ROMCC dependency for all CAR boards", we would have seen a major flamewar. If I had proposed to rewrite our CMOS code in assembler, the response would not have been enthusiastic either.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
IMHO access to CMOS before CAR is unnecessarily painful
Why?
Because you either introduce a dependency on ROMCC or you need additional assembler code.
I love Patrick's idea about generating macros from cmos.layout. With that, the additional assembler code would amount to maybe 15 instructions. Far from painful to me.
//Peter
Am Samstag, den 03.10.2009, 20:03 +0200 schrieb Peter Stuge:
Because you either introduce a dependency on ROMCC or you need additional assembler code.
I love Patrick's idea about generating macros from cmos.layout. With that, the additional assembler code would amount to maybe 15 instructions. Far from painful to me.
The thing is, there's code that isn't that pretty in assembly. K8 HT init comes to mind (necessary for rom mapping), so there is a use case for romcc in that model anyway.
But that isn't all that bad in my opinion: 1. we had much more trouble with gcc than with romcc.. If anything, gcc has to go ;-) 2. We're talking about a tiny piece of code here. The smaller, the better, so that even good, slow, unscalable romcc won't be too much of a burden. 3. We'll be using romcc for various projects anyway (eg. serialICE) - it's far from that, so we can use it where appropriate.
We have issues with romcc currently because we use it on a large set of files from many separate parts of the tree (the various bridges etc), and suffer from its constraints.
What I don't know is, do we require any chipset setup to _reach_ CMOS? Accessing it will be trivial, no matter if assembly or romcc.
Patrick
Patrick Georgi wrote:
What I don't know is, do we require any chipset setup to _reach_ CMOS?
It's not generally in the CPU, so some setup may be needed. On the other hand, maybe 70/71 are decoded correctly on power up, just like flash access?
//Peter
Peter Stuge wrote:
Patrick Georgi wrote:
What I don't know is, do we require any chipset setup to _reach_ CMOS?
It's not generally in the CPU, so some setup may be needed. On the other hand, maybe 70/71 are decoded correctly on power up, just like flash access?
It's not like there is a spec or anything, but most of the PC AT junk in IO space will be accessible from first fetch. Disassemble the early portions of some AMI or Phoenix BIOSes, and you'll see accesses to things like CMOS in the first few instructions. Legacy accesses have to die somewhere subtractively, and the RTC usually is in that path.
Tom
On 01.10.2009 00:32, ron minnich wrote:
can anyone even buy an m57sli any more? Was it an unfortunate mistake -- never repeated -- that FLASH was not directly accessible? If the m57sli is an exception and we'll never see this problem again, I say we drop it. Copying all of flash into ram sounds bad. If we have to cope with this problem in future, maybe we're stuck with accessor functions.
But FLASH is so slow I doubt that the cost of an accessor function is going to kill us. Function calls run in nanoseconds, and if SPI really is only 40 MB/sec., then that's 25 ns/byte.
The accessor function has the disadvantage of ruining readability of the code, and it also has to perform these extremely slow accesses every time someone walks the CBFS image.
AFAIK the M57SLI worst case read performance is ~400 kB/s, and the best case is ~855 kB/s. Each one-byte read access to flash needs at least 2.5 us (microseconds), and a three-byte read access needs at least 3.5 us. If your flash chip can handle 33 MHz with the normal read command (instead of the fast read command), flash access latency will be cut in half and data rate will be doubled.
While using accessor functions look somewhat beneficial from a performance standpoint, using accessor functions to run the lzma decompressor is waaaaay slower (I think by at least a factor of 4) than copying the uncompressed code to RAMand decompressing it there.
My suggestion would be to drop support for these large flash chips on M57SLI for now and use the copy-to-RAM mechanism once someone complains. I think Harald Gutmann has such a board with big flash.
Regads, Carl-Daniel
On Thursday 01 October 2009 01:31:33 Carl-Daniel Hailfinger wrote:
While using accessor functions look somewhat beneficial from a performance standpoint, using accessor functions to run the lzma decompressor is waaaaay slower (I think by at least a factor of 4) than copying the uncompressed code to RAMand decompressing it there.
My suggestion would be to drop support for these large flash chips on M57SLI for now and use the copy-to-RAM mechanism once someone complains. I think Harald Gutmann has such a board with big flash.
Yes, you're right I've that board with a 4MB (32Mbit) chip, but right now I just use a 512kb chip as I never got a kernel image working directly from flash.
Regads, Carl-Daniel
Regards, Harald
Index: src/devices/pci_rom.c
--- src/devices/pci_rom.c (Revision 4696) +++ src/devices/pci_rom.c (Arbeitskopie) @@ -35,17 +35,15 @@ struct rom_header *rom_header; struct pci_data *rom_data;
if (dev->on_mainboard) { /* this is here as a legacy path. We hope it goes away soon. Users should not have to
The legacy path is the non-CBFS path and should disappear
-#if CONFIG_CBFS == 1 -# if CONFIG_USE_FALLBACK_IMAGE == 1 +#if CONFIG_USE_FALLBACK_IMAGE == 1 str_coreboot_ram_name: .string "fallback/coreboot_ram" -# else +#else str_coreboot_ram_name: .string "normal/coreboot_ram" -# endif #endif
Since normal and failover aren't supported with CBFS, can they disappear too?
I consider the tree ready for this as there are no known bugs anymore (except the one fixed by that other patch). Speak up if you disagree (I intend to wait with committing this patch until saturday evening CEST)
The sooner the better. Non-CBFS is already bit rotting.
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Acked-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
Myles Watson wrote:
-#if CONFIG_CBFS == 1 -# if CONFIG_USE_FALLBACK_IMAGE == 1 +#if CONFIG_USE_FALLBACK_IMAGE == 1 str_coreboot_ram_name: .string "fallback/coreboot_ram" -# else +#else str_coreboot_ram_name: .string "normal/coreboot_ram" -# endif #endif
Since normal and failover aren't supported with CBFS, can they disappear too?
No, we should get that back to life with CBFS asap.. it's one of coreboot's key features..
Stefan
Since normal and failover aren't supported with CBFS, can they disappear too?
No, we should get that back to life with CBFS asap.. it's one of coreboot's key features..
Good to know. It seemed like it was being slowly removed.
I'm interested to see how it integrates with Kconfig. It's not obvious to me how it will work.
Thanks, Myles
On Thu, Oct 01, 2009 at 12:51:17AM +0200, Stefan Reinauer wrote:
Myles Watson wrote:
Since normal and failover aren't supported with CBFS, can they disappear too?
No, we should get that back to life with CBFS asap.. it's one of coreboot's key features..
What's the use case for normal/failover? I always envisioned it as a software implementation of a "bios savior". If so, building in a serialice shell might be a simpler solution.
Am I missing an important use-case?
-Kevin
On Wed, Sep 30, 2009 at 4:23 PM, Kevin O'Connor kevin@koconnor.net wrote:
What's the use case for normal/failover? I always envisioned it as a software implementation of a "bios savior". If so, building in a serialice shell might be a simpler solution.
Am I missing an important use-case?
I'm flashing 1024 machines. power fails midway through. bad.
I flash a new bios that has worked in test. It fails on 10% of the machines, in ways that could not be predicted because 10% of my machines have a manufacturing defect. This is what happened to me. Fallback saved me.
There are lots of use cases. It's why many vendors ship with a fallback.
ron
On Wed, Sep 30, 2009 at 04:26:44PM -0700, ron minnich wrote:
On Wed, Sep 30, 2009 at 4:23 PM, Kevin O'Connor kevin@koconnor.net wrote:
What's the use case for normal/failover? I always envisioned it as a software implementation of a "bios savior". If so, building in a serialice shell might be a simpler solution.
Am I missing an important use-case?
I'm flashing 1024 machines. power fails midway through. bad.
Ouch. So, I guess we're saying it's a software "bios savior" that doesn't require one to go hitting 1000 switches?
As an aside, to protect against a power failure, flashrom is going to need to know that it shouldn't reflash the "fallback" parts of the image.
I flash a new bios that has worked in test. It fails on 10% of the machines, in ways that could not be predicted because 10% of my machines have a manufacturing defect. This is what happened to me. Fallback saved me.
Ouch - I guess hooking up a serialice console to 100 machines isn't an appealing alternative.
Just to throw my 2cents in -- the coreboot fallback/normal thing has been thoroughly confusing to me. If this is being re-implemented it would be nice to see this done in a way that makes sense to users.
One suggestion I have - assuming my "bios savior" analogy is correct - would be to truly break up the fallback and normal parts. A user that wants fallback/normal should download two separate copies of coreboot-v2 into two separate directories, and then run "make config ; make" in both separate directories. The "normal" config would take the directory location of the "fallback" cbfs image, copy it into its local directory, and then just add the cbfs files it needs.
In particular, I'd like to be able to go into my "normal" directory and run "svn up", "make", and then "flashrom" - and be fairly confident that I didn't just blow up my image. As near as I can tell, the current fallback/normal thing recompiles both fallback and normal images, and there's a pretty good chance that both images are hosed when code changes are made. (Of course, as I said before, fallback/normal has me perplexed, so maybe I just missed the boat.)
-Kevin
Kevin O'Connor wrote:
As an aside, to protect against a power failure, flashrom is going to need to know that it shouldn't reflash the "fallback" parts of the image.
Yes. flashrom should know CBFS.
truly break up the fallback and normal parts.
I see a few problem with normal and fallback as they have been in v2 previously;
It was not well understood how to produce them. It was not well understood how they were combined. And finally it was not well understood how one of the two were selected.
CBFS and Kconfig fixes the hard parts; the first two.
I see cbfstool being a crucial part of safe updates. Initially cbfstool might have to be run manually (or even just flashrom) but we should look into how Kconfig and the build system can take an existing CBFS as input, and only build/replace the normal part.
In particular, I'd like to be able to go into my "normal" directory and run "svn up", "make", and then "flashrom" - and be fairly confident that I didn't just blow up my image.
Two directories strikes me as pretty complicated but I do get your point - it should be really easy to rebuild and flash normal, without touching anything else.
//Peter
On 01.10.2009 01:57, Kevin O'Connor wrote:
As an aside, to protect against a power failure, flashrom is going to need to know that it shouldn't reflash the "fallback" parts of the image.
flashrom currently has a patch review bottleneck, so partial reflashing is stalled.
Just to throw my 2cents in -- the coreboot fallback/normal thing has been thoroughly confusing to me. If this is being re-implemented it would be nice to see this done in a way that makes sense to users.
One suggestion I have - assuming my "bios savior" analogy is correct - would be to truly break up the fallback and normal parts. A user that wants fallback/normal should download two separate copies of coreboot-v2 into two separate directories, and then run "make config ; make" in both separate directories. The "normal" config would take the directory location of the "fallback" cbfs image, copy it into its local directory, and then just add the cbfs files it needs.
In particular, I'd like to be able to go into my "normal" directory and run "svn up", "make", and then "flashrom" - and be fairly confident that I didn't just blow up my image. As near as I can tell, the current fallback/normal thing recompiles both fallback and normal images, and there's a pretty good chance that both images are hosed when code changes are made.
You do have a point. In v3, you have an invariant boot block (which contains the CAR code, serial code, generic PCI accessor functions and printk) and one "initram" file and one "stage2" file. initram initializes RAM, stage2 is roughly what coreboot_ram does now. AFAIK the v3 build process only builds a "normal" image.
Two problem areas need to be looked at: 1. Can the new build reuse the old bootblock? Does the new build have to know the old bootblock? 2. How do you merge old and new images?
1. is trivial to integrate in the v3 build and bootblock reuse is easy. Of course you'd want to replace the bootblock (and the rest of the ROM) if some bootblock code changed.
2. is a bit more problematic regardless of whether you have v2 or v3. If you don't want to reflash the old parts of the image, you can't rename them either. If the old part was called "fallback", it will still be called "fallback" after flashing some new parts into the ROM. That means each time you reflash, the new part's name will be the opposite of the old part's name. Of course, with such a system, calling these things "fallback" and "normal" makes no sense anymore. After all, we always want to boot the newly flashed image first and the name doesn't tell us which one is new. There are solutions to this, but the ones I see will either require to change the CBFS data structure (LAR3 or CBFS2 anyone?) or put a horrible hack on top of CBFS. Maybe someone else has better ideas.
Now on to flashrom. You suggested that flashrom should understand CBFS and only flash the newly added parts of the image. (If I misunderstood you, please accept my apologies.) Given that flashrom already has a generic image layout feature, I propose to have cbfstool spit out an image layout file which is then read by flashrom. This makes flashrom independent of CBFS and that's a good thing (think upgrade).
Regards, Carl-Daniel
On Thu, Oct 01, 2009 at 09:26:08AM +0200, Carl-Daniel Hailfinger wrote:
In particular, I'd like to be able to go into my "normal" directory and run "svn up", "make", and then "flashrom" - and be fairly confident that I didn't just blow up my image.
[...]
Two problem areas need to be looked at:
- Can the new build reuse the old bootblock? Does the new build have to
know the old bootblock? 2. How do you merge old and new images?
[...]
- is a bit more problematic regardless of whether you have v2 or v3. If
you don't want to reflash the old parts of the image, you can't rename them either. If the old part was called "fallback", it will still be called "fallback" after flashing some new parts into the ROM. That means each time you reflash, the new part's name will be the opposite of the old part's name. Of course, with such a system, calling these things "fallback" and "normal" makes no sense anymore. After all, we always want to boot the newly flashed image first and the name doesn't tell us which one is new.
I'd always want to flash and boot the image I put in the "normal" directory. I don't want to rename "fallback" - I don't want to change it at all.
-Kevin
Carl-Daniel Hailfinger wrote:
Given that flashrom already has a generic image layout feature, I propose to have cbfstool spit out an image layout file which is then read by flashrom. This makes flashrom independent of CBFS and that's a good thing (think upgrade).
This is trivial to implement and might be a good first step, but it's absolutely horrible from a usability perspective;
The user would need to keep track of and understand no less than two tools, AND an intermediary layout file, in order to perform the single task of partial firmware update.
I think it is quite neccessary for flashrom to understand CBFS (and LAR, for v3 users).
//Peter
[adding flashrom@flashrom.org to CC]
On 03.10.2009 18:40, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
Given that flashrom already has a generic image layout feature, I propose to have cbfstool spit out an image layout file which is then read by flashrom. This makes flashrom independent of CBFS and that's a good thing (think upgrade).
This is trivial to implement and might be a good first step, but it's absolutely horrible from a usability perspective;
The user would need to keep track of and understand no less than two tools, AND an intermediary layout file, in order to perform the single task of partial firmware update.
The user has to understand cbfstool and lar anyway right now if he/she wants to do anything useful with fallback/normal. The user also has to understand flashrom to flash the resulting image. The user will not directly inspect the ROM image, nor will he/she directly inspect the layout file.
I think it is quite neccessary for flashrom to understand CBFS (and LAR, for v3 users).
What about WPH and other formats from proprietary BIOS vendors? Flashrom has more users who deal with WPH and related formats than it has users who deal with CBFS or LAR.
IIRC the Unix philosophy is roughly "Create programs that do one thing and do it well. Use simple programs together." I like that philosophy. One option would be to have cbfstool and lar execute the flashrom binary.
Regards, Carl-Daniel
Kevin O'Connor wrote:
On Thu, Oct 01, 2009 at 12:51:17AM +0200, Stefan Reinauer wrote:
Myles Watson wrote:
Since normal and failover aren't supported with CBFS, can they disappear too?
No, we should get that back to life with CBFS asap.. it's one of coreboot's key features..
What's the use case for normal/failover? I always envisioned it as a software implementation of a "bios savior". If so, building in a serialice shell might be a simpler solution.
SerialICE is more or less a development tool.. it won't help you with misflashed units in the field.
Safe updates and safe recovery is the key.
Details are quite open though, the fallback image could carry some kind of shell, while the "real one" goes SeaBIOS; depending on how people want to boot, and how they want to recover.
Stefan
Stefan Reinauer wrote:
Safe updates and safe recovery is the key.
Details are quite open though, the fallback image could carry some kind of shell,
Maybe this touches on the panic room.
depending on how people want to boot, and how they want to recover.
Yeah, this is important.
A panic room should not be too ambitious, or it might not be quite as reliable as we would like. If very simple, it may not be a good choice also for fallback.
//Peter
The fallback should work like the normal does. What you want, if things go wrong, is something that works as much like what you're used to as possible, so that you can recover easily.
The worst thing you can do, if things go wrong, is drop users into an unfamiliar environment that sends them scurrying around looking for the manuals.
The panic room should look just like the normal room, save it has a big sign that says "Don't Panic".
ron
Am Mittwoch, den 30.09.2009, 15:41 -0600 schrieb Myles Watson:
Index: src/devices/pci_rom.c
--- src/devices/pci_rom.c (Revision 4696) +++ src/devices/pci_rom.c (Arbeitskopie) @@ -35,17 +35,15 @@ struct rom_header *rom_header; struct pci_data *rom_data;
if (dev->on_mainboard) { /* this is here as a legacy path. We hope it goes away soon. Users should not have to
The legacy path is the non-CBFS path and should disappear
The comment is wrong. dev->on_mainboard is set by the CBFS loader a couple of lines above. This distinction is mostly "ROM in flash" vs. "ROM in option ROM" now.
Users won't have to calculate addresses with CBFS, so it's fine. I'll kill the comment in the commit, thanks for the pointer!
-#if CONFIG_CBFS == 1 -# if CONFIG_USE_FALLBACK_IMAGE == 1 +#if CONFIG_USE_FALLBACK_IMAGE == 1 str_coreboot_ram_name: .string "fallback/coreboot_ram" -# else +#else str_coreboot_ram_name: .string "normal/coreboot_ram" -# endif #endif
Since normal and failover aren't supported with CBFS, can they disappear too?
They are supported with CBFS on newconfig. It's Kconfig that doesn't support these, but newconfig will have to stay for a while, and so do these.
Patrick
Patrick Georgi wrote:
Hi,
attached patch removes:
- CONFIG_CBFS
- anything that's conditional on CONFIG_CBFS == 0
- files that were only included for CONFIG_CBFS == 0
In particular:
- elfboot
- stream boot code
- mini-filo and filesystems (depends on stream boot code)
After this patch, there is no way to build an image that is not using CBFS anymore.
I might not have caught everything, but an abuild run over everything built fine, and there is no mention of "CBFS" in the tree anymore that doesn't belong there. Kconfig is almost not affected, as it's CBFS-only, anyway. I only had to remove the CBFS configuration variable that defaulted to "true".
I consider the tree ready for this as there are no known bugs anymore (except the one fixed by that other patch). Speak up if you disagree (I intend to wait with committing this patch until saturday evening CEST)
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Acked-by: Stefan Reinauer stepan@coresystems.de
-
Carl-Daniel Hailfinger -
Harald Gutmann -
Kevin O'Connor -
Myles Watson -
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Tom Sylla