Hi,
attached patch cleans up the bootblock size handling: 1. cbfstool create does no longer take a value it doesn't parse anyway (bootblocksize), but creates a bootblock of the size of the file that's filled in.
2. kconfig and newconfig are adapted to not pass the value
3. CONFIG_ROMBASE in kconfig isn't set to the ROM size, but to 4GB-64KB, ie. the standard start address of the bootblock. That's how it's used anyway (which didn't show because the linker script moves into top 64K if necessary)
4. BOOTBLOCK_SIZE in src/arch/i386/Makefile.inc isn't used anymore, so it's dropped.
Change #1 requires #2, so mixing cbfstool versions must not happen (but usually won't happen)
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Patrick
On Wed, Nov 11, 2009 at 1:16 PM, Patrick Georgi patrick@georgi-clan.de wrote:
- CONFIG_ROMBASE in kconfig isn't set to the ROM size, but to 4GB-64KB, ie.
the standard start address of the bootblock. That's how it's used anyway (which didn't show because the linker script moves into top 64K if necessary)
This doesn't seem like it should be a config option any more.
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Acked-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
Am 11.11.2009 21:28, schrieb Myles Watson:
On Wed, Nov 11, 2009 at 1:16 PM, Patrick Georgipatrick@georgi-clan.de wrote:
- CONFIG_ROMBASE in kconfig isn't set to the ROM size, but to 4GB-64KB, ie.
the standard start address of the bootblock. That's how it's used anyway (which didn't show because the linker script moves into top 64K if necessary)
This doesn't seem like it should be a config option any more.
Ideally, it will become some automatic "as small as possible" configuration. Unfortunately ld doesn't allow to align everything to an upper boundary, so this requires the link-twice trick or so. So for now, I'd like to keep it there - people might want to tweak it. As an example (which made me look into this in the first place), someone (agaran) on #coreboot wanted to use a smaller bootblock. Until this automatically happens, we'll have to allow this to change.
kconfig is just as good as any place in my opinion.
Signed-off-by: Patrick Georgipatrick.georgi@coresystems.de
Acked-by: Myles Watsonmylesgw@gmail.com
Thanks, r4934
Patrick
This doesn't seem like it should be a config option any more.
Ideally, it will become some automatic "as small as possible" configuration. Unfortunately ld doesn't allow to align everything to an upper boundary, so this requires the link-twice trick or so. So for now, I'd like to keep it there - people might want to tweak it. As an example (which made me look into this in the first place), someone (agaran) on #coreboot wanted to use a smaller bootblock. Until this automatically happens, we'll have to allow this to change.
Sounds good.
kconfig is just as good as any place in my opinion.
Yes.
Thanks, Myles
On 12/11/2009, Myles Watson mylesgw@gmail.com wrote:
This doesn't seem like it should be a config option any more.
Ideally, it will become some automatic "as small as possible" configuration. Unfortunately ld doesn't allow to align everything to an upper boundary, so this requires the link-twice trick or so. So for now, I'd like to keep it there - people might want to tweak it. As an example (which made me look into this in the first place), someone (agaran) on #coreboot wanted to use a smaller bootblock. Until this automatically happens, we'll have to allow this to change.
Sounds good.
For me, ROMBASE must be at 0xFFFE000, that is 4G - romchip size (128k). if i try to set it to anything else i get some errors while build like:
$ grep ROMBASE build/ldoptions ; grep -A2 ROMBASE src/arch/i386/Kconfig;make CONFIG_ROMBASE = 0xfffe1000; config ROMBASE hex default 0xfffe1000 GEN build.h CC lib/version.o AR coreboot.a CC coreboot_ram.o CC coreboot_ram PAYLOAD payload.elf l CBFSPRINT coreboot.rom
/home/agaran/Coreboot/trunk/build/coreboot.rom: 128 kB, bootblocksize 0, romsize 131072, offset 0x0 Alignment: 64 bytes
Name Offset Type Size fallback/coreboot_ram 0x0 stage 33186 fallback/payload 0x8200 payload 16172 0xc180 null 81464 make: *** [/home/agaran/Coreboot/trunk/build/coreboot.rom] Segmentation fault make: *** Deleting file `/home/agaran/Coreboot/trunk/build/coreboot.rom'
but i found way that works for me (but it is somewhat ugly) (see patch in attachment)
this causes to increase space before actual rom code, but main disadvantage is need to make this change manual, probably this could be scripted (default extra gap = 0, and changed via some echo after first linking when amount of space after rom code before jumpvector is known)
or maybe you have better idea
ps. please just tell me if this make no sense at all
best regards Maciej
On Wed, Nov 11, 2009 at 4:57 PM, Maciej Pijanka maciej.pijanka@gmail.com wrote:
On 12/11/2009, Myles Watson mylesgw@gmail.com wrote:
This doesn't seem like it should be a config option any more.
Ideally, it will become some automatic "as small as possible" configuration. Unfortunately ld doesn't allow to align everything to an upper boundary, so this requires the link-twice trick or so. So for now, I'd like to keep it there - people might want to tweak it. As an example (which made me look into this in the first place), someone (agaran) on #coreboot wanted to use a smaller bootblock. Until this automatically happens, we'll have to allow this to change.
Sounds good.
For me, ROMBASE must be at 0xFFFE000, that is 4G - romchip size (128k). if i try to set it to anything else i get some errors while build like:
It broke for me too. I'm getting a 4GB bootblock. I should have build/boot tested it.
Thanks, Myles
Myles Watson wrote:
On Wed, Nov 11, 2009 at 4:57 PM, Maciej Pijanka maciej.pijanka@gmail.com wrote:
On 12/11/2009, Myles Watson mylesgw@gmail.com wrote:
This doesn't seem like it should be a config option any more.
Ideally, it will become some automatic "as small as possible" configuration. Unfortunately ld doesn't allow to align everything to an upper boundary, so this requires the link-twice trick or so. So for now, I'd like to keep it there - people might want to tweak it. As an example (which made me look into this in the first place), someone (agaran) on #coreboot wanted to use a smaller bootblock. Until this automatically happens, we'll have to allow this to change.
Sounds good.
For me, ROMBASE must be at 0xFFFE000, that is 4G - romchip size (128k). if i try to set it to anything else i get some errors while build like:
It broke for me too. I'm getting a 4GB bootblock. I should have build/boot tested it.
Are you guys using the util/crossgcc compiler?
On 12/11/2009, Stefan Reinauer stepan@coresystems.de wrote:
Myles Watson wrote:
On Wed, Nov 11, 2009 at 4:57 PM, Maciej Pijanka maciej.pijanka@gmail.com wrote:
On 12/11/2009, Myles Watson mylesgw@gmail.com wrote:
This doesn't seem like it should be a config option any more.
Ideally, it will become some automatic "as small as possible" configuration. Unfortunately ld doesn't allow to align everything to an upper boundary, so this requires the link-twice trick or so. So for now, I'd like to keep it there - people might want to tweak it. As an example (which made me look into this in the first place), someone (agaran) on #coreboot wanted to use a smaller bootblock. Until this automatically happens, we'll have to allow this to change.
Sounds good.
For me, ROMBASE must be at 0xFFFE000, that is 4G - romchip size (128k). if i try to set it to anything else i get some errors while build like:
It broke for me too. I'm getting a 4GB bootblock. I should have build/boot tested it.
Are you guys using the util/crossgcc compiler?
negative, before this change it was working with compiler i use, after change and changing ROMBASE to 4G-128k, works again, if i add crude ld hack i posted previously, i even can make bootblock more tight.
best regards Maciej
For me, ROMBASE must be at 0xFFFE000, that is 4G - romchip size (128k). if i try to set it to anything else i get some errors while build like:
It broke for me too. I'm getting a 4GB bootblock. I should have build/boot tested it.
Are you guys using the util/crossgcc compiler?
Yes. I am. It works for you?
Thanks, Myles
Am 12.11.2009 14:49, schrieb Myles Watson:
It works for you?
I tracked it down. I'm sorry, but my tests worked for some reason. Working on a fix now...
Patrick
On Thu, Nov 12, 2009 at 7:12 AM, Patrick Georgi patrick.georgi@coresystems.de wrote:
Am 12.11.2009 14:49, schrieb Myles Watson:
It works for you?
I tracked it down. I'm sorry, but my tests worked for some reason. Working on a fix now...
Should we revert it and then try again fresh?
I really think we need to be tracking kbuildall like we track abuild.
Thanks, Myles
Am 12.11.2009 15:14, schrieb Myles Watson:
On Thu, Nov 12, 2009 at 7:12 AM, Patrick Georgi patrick.georgi@coresystems.de wrote:
I tracked it down. I'm sorry, but my tests worked for some reason. Working on a fix now...
Should we revert it and then try again fresh?
Reverting everthing would be overkill.. The only thing that negatively affects the build is the ROMBASE configuration in src/arch/i386/Kconfig, the other parts are fine.
I'm looking for a way to keep ROMBASE functional that way (esp. to allow smaller bootblocks) while fixing the current issue. Maybe it's still a good idea to revert that change for now.
Patrick
Reverting everthing would be overkill.. The only thing that negatively affects the build is the ROMBASE configuration in src/arch/i386/Kconfig, the other parts are fine.
I'm looking for a way to keep ROMBASE functional that way (esp. to allow smaller bootblocks) while fixing the current issue.
I think we should allow larger boot blocks at the same time and fix fam10 builds.
Maybe it's still a good idea to revert that change for now.
It's up to you. Reverting it seems cheap compared to having it broken for multiple days.
Thanks, Myles
Am 12.11.2009 15:56, schrieb Myles Watson:
Reverting everthing would be overkill.. The only thing that negatively affects the build is the ROMBASE configuration in src/arch/i386/Kconfig, the other parts are fine.
I'm looking for a way to keep ROMBASE functional that way (esp. to allow smaller bootblocks) while fixing the current issue.
I think we should allow larger boot blocks at the same time and fix fam10 builds.
If that fixes fam10, I'm all for it. My understanding is that failover was invented specifically to make fam10 work with only 64kb of available ROM, but I might be wrong. That would mean that a bootblock >64kb wouldn't be entirely visible.
It's up to you. Reverting it seems cheap compared to having it broken for multiple days.
Either I fix it today, or I'll revert that part of the change. Either way it'll work in a couple of hours again.
Patrick
On Thu, Nov 12, 2009 at 8:00 AM, Patrick Georgi patrick.georgi@coresystems.de wrote:
Am 12.11.2009 15:56, schrieb Myles Watson:
Reverting everthing would be overkill.. The only thing that negatively affects the build is the ROMBASE configuration in src/arch/i386/Kconfig, the other parts are fine.
I'm looking for a way to keep ROMBASE functional that way (esp. to allow smaller bootblocks) while fixing the current issue.
I think we should allow larger boot blocks at the same time and fix fam10 builds.
If that fixes fam10, I'm all for it. My understanding is that failover was invented specifically to make fam10 work with only 64kb of available ROM, but I might be wrong. That would mean that a bootblock >64kb wouldn't be entirely visible.
I keep forgetting that the bootblock has to be < 64Kb so that the start is reachable with a jump in 16-bit mode. A larger bootblock makes it build but fails to boot.
It's up to you. Reverting it seems cheap compared to having it broken for multiple days.
Either I fix it today, or I'll revert that part of the change. Either way it'll work in a couple of hours again.
Great.
Thanks, Myles
Peter Stuge wrote:
I keep forgetting that the bootblock has to be < 64Kb so that the start is reachable with a jump in 16-bit mode.
Why does it not work to do e.g. jmp fffe:0000?
Is CS set up especially for the top 64k on reset? I've known this..
But, in any case, maybe the bootblock can be split up so that there really only is a minimum (not 64k!) of stuff which needs to be near fffffff0?
//Peter
Am 12.11.2009 16:42, schrieb Peter Stuge:
But, in any case, maybe the bootblock can be split up so that there really only is a minimum (not 64k!) of stuff which needs to be near fffffff0?
That's basically what failover does, and newfailover aims for.
Patrick
Hello
I feel somewhat guilty for this ROMBASE problem as i was on irc bugging about inability to move bootblock in chip and rom layout for me was looking like
0-64k cbfs 64-128k bootblock, then empty space, then jump code and empty space was about 20k
so i asked how i could change that to move bootblock towards jumpcode to make that empty space gap smaller.
While change done caused another problems with ROMBASE, i simply changed ROMBASE to 4G - size of rom (hardcoded, i know that this can be calculated depending on actual selected chip size), also i created small change in linker script used to generate bootblock which automatically makes gap small (assuming rounding to 256byte boundaries etc)
I already posted this patch once, but maybe it was overlooked. That already commited change plus this patch make me able to save about 20k of raw flash space, and it boots (then later crash on lzma problem but this is with or without moveing of bootblock)
best regards Maciej
I already posted this patch once, but maybe it was overlooked.
but i found way that works for me (but it is somewhat ugly) (see patch in attachment)
Since you said it was ugly and named it crude-ld-hack.patch, it might not have been reviewed.
That already commited change plus this patch make me able to save about 20k of raw flash space, and it boots (then later crash on lzma problem but this is with or without moveing of bootblock)
I'd be interested to hear about your lzma problem. I don't remember seeing that one. Have you tried increasing your stack size?
Thanks, Myles
On 12/11/2009, Myles Watson mylesgw@gmail.com wrote:
I already posted this patch once, but maybe it was overlooked.
but i found way that works for me (but it is somewhat ugly) (see patch in attachment)
Since you said it was ugly and named it crude-ld-hack.patch, it might not have been reviewed.
Maybe better name would be bootblock-autorelocation-ldscript.patch in case if anyone would consider it as worth keeping etc, Signed-off Maciej Pijanka maciej.pijanka@gmail.com
That already commited change plus this patch make me able to save about 20k of raw flash space, and it boots (then later crash on lzma problem but this is with or without moveing of bootblock)
I'd be interested to hear about your lzma problem. I don't remember seeing that one. Have you tried increasing your stack size?
No, it just reports error and reboots so i spend some work to save as much space as possible and to make small filo to fit without lzma, but didn't finished that approach yet.
best regards Maciej
No, it just reports error and reboots so i spend some work to save as much space as possible and to make small filo to fit without lzma, but didn't finished that approach yet.
It's important in the general case for lzma to work, so if you're interested in figuring it out, start a new thread and send the error log to the list.
Thanks, Myles
Maybe better name would be bootblock-autorelocation-ldscript.patch in case if anyone would consider it as worth keeping etc, Signed-off Maciej Pijanka maciej.pijanka@gmail.com
This patch saves 28K on my s2895, and 55K on qemu. Anybody have a strong objection to that? Are we trying to have bootblock size be constant for each board? Does it mess up future plans for backwards compatibility?
It uses an alignment of 256 bytes. Is that sufficient? Is it necessary?
Thanks, Myles
Am 12.11.2009 19:13, schrieb Myles Watson:
This patch saves 28K on my s2895, and 55K on qemu. Anybody have a strong objection to that? Are we trying to have bootblock size be constant for each board? Does it mess up future plans for backwards compatibility?
Having a good automatic way to minimize the bootblock size is very useful. As for backwards compatibility, what do you mean - updates? The bootblock complicates any attempt to do safe updates currently. This change won't improve it, but it won't make it worse.
It uses an alignment of 256 bytes. Is that sufficient? Is it necessary?
Should be fine.
My only issue is that I don't know if its behaviour is stable. ld prefers to work from bottom to top in the address space and this solution might interfere. How can we get an "official" statement if this method is supported or just luck that it works right now? A mail to the binutils list?
Patrick
On Thu, Nov 12, 2009 at 11:39 AM, Patrick Georgi patrick.georgi@coresystems.de wrote:
Am 12.11.2009 19:13, schrieb Myles Watson:
This patch saves 28K on my s2895, and 55K on qemu. Anybody have a strong objection to that? Are we trying to have bootblock size be constant for each board? Does it mess up future plans for backwards compatibility?
Having a good automatic way to minimize the bootblock size is very useful. As for backwards compatibility, what do you mean - updates? The bootblock complicates any attempt to do safe updates currently. This change won't improve it, but it won't make it worse.
I thought that the master CBFS header was directly above the bootblock. If someone wanted to just update the bootblock, but the size increased, there would be no way to do that. I realize that it's impossible now, but it seems like that was a future plan at some point.
It uses an alignment of 256 bytes. Is that sufficient? Is it necessary?
Should be fine.
My only issue is that I don't know if its behaviour is stable. ld prefers to work from bottom to top in the address space and this solution might interfere. How can we get an "official" statement if this method is supported or just luck that it works right now? A mail to the binutils list?
Good idea.
Myles
Am 12.11.2009 19:44, schrieb Myles Watson:
On Thu, Nov 12, 2009 at 11:39 AM, Patrick Georgi patrick.georgi@coresystems.de wrote:
Am 12.11.2009 19:13, schrieb Myles Watson:
This patch saves 28K on my s2895, and 55K on qemu. Anybody have a strong objection to that? Are we trying to have bootblock size be constant for each board? Does it mess up future plans for backwards compatibility?
Having a good automatic way to minimize the bootblock size is very useful. As for backwards compatibility, what do you mean - updates? The bootblock complicates any attempt to do safe updates currently. This change won't improve it, but it won't make it worse.
I thought that the master CBFS header was directly above the bootblock.
The bootblock can be stored whereever we want. Its location is recorded in 0xfffffffc. It can be copied, regenerated, etc. at will, given that there's 32byte (or so) of free space somewhere - and we need a special "update bootblock" routine in any case, so it could as well take care of the master header.
The only "downside" is that the "only 64kb are mapped" test I added earlier today won't work anymore, if the bootblock is usually smaller than 64kb.
If someone wanted to just update the bootblock, but the size increased, there would be no way to do that. I realize that it's impossible now, but it seems like that was a future plan at some point.
My hope is that at some point, the bootblock is immutable for a board, by kicking everything out of it that really, really has to be in there.
On Thu, 12 Nov 2009, Patrick Georgi wrote:
Am 12.11.2009 19:13, schrieb Myles Watson:
This patch saves 28K on my s2895, and 55K on qemu. Anybody have a strong objection to that? Are we trying to have bootblock size be constant for each board? Does it mess up future plans for backwards compatibility?
Having a good automatic way to minimize the bootblock size is very useful. As for backwards compatibility, what do you mean - updates? The bootblock complicates any attempt to do safe updates currently. This change won't improve it, but it won't make it worse.
It uses an alignment of 256 bytes. Is that sufficient? Is it necessary?
Should be fine.
My only issue is that I don't know if its behaviour is stable. ld prefers to work from bottom to top in the address space and this solution might interfere. How can we get an "official" statement if this method is supported or just luck that it works right now? A mail to the binutils list?
Anyone tried to confirm if this method is supported or not?
Am 24.11.2009 15:34, schrieb Maciej Pijanka:
Anyone tried to confirm if this method is supported or not?
I read the documentation of the linker again. It should be safe to use. Thus, Acked-by: Patrick Georgi patrick.georgi@coresystems.de
There are some places that could be cleaned up at some point, but that might be easier once newconfig is gone. This is already a very nice improvement!
Patrick
On Wed, Nov 11, 2009 at 10:32:40PM +0100, Patrick Georgi wrote:
Ideally, it will become some automatic "as small as possible" configuration. Unfortunately ld doesn't allow to align everything to an upper boundary, so this requires the link-twice trick or so.
Just as a random note, the above is what SeaBIOS does. It links the code with "-r", figures out the sizes of the sections, and then does the final link with the code located as high as possible.
-Kevin
Patrick Georgi wrote:
attached patch cleans up the bootblock size handling:
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Acked-by: Peter Stuge peter@stuge.se
-
Kevin O'Connor -
Maciej Pijanka -
Myles Watson -
Patrick Georgi -
Patrick Georgi -
Peter Stuge -
Stefan Reinauer