| Submitter | Patrick Georgi |
|---|---|
| Date | 2009-11-11 20:16:12 |
| Message ID | <4AFB1B8C.7030502@georgi-clan.de> |
| Download | mbox | patch |
| Permalink | /patch/553/ |
| State | Accepted |
| Commit | r4934 |
| Headers | show |
Comments
On Wed, Nov 11, 2009 at 1:16 PM, Patrick Georgi <patrick@georgi-clan.de> wrote: > 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) 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
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>
Am 11.11.2009 21:28, schrieb Myles Watson: > On Wed, Nov 11, 2009 at 1:16 PM, Patrick Georgi<patrick@georgi-clan.de> wrote: > > >> 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) >> > 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 Georgi<patrick.georgi@coresystems.de> >> > Acked-by: Myles Watson<mylesgw@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
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
>>> 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
Myles Watson 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? > A larger bootblock makes it build but fails to boot. Maybe that can be fixed. Or maybe not? //Peter
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
Patch
Index: src/arch/i386/Kconfig =================================================================== --- src/arch/i386/Kconfig (revision 4930) +++ src/arch/i386/Kconfig (working copy) @@ -20,12 +20,7 @@ config ROMBASE hex - default 0xffc00000 if COREBOOT_ROMSIZE_KB_4096 - default 0xffe00000 if COREBOOT_ROMSIZE_KB_2048 - default 0xfff00000 if COREBOOT_ROMSIZE_KB_1024 - default 0xfff80000 if COREBOOT_ROMSIZE_KB_512 - default 0xfffc0000 if COREBOOT_ROMSIZE_KB_256 - default 0xfffe0000 if COREBOOT_ROMSIZE_KB_128 + default 0xffff0000 config ROM_IMAGE_SIZE hex Index: src/arch/i386/Makefile.inc =================================================================== --- src/arch/i386/Makefile.inc (revision 4930) +++ src/arch/i386/Makefile.inc (working copy) @@ -8,14 +8,13 @@ obj-$(CONFIG_HAVE_OPTION_TABLE) += ../../option_table.o ifdef POST_EVALUATION -BOOTBLOCK_SIZE=65536 ####################################################################### # Build the final rom image $(obj)/coreboot.rom: $(obj)/coreboot.bootblock $(obj)/coreboot_ram $(CBFSTOOL) rm -f $@ - $(CBFSTOOL) $@ create $(shell expr 1024 \* $(CONFIG_COREBOOT_ROMSIZE_KB)) $(BOOTBLOCK_SIZE) $(obj)/coreboot.bootblock + $(CBFSTOOL) $@ create $(shell expr 1024 \* $(CONFIG_COREBOOT_ROMSIZE_KB)) $(obj)/coreboot.bootblock if [ -f fallback/coreboot_apc ]; \ then \ $(CBFSTOOL) $@ add-stage fallback/coreboot_apc fallback/coreboot_apc $(CBFS_COMPRESS_FLAG); \ Index: util/newconfig/config.g =================================================================== --- util/newconfig/config.g (revision 4930) +++ util/newconfig/config.g (working copy) @@ -2295,8 +2295,8 @@ for j in i.roms: file.write(" %s/coreboot.rom " % j) file.write("> %s.bootblock\n\n" %i.name) - file.write("\t./cbfs/cbfstool %s create %s %s %s.bootblock\n" - %(i.name, romsize, bootblocksize, i.name)) + file.write("\t./cbfs/cbfstool %s create %s %s.bootblock\n" + %(i.name, romsize, i.name)) for j in pciroms: file.write("\t./cbfs/cbfstool %s add %s pci%04x,%04x.rom optionrom\n" % (i.name, j.name, j.pci_vid, j.pci_did)) for j in i.roms: Index: util/cbfstool/cbfstool.c =================================================================== --- util/cbfstool/cbfstool.c (revision 4930) +++ util/cbfstool/cbfstool.c (working copy) @@ -187,18 +187,17 @@ { char *romname = argv[1]; char *cmd = argv[2]; - if (argc < 6) { + if (argc < 5) { printf("not enough arguments to 'create'.\n"); return 1; } uint32_t size = strtoul(argv[3], NULL, 0); - /* ignore bootblock size. we use whatever we get and won't allocate any larger */ - char *bootblock = argv[5]; + char *bootblock = argv[4]; uint32_t align = 0; - if (argc > 6) - align = strtoul(argv[6], NULL, 0); + if (argc > 5) + align = strtoul(argv[5], NULL, 0); return create_cbfs_image(romname, size, bootblock, align); } @@ -255,7 +254,7 @@ "add FILE NAME TYPE [base address] Add a component\n" "add-payload FILE NAME [COMP] [base] Add a payload to the ROM\n" "add-stage FILE NAME [COMP] [base] Add a stage to the ROM\n" - "create SIZE BSIZE BOOTBLOCK [ALIGN] Create a ROM file\n" + "create SIZE BOOTBLOCK [ALIGN] Create a ROM file\n" "locate FILE NAME ALIGN Find a place for a file of that size\n" "print Show the contents of the ROM\n"); }
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