[U-Boot-Users] Increasing U-Boot partition size

[U-Boot-Users] Increasing U-Boot partition size

[Jatin Sharma]

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

[U-Boot-Users] Increasing U-Boot partition size

[Scott Wood]

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

[U-Boot-Users] Increasing U-Boot partition size

[Jatin Sharma]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

[U-Boot-Users] Increasing U-Boot partition size

[Scott Wood]

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

[U-Boot-Users] Increasing U-Boot partition size

[Jatin Sharma]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

[U-Boot-Users] Increasing U-Boot partition size

[Scott Wood]

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

[U-Boot-Users] Increasing U-Boot partition size

[Scott Wood]

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

[U-Boot-Users] Increasing U-Boot partition size

[Jerry Van Baren]

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

[U-Boot-Users] Increasing U-Boot partition size

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A Stanford research group advertised for participants in a  study  of
obsessive-compulsive  disorder. They were looking for therapy clients
who had been diagnosed with this disorder. The  response  was  grati-
fying;  they  got  3,000 responses about three days after the ad came
out. All from the same person.

[U-Boot-Users] Increasing U-Boot partition size

[Jerry Van Baren]

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

[U-Boot-Users] Increasing U-Boot partition size

[David Hawkins]

> 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

[U-Boot-Users] Increasing U-Boot partition size

[Jerry Van Baren]

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