Attached. This patch lets us create XIP stages for cbfs.
ron
Attached. This patch lets us create XIP stages for cbfs.
I'd like to see the picture of what you're imagining here. I thought CBFS was designed to grow in only one direction. Are you going to have to add components in a certain order to make this work? I don't see where you're padding or inserting blank areas.
Thanks, Myles
On Mon, May 4, 2009 at 8:55 PM, Myles Watson mylesgw@gmail.com wrote:
Attached. This patch lets us create XIP stages for cbfs.
I'd like to see the picture of what you're imagining here. I thought CBFS was designed to grow in only one direction. Are you going to have to add components in a certain order to make this work? I don't see where you're padding or inserting blank areas.
no, cbfs files can be sparse. There is nothing in the design that requires that all entries be contiguous. In fact, given that remove exists, cbfs has to allow holes.
The padding is implicit in the way the fs code works. The code allocates a ROM image that is the size of the actual ROM, and initializes that ROM image with empty values. To add a file, it simply installs a cbfs file header at a location that is aligned with rom->header->align. The header has a type and a length.
All that this XIP code patch does is allow cbfs to install a cbfs file in the archive at an offset such that XIP will work for that file. That's it. It's a very simple addition.
There is actually no change to the find code in src/lib, in fact; that code also walks all of rom, in strides of 'align'. If we ever worry that 16 bytes is too small an increment we can change it at the command line, when we create a cbfs archive.
And, no, you don't have to add components in any particular order. The only requirement, in fact, is that XIP components have room to fit. That's about it.
ron
Am 05.05.2009 06:55, schrieb ron minnich:
There is actually no change to the find code in src/lib, in fact; that code also walks all of rom, in strides of 'align'. If we ever worry that 16 bytes is too small an increment we can change it at the command line, when we create a cbfs archive.
In that case, I'll have to revert a change made to lib/cbfs.c to walk the chain of files (instead of a brute force walk through the whole image). SeaBIOS will have to do likewise.
And that means, that we either need some cache about file locations in the readers, or certain operations will be very expensive (eg. SeaBIOS looking for all kind of pci*roms)
Patrick
On 05.05.2009 09:42, Patrick Georgi wrote:
Am 05.05.2009 06:55, schrieb ron minnich:
There is actually no change to the find code in src/lib, in fact; that code also walks all of rom, in strides of 'align'. If we ever worry that 16 bytes is too small an increment we can change it at the command line, when we create a cbfs archive.
In that case, I'll have to revert a change made to lib/cbfs.c to walk the chain of files (instead of a brute force walk through the whole image). SeaBIOS will have to do likewise.
And that means, that we either need some cache about file locations in the readers, or certain operations will be very expensive (eg. SeaBIOS looking for all kind of pci*roms)
Doesn't zerofill solve that problem?
Regards, Carl-Daniel
Am 05.05.2009 09:48, schrieb Carl-Daniel Hailfinger:
On 05.05.2009 09:42, Patrick Georgi wrote:
Am 05.05.2009 06:55, schrieb ron minnich:
There is actually no change to the find code in src/lib, in fact; that code also walks all of rom, in strides of 'align'. If we ever worry that 16 bytes is too small an increment we can change it at the command line, when we create a cbfs archive.
In that case, I'll have to revert a change made to lib/cbfs.c to walk the chain of files (instead of a brute force walk through the whole image). SeaBIOS will have to do likewise.
And that means, that we either need some cache about file locations in the readers, or certain operations will be very expensive (eg. SeaBIOS looking for all kind of pci*roms)
Doesn't zerofill solve that problem?
No, esp. with XIP images, we have no idea where images start and end. We have to look through the entire image for that.
I have some code for a "next" field that builds a chain without relying on "offset" and "len" (as the current chain walker do). That helps with a scenario like having two option roms right after another at the beginning of the ROM. The current walker would be confused by that. (it always looks for the next file header after the current file's data)
The "next" field has the disadvantage that we can't simply hot-update anymore, as we'd have to change data (instead of merely adding it).
And solutions like "use the 'unwritten bytes' marker (eg. 0xffffffff) as end-of-chain identifier", so it can be overwritten feel quite unclean, too.
Patrick
On Tue, May 5, 2009 at 12:59 AM, Patrick Georgi patrick@georgi-clan.de wrote:
I have some code for a "next" field that builds a chain without relying on "offset" and "len" (as the current chain walker do). That helps with a scenario like having two option roms right after another at the beginning of the ROM. The current walker would be confused by that. (it always looks for the next file header after the current file's data)
I am missing the point. Are they two cbfs files or ... if they are two cbfs files, then there is no problem. The case that the option ROMs are not part of cbfs? Or there are two option ROMs in one CBFS file?
it's too early in the morning for me :-)
ron
Am 05.05.2009 17:12, schrieb ron minnich:
On Tue, May 5, 2009 at 12:59 AM, Patrick Georgipatrick@georgi-clan.de wrote:
I have some code for a "next" field that builds a chain without relying on "offset" and "len" (as the current chain walker do). That helps with a scenario like having two option roms right after another at the beginning of the ROM. The current walker would be confused by that. (it always looks for the next file header after the current file's data)
I am missing the point. Are they two cbfs files or ... if they are two cbfs files, then there is no problem. The case that the option ROMs are not part of cbfs? Or there are two option ROMs in one CBFS file?
Consider the following case: The system has _two_ images it requires at fixed addresses right after another. We don't process these images (eg. EC firmware) ourselves, but have to take care that they're at the right spot (similar to your XIP stuff). We want to keep the images as two entries in cbfs (as they have different release cycles)
The layout would look like this:
file1-data | file2-data
The current algorithm in coreboot and seabios says to walk the chain by taking the current cbfs_file address, adding the offset (so you're at the beginning of the file in question), and adding the file length (so you're at the first byte after the file in question). There, the current algorithm expects a new cbfs_file header.
But there's already file2's data in the way. Oops.
With the next field, we decouple the file location and the cbfs_file location completely. offset/len point to the file data, next points to the next header.
Patrick
On Tue, May 5, 2009 at 8:26 AM, Patrick Georgi patrick@georgi-clan.de wrote:
Consider the following case: The system has _two_ images it requires at fixed addresses right after another. We don't process these images (eg. EC firmware) ourselves, but have to take care that they're at the right spot (similar to your XIP stuff). We want to keep the images as two entries in cbfs (as they have different release cycles)
The layout would look like this:
file1-data | file2-data
The current algorithm in coreboot and seabios says to walk the chain by taking the current cbfs_file address, adding the offset (so you're at the beginning of the file in question), and adding the file length (so you're at the first byte after the file in question). There, the current algorithm expects a new cbfs_file header.
But there's already file2's data in the way. Oops.
With the next field, we decouple the file location and the cbfs_file location completely. offset/len point to the file data, next points to the next header.
Thanks, I see it now.
So this scenario requires that we have two cbfs file headers, and data somewhere else, not necessarily contiguous with the header. Does the cbfstool currently create this kind of image?
ron
On Tue, May 5, 2009 at 9:33 AM, ron minnich rminnich@gmail.com wrote:
On Tue, May 5, 2009 at 8:26 AM, Patrick Georgi patrick@georgi-clan.de wrote:
Consider the following case: The system has _two_ images it requires at fixed addresses right after another. We don't process these images (eg. EC firmware) ourselves, but have to take care that they're at the right spot (similar to your XIP stuff). We want to keep the images as two entries in cbfs (as they have different release cycles)
The layout would look like this:
file1-data | file2-data
The current algorithm in coreboot and seabios says to walk the chain by taking the current cbfs_file address, adding the offset (so you're at the beginning of the file in question), and adding the file length (so you're at the first byte after the file in question). There, the current algorithm expects a new cbfs_file header.
But there's already file2's data in the way. Oops.
With the next field, we decouple the file location and the cbfs_file location completely. offset/len point to the file data, next points to the next header.
Thanks, I see it now.
So this scenario requires that we have two cbfs file headers, and data somewhere else, not necessarily contiguous with the header. Does the cbfstool currently create this kind of image?
I don't think so.
I think CBFS requires the header to be contiguous with the data. We could change it, but that seems like a fundamental redesign.
It would be easier to walk if all the headers were contiguous.
Myles
On Tue, May 5, 2009 at 8:36 AM, Myles Watson mylesgw@gmail.com wrote:
On Tue, May 5, 2009 at 9:33 AM, ron minnich rminnich@gmail.com wrote:
So this scenario requires that we have two cbfs file headers, and data somewhere else, not necessarily contiguous with the header. Does the cbfstool currently create this kind of image?
I don't think so.
I don't think it does either.
I think CBFS requires the header to be contiguous with the data. We could change it, but that seems like a fundamental redesign.
Agreed.
It would be easier to walk if all the headers were contiguous.
Agreed. But then you have to leave room somewhere for all possible headers, which means you have to reserve part of flash for headers only, which is something I would rather not do.
Many of the proposed changes will result in balooning cbfs code, which I think we should avoid. I'm not even sure that arbitrary file name lengths (which we have now) are a good idea :-)
ron
On Tue, May 5, 2009 at 9:43 AM, ron minnich rminnich@gmail.com wrote:
On Tue, May 5, 2009 at 8:36 AM, Myles Watson mylesgw@gmail.com wrote:
On Tue, May 5, 2009 at 9:33 AM, ron minnich rminnich@gmail.com wrote:
So this scenario requires that we have two cbfs file headers, and data somewhere else, not necessarily contiguous with the header. Does the cbfstool currently create this kind of image?
I don't think so.
I don't think it does either.
I think CBFS requires the header to be contiguous with the data. We could change it, but that seems like a fundamental redesign.
Agreed.
It would be easier to walk if all the headers were contiguous.
Agreed. But then you have to leave room somewhere for all possible headers, which means you have to reserve part of flash for headers only, which is something I would rather not do.
Yes.
Many of the proposed changes will result in balooning cbfs code, which I think we should avoid. I'm not even sure that arbitrary file name lengths (which we have now) are a good idea :-)
I agree. I think 16 bytes could be plenty...32 if someone complains that there aren't enough file names in 16 characters.
Myles
Am 05.05.2009 17:33, schrieb ron minnich:
So this scenario requires that we have two cbfs file headers, and data somewhere else, not necessarily contiguous with the header. Does the cbfstool currently create this kind of image?
Right now, it isn't able to. Without your patch, it isn't even able to put some data at a fixed address, so that patch is the first step in that direction.
Patrick
On 05.05.2009 06:55, ron minnich wrote:
There is actually no change to the find code in src/lib, in fact; that code also walks all of rom, in strides of 'align'.
Didn't we decide in v3 that walking all of ROM was a bad idea after that method (instead of skipping ahead based on headers) triggered too many false positives? Remember funny constructs like
/* I hope the compiler does not optimize this */ char *magic = "L" + "ARCHIVE"
What did I miss?
Regards, Carl-Daniel
On Tue, May 5, 2009 at 12:58 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 05.05.2009 06:55, ron minnich wrote:
There is actually no change to the find code in src/lib, in fact; that code also walks all of rom, in strides of 'align'.
Didn't we decide in v3 that walking all of ROM was a bad idea after that method (instead of skipping ahead based on headers) triggered too many false positives? Remember funny constructs like
/* I hope the compiler does not optimize this */ char *magic = "L" + "ARCHIVE"
What did I miss?
You didn't miss anything. It's a bug in the current cbfs walking code that I noticed last night.
Fix is simple: use Patrick's 'next' pointer or, when the code sees a valid file, it should skip to the end of that file and keep looking -- at which point it is likely to find another file or a non-magic value.
After this discussion I am thinking his next pointer is a good idea. ron
-----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] On Mon, May 4, 2009 at 8:55 PM, Myles Watson mylesgw@gmail.com wrote:
Attached. This patch lets us create XIP stages for cbfs.
I'd like to see the picture of what you're imagining here. I thought
CBFS
was designed to grow in only one direction. Are you going to have to
add
components in a certain order to make this work? I don't see where
you're
padding or inserting blank areas.
no, cbfs files can be sparse. There is nothing in the design that requires that all entries be contiguous. In fact, given that remove exists, cbfs has to allow holes.
Someone needs to fix remove then. Right now it moves all entries after it and zeroes the new space. I guess most of my confusion came from the implementation/design gap.
Thanks, Myles
On Tue, May 5, 2009 at 5:29 AM, Myles Watson mylesgw@gmail.com wrote:
Someone needs to fix remove then. Right now it moves all entries after it and zeroes the new space. I guess most of my confusion came from the implementation/design gap.
I think it was my confusion, not yours :-)
But I think we have to have clean support for XIP in ROM, which means we have to have a way for cbfs to place a block of code in a designated place. I like the idea of having the ROM stages visible in cbfs.
If we are certain we don't need XIP then we don't need this patch. But if we have XIP we can remove some fairly confusing __asm__ code in failover, as well as the attendant load scripts. Also, since the stage header has the entry point as well, we get rid of the need to have a reset vector at the end of the normal and failover ROM images -- a much cleaner way to go.
Some suggestions: - adopt a coarser granularity. Were we to adopt, e.g., 512B as a block size, then at most the walking code would have to check 4096 items on even a 2 Mbyte ROM (as opposed to the current 128K items) - zero fill - NEXT pointer
All of these will work.
ron
On Tue, May 5, 2009 at 9:06 AM, ron minnich rminnich@gmail.com wrote:
On Tue, May 5, 2009 at 5:29 AM, Myles Watson mylesgw@gmail.com wrote:
Someone needs to fix remove then. Right now it moves all entries after it and zeroes the new space. I guess most of my confusion came from the implementation/design gap.
I think it was my confusion, not yours :-)
But I think we have to have clean support for XIP in ROM, which means we have to have a way for cbfs to place a block of code in a designated place.
So can we force the compiler to make everything inside a block relative so that it can be position-independent?
I like the idea of having the ROM stages visible in cbfs.
So do I.
If we are certain we don't need XIP then we don't need this patch. But if we have XIP we can remove some fairly confusing __asm__ code in failover, as well as the attendant load scripts.
Does a normal image need to be XIP?
Also, since the stage header has the entry point as well, we get rid of the need to have a reset vector at the end of the normal and failover ROM images -- a much cleaner way to go.
Yes.
Some suggestions:
- adopt a coarser granularity. Were we to adopt, e.g., 512B as a block
size, then at most the walking code would have to check 4096 items on even a 2 Mbyte ROM (as opposed to the current 128K items)
- zero fill
- NEXT pointer
All of these will work.
I think this is the easy part. The harder problems have to do with what we want to allow to be constrained to a specific location. The fewer of those the better to me.
Thanks, Myles
On Tue, May 5, 2009 at 8:20 AM, Myles Watson mylesgw@gmail.com wrote:
On Tue, May 5, 2009 at 9:06 AM, ron minnich rminnich@gmail.com wrote:
But I think we have to have clean support for XIP in ROM, which means we have to have a way for cbfs to place a block of code in a designated place.
So can we force the compiler to make everything inside a block relative so that it can be position-independent?
I've tried in v3, but have been warned that the way we get PIE in v3 is really not legitimate, and not guaranteed to keep working. Some form of PIE that gnubin experts would accept would be very good to have.
I don't think we'll ever escape the need for some way to force files into specific locations. The ROMSTRAP code from nvidia is not the first example, nor will it be the last.
If we are certain we don't need XIP then we don't need this patch. But if we have XIP we can remove some fairly confusing __asm__ code in failover, as well as the attendant load scripts.
Does a normal image need to be XIP?
It is now and always has been. I don't know how to make it otherwise.
I think this is the easy part. The harder problems have to do with what we want to allow to be constrained to a specific location. The fewer of those the better to me.
I agree. The chipset vendors will always create challenges in this area, however. And we must still solve our own ROM code issues as well.
One option is to do the FILO trick and make %cs point to the start of the ROM code that you are running. This is easy: have a GDT entry for fallback code and a GDT entry for normal code. Then it suffices to do load the %cs with the right segment index for fallback or normal. This approach would remove the need for XIP for our ROM segments.
ron
I don't think we'll ever escape the need for some way to force files into specific locations. The ROMSTRAP code from nvidia is not the first example, nor will it be the last.
Here are two more. VIA has smth like this too. (pointer at ffffffd0) And notebooks usually has the uCode for EC somewhere fixed.
Rudolf
On Tue, May 5, 2009 at 8:31 AM, Rudolf Marek r.marek@assembler.cz wrote:
I don't think we'll ever escape the need for some way to force files into specific locations. The ROMSTRAP code from nvidia is not the first example, nor will it be the last.
Here are two more. VIA has smth like this too. (pointer at ffffffd0) And notebooks usually has the uCode for EC somewhere fixed.
I would argue that we need, at least, the part of my patch that includes rom_find_area if we wish to put these types of things in cbfs.
ron
On Tue, May 5, 2009 at 10:26 AM, ron minnich rminnich@gmail.com wrote:
On Tue, May 5, 2009 at 8:31 AM, Rudolf Marek r.marek@assembler.cz wrote:
I don't think we'll ever escape the need for some way to force files into specific locations. The ROMSTRAP code from nvidia is not the first example, nor will it be the last.
Here are two more. VIA has smth like this too. (pointer at ffffffd0) And notebooks usually has the uCode for EC somewhere fixed.
I would argue that we need, at least, the part of my patch that includes rom_find_area if we wish to put these types of things in cbfs.
I agree. I'd like to go through a round of:
1. It's impossible to do fixed locations. 2. How do we convert everything that's fixed now? 3. What's impossible to do without fixed locations?
Otherwise I'm afraid we'll end up with fixed regions that don't need to be fixed.
Thanks, Myles
On Tue, May 5, 2009 at 9:28 AM, ron minnich rminnich@gmail.com wrote:
On Tue, May 5, 2009 at 8:20 AM, Myles Watson mylesgw@gmail.com wrote:
On Tue, May 5, 2009 at 9:06 AM, ron minnich rminnich@gmail.com wrote:
But I think we have to have clean support for XIP in ROM, which means we have to have a way for cbfs to place a block of code in a designated place.
So can we force the compiler to make everything inside a block relative so that it can be position-independent?
I've tried in v3, but have been warned that the way we get PIE in v3 is really not legitimate, and not guaranteed to keep working. Some form of PIE that gnubin experts would accept would be very good to have.
Agreed. I think it should be used very sparingly even if we have it.
I don't think we'll ever escape the need for some way to force files into specific locations. The ROMSTRAP code from nvidia is not the first example, nor will it be the last.
If we are certain we don't need XIP then we don't need this patch. But if we have XIP we can remove some fairly confusing __asm__ code in failover, as well as the attendant load scripts.
Does a normal image need to be XIP?
It is now and always has been. I don't know how to make it otherwise.
OK.
I think this is the easy part. The harder problems have to do with what we want to allow to be constrained to a specific location. The fewer of those the better to me.
I agree. The chipset vendors will always create challenges in this area, however. And we must still solve our own ROM code issues as well.
One option is to do the FILO trick and make %cs point to the start of the ROM code that you are running. This is easy: have a GDT entry for fallback code and a GDT entry for normal code. Then it suffices to do load the %cs with the right segment index for fallback or normal. This approach would remove the need for XIP for our ROM segments.
How hard would that be? I'd be happy to test on SimNOW and a Tyan board.
Thanks, Myles
On Tue, May 5, 2009 at 8:34 AM, Myles Watson mylesgw@gmail.com wrote:
How hard would that be? I'd be happy to test on SimNOW and a Tyan board.
We would need to link normal such that its addressing is based on some fixed address (let's just pick one: 80000000). Then, at runtime, we copy the GDT to CAR data area, and parse the 'stage' header for normal and produce a GDT with an extra code segment entry for normal that maps that physical normal code (the code location in ROM) to its virtual address (stage->loadaddress).
That should work. It's a bit more complexity than simple XIP, but it's very flexitble for future work.
ron
Patrick Georgi wrote:
The "next" field has the disadvantage that we can't simply hot-update anymore, as we'd have to change data (instead of merely adding it).
ron minnich wrote:
- NEXT pointer
All of these will work.
'next' foils the desirable property that single files in cbfs can be updated in the flash chip without touching any other regions.
//Peter
On Tue, May 5, 2009 at 10:07 AM, Peter Stuge peter@stuge.se wrote:
Patrick Georgi wrote:
The "next" field has the disadvantage that we can't simply hot-update anymore, as we'd have to change data (instead of merely adding it).
ron minnich wrote:
- NEXT pointer
All of these will work.
'next' foils the desirable property that single files in cbfs can be updated in the flash chip without touching any other regions.
Isn't this somewhat mythical anyway? how many flash chips support 'erase byte' at this point (I honestly don't know!). I.e., isn't an update of any one byte in a block going to wipe out a whole block? How many cbfs files fit on neat 64k or 16k or whatever boundaries?
I don't know these answers, but you do :-)
ron
ron minnich wrote:
'next' foils the desirable property that single files in cbfs can be updated in the flash chip without touching any other regions.
Isn't this somewhat mythical anyway?
No sir.
how many flash chips support 'erase byte' at this point (I honestly don't know!). I.e., isn't an update of any one byte in a block going to wipe out a whole block? How many cbfs files fit on neat 64k or 16k or whatever boundaries?
None have single byte erase blocks, but most of the SPI flash chips can actually do 256 byte erase blocks.
I think it is important to keep the alignment in mind, so that files can be fit onto boundaries. I also think we should try to do it in the normal case.
I keep imagining how I will be able to safely update the coreboot normal image but keep fallback, stages and payloads untouched.
Another factor is that this is something our competition already allows, so we want to do it as well.
//Peter
On Tue, May 5, 2009 at 11:50 AM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
'next' foils the desirable property that single files in cbfs can be updated in the flash chip without touching any other regions.
Isn't this somewhat mythical anyway?
No sir.
how many flash chips support 'erase byte' at this point (I honestly don't know!). I.e., isn't an update of any one byte in a block going to wipe out a whole block? How many cbfs files fit on neat 64k or 16k or whatever boundaries?
None have single byte erase blocks, but most of the SPI flash chips can actually do 256 byte erase blocks.
Since erase block granularity is chip dependent, shouldn't flashrom be in charge of touching the minimal number of blocks? I don't see how CBFS can know which chip it will be used in.
I think it is important to keep the alignment in mind, so that files can be fit onto boundaries. I also think we should try to do it in the normal case.
What's the most common boundary? 1K, 2K, 4K? Should we pick one that is reasonable?
I keep imagining how I will be able to safely update the coreboot normal image but keep fallback, stages and payloads untouched.
That would be nice.
Thanks, Myles
Myles Watson wrote:
None have single byte erase blocks, but most of the SPI flash chips can actually do 256 byte erase blocks.
Since erase block granularity is chip dependent, shouldn't flashrom be in charge of touching the minimal number of blocks? I don't see how CBFS can know which chip it will be used in.
Correct, it can't on it's own, and I think flash writing and cbfs expertise will go together eventually. I expect cbfstool and flashrom to converge a bit. Not all the way into one tool, but they will be close.
What's the most common boundary? 1K, 2K, 4K? Should we pick one that is reasonable?
Fun fun. A few chips even have odd-byte boundaries like 4300 bytes or whatever. And some are very much not symmetrical.
I think it's impossible to pick a good universal default. The target flash chip layout is required information. I expect the final decision to be defered until actual flash write time. It could certainly be the case that not everything in the flash chip can be aligned into it's own block at that point.
//Peter
On 05.05.2009 19:54, Myles Watson wrote:
On Tue, May 5, 2009 at 11:50 AM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
how many flash chips support 'erase byte' at this point (I honestly don't know!). I.e., isn't an update of any one byte in a block going to wipe out a whole block? How many cbfs files fit on neat 64k or 16k or whatever boundaries?
None have single byte erase blocks, but most of the SPI flash chips can actually do 256 byte erase blocks.
Since erase block granularity is chip dependent, shouldn't flashrom be in charge of touching the minimal number of blocks? I don't see how CBFS can know which chip it will be used in.
Yes. I need to resend the flashrom patches solving this.
I think it is important to keep the alignment in mind, so that files can be fit onto boundaries. I also think we should try to do it in the normal case.
What's the most common boundary? 1K, 2K, 4K? Should we pick one that is reasonable?
There is no common boundary. It all depends on how much you're willing to pay per chip. I've seen anything from 256 Bytes to 64 kBytes as erase granularity for SPI chips currently in production. Of course, some chips have non-uniform erase sizes. That makes it even harder to handle.
Regards, Carl-Daniel
On Tue, May 5, 2009 at 10:50 AM, Peter Stuge peter@stuge.se wrote:
No sir.
This is great!
None have single byte erase blocks, but most of the SPI flash chips can actually do 256 byte erase blocks.
Should we move to 256 byte default alignment?
I keep imagining how I will be able to safely update the coreboot normal image but keep fallback, stages and payloads untouched.
me too.
ron
On 05.05.2009 19:59, ron minnich wrote:
On Tue, May 5, 2009 at 10:50 AM, Peter Stuge peter@stuge.se wrote:
No sir.
This is great!
None have single byte erase blocks, but most of the SPI flash chips can actually do 256 byte erase blocks.
Should we move to 256 byte default alignment?
256 byte LAR member _content_ alignment or _header_ alignment? Sometimes it may be useful to have the content aligned.
I keep imagining how I will be able to safely update the coreboot normal image but keep fallback, stages and payloads untouched.
me too.
With LAR and a patched flashrom this is possible right now.
Regards, Carl-Daniel
Just catching up on this discussion so I applogize if these ideas have already been hashed out.
I think that the original idea Jordan had was that the alignment is in the master header. Each component is always header and data together. The component header has the length. Given the alignment and the length the component search should be pretty smart.
Details about adding and removing components can be left to the discretion of the image creator/ rom writer. Putting the components in execution order would be optimal but decisions about alignment and space are left up to the user.
If something is wrong or missing in the idea please fix the wiki too. http://www.coreboot.org/CBFS#Searching_Alogrithm
Marc
On 05.05.2009 19:36, ron minnich wrote:
Isn't this somewhat mythical anyway? how many flash chips support 'erase byte' at this point (I honestly don't know!). I.e., isn't an update of any one byte in a block going to wipe out a whole block? How many cbfs files fit on neat 64k or 16k or whatever boundaries?
Intel specifies that each flash chip location (byte) must be writable at least twice after each erase, so you can update a previously written byte once (well, set some more bits to 0) without erasing.
Regards, Carl-Daniel
Am 05.05.2009 19:07, schrieb Peter Stuge:
'next' foils the desirable property that single files in cbfs can be updated in the flash chip without touching any other regions.
Two options: 1. have next point to 0xffffffff and replace the whole block it's in 2. have next point to a validated clean area (esp. no magic) and force the next cbfs_file header there.
2. is better, but there might be the rare corner case that the intended area is fixed memory for a new entry.
I guess we can live with that, right?
Patrick
-
Carl-Daniel Hailfinger -
Marc Jones -
Myles Watson -
Patrick Georgi -
Peter Stuge -
ron minnich -
Rudolf Marek