All of lore.kernel.org
 help / color / mirror / Atom feed
From: JerryVanBaren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] FSBBP: uboot Programming on to the flash for MPC8548 for bootup
Date: Tue, 09 Sep 2008 09:08:30 -0400	[thread overview]
Message-ID: <48C6754E.2040101@ge.com> (raw)
In-Reply-To: <2acbd3e40809081445r66ef1217oc2abba50c7d4e573@mail.gmail.com>

Andy Fleming wrote:
> On Wed, Aug 27, 2008 at 12:16 AM, Ajeesh Kumar <ajeesh@tataelxsi.co.in> wrote:
>> hi sir/madam,
>>
>> I'm using a MPC8548E processor(power pc) also, i've interfaced a nor flash
>> of 128 MB to the processor.
>> i've read few documents and got to know that the uboot.bin should be
>> programmed at 0xfff80000.
>> Also, when i saw the uboot.bin size it was 512K. so, it could fit between
>> 0xfff80000 - 0xffffffff.
>> I 'M USING ABATRON BDI2000/BDI3000 FOR THIS.
>> Now my question is:
>> 1) If i'm making changes(addition/deletion of code) to the bootloader(uboot
>> 1.2) and re compile it, i believe that the size of the uboot.bin will get
>> changed i.e >/< 512K. NOW AT WHICH LOCATION I SHOULD FLASH THE
>> UBOOT.BIN(SIZE IS NOT EQUAL TO 512)
>> FOR Eg.  If my uboot.bin size is >512K ?????
> 
> 
> Well, it's not likely you will change the size of the binary.  You
> see, the 512K size is a result of a quirk of the 85xx platform.  The
> reset vector is at 0xfffffffc, but we define the base address to be
> 0xfff80000, so we fill in the space between, and it's 512K.
> 
> The result is, you don't need to mind the size, unless you grow the
> compiled output by over 200K.  Try to avoid that ;)
> 
> Andy

Hi Andy,

I was looking at the MPC8548CDS config.  The memory map is:
   0xFFF80000 256K - u-boot
   0xFFFC0000 128K - env
   0xFFFE0000 128K - reset vector & bootpage (only one 4K page used!)

Putting the env between u-boot and the reset vector is a horrible thing 
to do.  As a result, the top page of flash is almost entirely unused and 
is very difficult to use.

I have a EP8548 config (whose origins was the MPC8548CDS config) that I 
modified to use this memory map:
   0xFFFA0000 128K - env
   0xFFFC0000 256K - incl reset vector & bootpage

Is there any reason *not* to do this?  (The only downside I can think of 
is that existing boards with the CDS-style map would get their env 
erased when reprogrammed with a revised memory map u-boot, but that is 
easy enough to recover from.)

Best regards,
gvb

      parent reply	other threads:[~2008-09-09 13:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-27  5:16 [U-Boot] FSBBP: uboot Programming on to the flash for MPC8548 for bootup Ajeesh Kumar
2008-09-08 21:45 ` Andy Fleming
2008-09-09  2:50   ` Ajeesh Kumar
2008-09-09 13:08   ` JerryVanBaren [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48C6754E.2040101@ge.com \
    --to=gerald.vanbaren@ge.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.