[U-Boot-Users] Increasing U-Boot partition size
I have to increase u-boot's partition size on my board to make room for an application to be compiled as part of u-boot binary. I am currently running u-boot version "1.3.1-rc1" and my current NOR partition is as follows:
Partition Address -------------------------------- ---------------- /dev/mtd0 -RCW, 64k 0xFF800000 /dev/mtd1 Kernel 2M 0xFF810000 /dev/mtd2 cramfs 4.8M 0xFFA10000 /dev/mtd3 U-Boot 384K 0xFFF00000 /dev/mtd4 Env 64K 0xFFF60000 /dev/mtd5 EnvB 64K 0xFFF70000 /dev/mtd6 DTB 64K 0xFFF90000
I have updated to Flattened Device Tree to reflect the new partition as follows. Also, I have updated the TEXT_BASE to 0xFFE60000 in the config.mk under board/<my board> directory.
Partition Address -------------------------------- ---------------- /dev/mtd0 -RCW, 64k 0xFF800000 /dev/mtd1 Kernel 2M 0xFF810000 /dev/mtd2 cramfs 4.3M 0xFFA10000 /dev/mtd3 U-Boot 1M 0xFFE60000 /dev/mtd4 Env 64K 0xFFF60000 /dev/mtd5 EnvB 64K 0xFFF70000 /dev/mtd6 DTB 64K 0xFFF90000
U-Boot binary with the updated FDT doesn't boot. So, I need to understand what other updates I need to make for U-Boot to use this new partition. I would like to know if there are standard hooks in u-boot to incorporate partition changes that may be documented somewhere.
My board is powerpc architecture and is using NOR flash to boot u-boot. Any help is appreciated. I can provide more information if needed.
Thanks, Jatin
On Fri, Aug 01, 2008 at 12:16:13PM -0500, Jatin Sharma wrote:
I have to increase u-boot's partition size on my board to make room for an application to be compiled as part of u-boot binary. I am currently running u-boot version "1.3.1-rc1" and my current NOR partition is as follows:
Partition Address
/dev/mtd0 -RCW, 64k 0xFF800000 /dev/mtd1 Kernel 2M 0xFF810000 /dev/mtd2 cramfs 4.8M 0xFFA10000 /dev/mtd3 U-Boot 384K 0xFFF00000 /dev/mtd4 Env 64K 0xFFF60000 /dev/mtd5 EnvB 64K 0xFFF70000 /dev/mtd6 DTB 64K 0xFFF90000
I have updated to Flattened Device Tree to reflect the new partition as follows. Also, I have updated the TEXT_BASE to 0xFFE60000 in the config.mk under board/<my board> directory.
Partition Address
/dev/mtd0 -RCW, 64k 0xFF800000 /dev/mtd1 Kernel 2M 0xFF810000 /dev/mtd2 cramfs 4.3M 0xFFA10000 /dev/mtd3 U-Boot 1M 0xFFE60000 /dev/mtd4 Env 64K 0xFFF60000 /dev/mtd5 EnvB 64K 0xFFF70000 /dev/mtd6 DTB 64K 0xFFF90000
U-Boot binary with the updated FDT doesn't boot.
You changed the address where u-boot starts. Does the CPU know about this when it branches to the boot vector?
-Scott
No, I don't think I made changes to let CPU know about this when it branches to the boot vector.
After I posted this message, I learned the reset vector for the PPC architecture lies at 0xFFF00100. Does it mean the u-boot has to start at the address 0xFFF00000? If not, how can I let CPU know to look for u-boot at this new address? Please let me know if it is documented somewhere.
Thanks, Jatin
2008/8/4 Scott Wood scottwood@freescale.com:
On Fri, Aug 01, 2008 at 12:16:13PM -0500, Jatin Sharma wrote:
I have to increase u-boot's partition size on my board to make room for an application to be compiled as part of u-boot binary. I am currently running u-boot version "1.3.1-rc1" and my current NOR partition is as follows:
Partition Address
/dev/mtd0 -RCW, 64k 0xFF800000 /dev/mtd1 Kernel 2M 0xFF810000 /dev/mtd2 cramfs 4.8M 0xFFA10000 /dev/mtd3 U-Boot 384K 0xFFF00000 /dev/mtd4 Env 64K 0xFFF60000 /dev/mtd5 EnvB 64K 0xFFF70000 /dev/mtd6 DTB 64K 0xFFF90000
I have updated to Flattened Device Tree to reflect the new partition as follows. Also, I have updated the TEXT_BASE to 0xFFE60000 in the config.mk under board/<my board> directory.
Partition Address
/dev/mtd0 -RCW, 64k 0xFF800000 /dev/mtd1 Kernel 2M 0xFF810000 /dev/mtd2 cramfs 4.3M 0xFFA10000 /dev/mtd3 U-Boot 1M 0xFFE60000 /dev/mtd4 Env 64K 0xFFF60000 /dev/mtd5 EnvB 64K 0xFFF70000 /dev/mtd6 DTB 64K 0xFFF90000
U-Boot binary with the updated FDT doesn't boot.
You changed the address where u-boot starts. Does the CPU know about this when it branches to the boot vector?
-Scott
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Jatin Sharma wrote:
After I posted this message, I learned the reset vector for the PPC architecture lies at 0xFFF00100.
Well, it depends on what kind of PPC chip...
Does it mean the u-boot has to start at the address 0xFFF00000?
Yes (or possibly zero, if the RCW is set appropriately).
If not, how can I let CPU know to look for u-boot at this new address?
You edit the VHDL/Verilog. :-)
-Scott
I have Freescale MPC8347. Can you confirm that I have to have U-Boot start at 0xFFF00000?
Thanks, Jatin
2008/8/4 Scott Wood scottwood@freescale.com:
Jatin Sharma wrote:
After I posted this message, I learned the reset vector for the PPC architecture lies at 0xFFF00100.
Well, it depends on what kind of PPC chip...
Does it mean the u-boot has to start at the address 0xFFF00000?
Yes (or possibly zero, if the RCW is set appropriately).
If not, how can I let CPU know to look for u-boot at this new address?
You edit the VHDL/Verilog. :-)
-Scott
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Scott Wood wrote:
Jatin Sharma wrote:
I have Freescale MPC8347. Can you confirm that I have to have U-Boot start at 0xFFF00000?
Your choices are 0xfff00000 and zero, based on the BMS (Boot Memory Space) bit of the low reset control word.
Grr, that should say "high reset control word".
-Scott
Scott Wood wrote:
Jatin Sharma wrote:
I have Freescale MPC8347. Can you confirm that I have to have U-Boot start at 0xFFF00000?
Your choices are 0xfff00000 and zero, based on the BMS (Boot Memory Space) bit of the low reset control word.
-Scott
...and of the two options, I recommend 0xfff00000 ("boot high"). Note that the start of u-boot is 0xfff00000 but the reset vector itself is 0xfff00100 (or 0x00000100 for "boot low"). The first 0x100 bytes has the u-boot signature and version info.
HTH, gvb
In message 489765FB.1010002@ge.com you wrote:
Your choices are 0xfff00000 and zero, based on the BMS (Boot Memory Space) bit of the low reset control word.
-Scott
...and of the two options, I recommend 0xfff00000 ("boot high"). Note that the start of u-boot is 0xfff00000 but the reset vector itself is 0xfff00100 (or 0x00000100 for "boot low"). The first 0x100 bytes has the u-boot signature and version info.
I disagree.
High-booting systems are a PITA. You always lose a full megabyte at the end of the flash of which usually only 256 kB or less are needed for U-Boot, wasting 0.75 MB.
Also, systems with varying number of flash banks and/or flash sizes are not really straightforward to handle.
Low-booting is much, much saner.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 489765FB.1010002@ge.com you wrote:
Your choices are 0xfff00000 and zero, based on the BMS (Boot Memory Space) bit of the low reset control word.
-Scott
...and of the two options, I recommend 0xfff00000 ("boot high"). Note that the start of u-boot is 0xfff00000 but the reset vector itself is 0xfff00100 (or 0x00000100 for "boot low"). The first 0x100 bytes has the u-boot signature and version info.
I disagree.
High-booting systems are a PITA. You always lose a full megabyte at the end of the flash of which usually only 256 kB or less are needed for U-Boot, wasting 0.75 MB.
Also, systems with varying number of flash banks and/or flash sizes are not really straightforward to handle.
Low-booting is much, much saner.
Best regards,
Wolfgang Denk
Arrr, my insanity. Wolfgang is correct, of course.
Sorry, gvb
Arrr, my insanity. Wolfgang is correct, of course.
Gee, and I was just going to ask why on earth you liked high-boot :)
I've seen one novel use of high-boot that could make it useful if you're lazy and can't be bothered plugging in your debugger ;)
Assuming your board has a toggle switch that sets the state of BMS in the RCW (as most Freescale boards do), you can put a 'good' version of U-Boot at say the high-boot location, and the test version at the low-boot. If the low-boot version doesn't boot, power-down, flip the BMS toggle switch, power-up and boot-high, reflash to the next low-boot test version, and continue.
I personally haven't tried the trick, but it sounded like a nice idea.
Low-boot is the only sane method for booting, since high-boot sticks the bootloader 8MB into your 32MB/64MB/etc Flash ... I mean who uses 8MB Flash these days ... :)
Cheers, Dave
David Hawkins wrote:
Arrr, my insanity. Wolfgang is correct, of course.
Gee, and I was just going to ask why on earth you liked high-boot :)
I've seen one novel use of high-boot that could make it useful if you're lazy and can't be bothered plugging in your debugger ;)
Or the hardware weenies have it in a different building.
Assuming your board has a toggle switch that sets the state of BMS in the RCW (as most Freescale boards do), you can put a 'good' version of U-Boot at say the high-boot location, and the test version at the low-boot. If the low-boot version doesn't boot, power-down, flip the BMS toggle switch, power-up and boot-high, reflash to the next low-boot test version, and continue.
I personally haven't tried the trick, but it sounded like a nice idea.
That works great. It saved my a$$ there more than once. :-/ (The Freescale eval boards generally support this - very handy.)
Low-boot is the only sane method for booting, since high-boot sticks the bootloader 8MB into your 32MB/64MB/etc Flash ... I mean who uses 8MB Flash these days ... :)
Cheers, Dave
Best regards, gvb
participants (5)
-
David Hawkins -
Jatin Sharma -
Jerry Van Baren -
Scott Wood -
Wolfgang Denk