[U-Boot] building and updating u-boot on redboot based

[U-Boot] building and updating u-boot on redboot based

[Vipul Jain]

Date: Sun, 21 Feb 2010 11:21:20 +0100
From: Matthias Kaehlcke <matthias@kaehlcke.net>
Subject: Re: [U-Boot] building and updating u-boot on redboot based
       board
To: Vipul Jain <vipulsj@gmail.com>
Cc: u-boot at lists.denx.de
Message-ID: <20100221102120.GR20201@darwin
>
Content-Type: text/plain; charset=us-ascii

Hi,

El Sat, Feb 20, 2010 at 05:31:48PM -0800 Vipul Jain ha dit:

> 1. How to know if u-boot image I have build is build correctly?

the image is build correctly if the file u-boot.bin is
generated. another question is if this image is appropriate for your
board

> 2. I have redboot on my EP9302 SOC (Cirrus logic), can I load u-boot in
> memory and test if it works? What will be the memory address I need to
> download the image?

in order to start U-Boot from RAM you must define
CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT. the memory
address depends on your board. for a edb9302 try 0x01000000, for
edb9302a 0xc1000000

be aware that even if the U-Boot image starts from RAM this doesn't
mean automatically that it will boot on your board. when booting from
RAM low-level initialization is skipped (i.e. the environment set up
by redboot is used), when U-Boot boots from flash it is in charge to
do the low-level init.

> 3. How can I burn the u-boot image if I find every thing ok?

if your board is a Cirrus Logic edb9302, refer to the paragraph
"Download Utility" in chapter 7 of the technical reference
manual. otherwise consult the manual provided by your board
manufacturer.

i think you could skip step 2 (try to load U-Boot from RAM), as you
can always restore your RedBoot bootloader using the same procedure as
for flashing the U-Boot image

btw, which version of U-Boot are you using, the current development
version or a custom one?

best regards

--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona

Hi Matthias,

   I am using the latest source of u-boot that I have gitted from git://
git.denx.de/u-boot.git
here.  Can you please also tell me how to find out memory address for any
particular
board to download u-boot image. either from u-boot source or from board
specific technical
manual (PRM).

Also, I did tried last night the following command and now board is not
responding to anything,
Is there any way to recover the board back either via software/jumper
setting or JTAG. if JTAG
I am not sure which one and how to go about it, if there any pointer to
these. I really appreciate
your help, in making newbies learn.

RedBoot> load -r -v -b 0x100000 -h 192.168.15.6
u-boot.bin
-

Raw file loaded 0x00100000-0x00119ee7, assumed entry at 0x00100000
RedBoot> fis write -f 0x60000000 -b 0x100000 -l 0x40000
<------------------------ I gave this number from some website

                                                  how to find this number ??

* CAUTION * about to program
FLASH
            at 0x60000000..0x6003ffff from 0x00100000 - continue (y/n)?
y
... Erase from 0x60000000-0x60040000:
..
... Program from 0x00100000-0x00140000@0x60000000:
..
RedBoot>
reset
... Resetting.


Regards,
Vipul.

[U-Boot] building and updating u-boot on redboot based

[Matthias Kaehlcke]

El Sun, Feb 21, 2010 at 09:36:53AM -0800 Vipul Jain ha dit:

>       I am using the latest source of u-boot that I have gitted from
>    git://git.denx.de/u-boot.git
>    here.

good!

>    Can you please also tell me how to find out memory address for any
>    particular
>    board to download u-boot image. either from u-boot source or from board
>    specific technical
>    manual (PRM).

the u-boot source won't be of any help here, especially if your board
is not supported. is your board either a Cirrus Logic edb9302 or
edb9302a? both of them should be supported, though in lack of a board
i have not been able to test.

i am not sure if i understand to which memory address you are
referring: the address in flash? in this case 0x60000000 should be
correct.

the base address of the SDRAM on your board depends on the chip select
used for RAM. information about the chip select you can most likely
find in the user manual, otherwise consult the schematics of your
board. i can't provide further help here as i don't know which board
you are using.

>    Also, I did tried last night the following command and now board is not
>    responding to anything,
>    Is there any way to recover the board back either via software/jumper
>    setting or JTAG. if JTAG
>    I am not sure which one and how to go about it, if there any pointer to
>    these. I really appreciate
>    your help, in making newbies learn.

for recovery the easiest is re-flash redboot via the serial port. the
ep93xx BSP provided by Cirrus Logic
(http://arm.cirrus.com/files/linux/releases/linux-2.4/cirrus-arm-linux-1.4.5.tar.bz2)
contains a utility called 'download' for this purpose. you need to put
a jumper in order to configure the processor for UART boot. this
jumper is board specific, i am sure the manual of your board has
instructions for this.

please don't forget to mention which board you are using, otherwise
providing help is impossible

-- 
Matthias Kaehlcke
Embedded Linux Developer
Barcelona

          We can't solve problems by using the same kind
             of thinking we used when we created them
                         (Albert Einstein)
                                                                 .''`.
    using free software / Debian GNU/Linux | http://debian.org  : :'  :
                                                                `. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-

[U-Boot] building and updating u-boot on redboot based

[Vipul Jain]

Hi Matthias,

   I am Using Cirrus Logic EP9302-CQZ board. The memory address I was
talking about
was ram address to download u-Boot (as you mentioned earlier it can be
0x1000000) and then perform
the actual flash update command by using flash address and RAM
addr(0x1000000) from
where to pick the image. I am not sure though what value to give to the
u-boot size option flag.
i.e. say on redboot

fis write -f 0x60000000 -b 0x100000 -l 0x40000
                  Flash addr        Ram addr       Size   <-- how to find
size value
                                           How to find
                                           for a particular
                                           board.

 so I was wondering if there is any general way to find out such u-boot
image download ram address
and size . Also, if you don't mind can you please guide me with steps to
follow in-order to boot the board from
UART and to flash the board with new image. Thanks a lot for your kind help.

Regards,
Vipul.


On Sun, Feb 21, 2010 at 10:07 AM, Matthias Kaehlcke
<matthias@kaehlcke.net>wrote:

> El Sun, Feb 21, 2010 at 09:36:53AM -0800 Vipul Jain ha dit:
>
> >       I am using the latest source of u-boot that I have gitted from
> >    git://git.denx.de/u-boot.git
> >    here.
>
> good!
>
> >    Can you please also tell me how to find out memory address for any
> >    particular
> >    board to download u-boot image. either from u-boot source or from
> board
> >    specific technical
> >    manual (PRM).
>
> the u-boot source won't be of any help here, especially if your board
> is not supported. is your board either a Cirrus Logic edb9302 or
> edb9302a? both of them should be supported, though in lack of a board
> i have not been able to test.
>
> i am not sure if i understand to which memory address you are
> referring: the address in flash? in this case 0x60000000 should be
> correct.
>
> the base address of the SDRAM on your board depends on the chip select
> used for RAM. information about the chip select you can most likely
> find in the user manual, otherwise consult the schematics of your
> board. i can't provide further help here as i don't know which board
> you are using.
>
> >    Also, I did tried last night the following command and now board is
> not
> >    responding to anything,
> >    Is there any way to recover the board back either via software/jumper
> >    setting or JTAG. if JTAG
> >    I am not sure which one and how to go about it, if there any pointer
> to
> >    these. I really appreciate
> >    your help, in making newbies learn.
>
> for recovery the easiest is re-flash redboot via the serial port. the
> ep93xx BSP provided by Cirrus Logic
> (
> http://arm.cirrus.com/files/linux/releases/linux-2.4/cirrus-arm-linux-1.4.5.tar.bz2
> )
> contains a utility called 'download' for this purpose. you need to put
> a jumper in order to configure the processor for UART boot. this
> jumper is board specific, i am sure the manual of your board has
> instructions for this.
>
> please don't forget to mention which board you are using, otherwise
> providing help is impossible
>
> --
> Matthias Kaehlcke
> Embedded Linux Developer
> Barcelona
>
>           We can't solve problems by using the same kind
>             of thinking we used when we created them
>                         (Albert Einstein)
>                                                                 .''`.
>    using free software / Debian GNU/Linux | http://debian.org  : :'  :
>                                                                `. `'`
> gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-
>

[U-Boot] building and updating u-boot on redboot based

[Matthias Kaehlcke]

El Sun, Feb 21, 2010 at 10:22:34AM -0800 Vipul Jain ha dit:

>    I am Using Cirrus Logic EP9302-CQZ board.

i don't think so, EP9302-CQZ is a processor, not a board, please
verify again

>    The memory address I was talking about
>    was ram address to download u-Boot (as you mentioned earlier it can be
>    0x1000000) and then perform
>    the actual flash update command by using flash address and RAM
>    addr(0x1000000) from
>    where to pick the image. I am not sure though what value to give to the
>    u-boot size option flag.

0x40000 for size of u-boot is ok

>    i.e. say on redboot
> 
>    fis write -f 0x60000000 -b 0x100000 -l 0x40000
>                      Flash addr        Ram addr       Size   <-- how to find
>    size value
>                                               How to find
>                                               for a particular
>                                               board.
> 
>     so I was wondering if there is any general way to find out such u-boot
>    image download ram address and size .

if the base address of your SDRAM is 0x00000000 (like on the edb9302
board), than 0x100000 should be ok. otherwise you probably just wrote
random values to the flash.

there is no general way for the ram address, it's board specific

>    Also, if you don't mind can you please guide me with steps to
>    follow in-order to boot the board from
>    UART and to flash the board with new image. Thanks a lot for your kind
>    help.

i repeat, without knowing the board you are using (and find
information online if it's not an edb9302 or edb9302a) is impossible.

-- 
Matthias Kaehlcke
Embedded Linux Developer
Barcelona

          Dreams and reality are opposites. Action synthesizes them
                             (Assata Shakur)
                                                                 .''`.
    using free software / Debian GNU/Linux | http://debian.org  : :'  :
                                                                `. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-

[U-Boot] building and updating u-boot on redboot based

[Vipul Jain]

Hi Matthias,

I did update my board after applying the patch you sent and I found no
problem with booting up
of the board. The only visible change to me was in U-Boot version string
with latest time stamp
and -dirty appended as below.

Before Update:
U-Boot 2009.11-00400-g77e7273 (Feb 21 2010 - 01:15:31)

After Update:
U-Boot 2009.11-00400-g77e7273-dirty (Feb 22 2010 - 13:06:39)

Is there any specific test/command you would like me to execute?

Regards,
Vipul.


On Mon, Feb 22, 2010 at 12:35 PM, Matthias Kaehlcke
<matthias@kaehlcke.net>wrote:

> hi vipul,
>
> something must have gone wrong when copying the patch to the mail ...
> i attached the patch to this mail, i hope this works better
>
> thanks for testing!
>
> matthias
>
>
> El Mon, Feb 22, 2010 at 12:05:29PM -0800 Vipul Jain ha dit:
>
> >      I tried to copy paste the diffs into a text file called
> >    ep93xx.sdram.patch and ran patch command
> >    but it rejected/failed. I did notice that in the email the diff has
> >    mingled around the @@ -R +R@@
> >    with the source code line as below:
> >    @@ -101,6 +120,11 @@ static void setup_refresh_timer(void)
> >
> >    I was wondering, if you could send me the diff in text file rather can
> >    copy paste it in email.
> >
> >    I am attaching the patch file I created the rej report that got
> created in
> >    case you would like to
> >    have a look.
> >
> >    Regards,
> >    Vipul.
> >
> >    On Mon, Feb 22, 2010 at 1:04 AM, Matthias Kaehlcke <
> matthias at kaehlcke.net>
> >    wrote:
> >
> >      hi vipul,
> >
> >      El Sun, Feb 21, 2010 at 01:13:22PM -0800 Vipul Jain ha dit:
> >      >      I had two workspaces one which I got from main u-boot source
> base
> >      and
> >      >    other from
> >      >    git clone git://gitorious.org/u-boot-ep93xx/u-boot-ep93xx.git
> >      >    and by mistake I used u-boot.bin image build from this ep93xx
> >      specific
> >      >
> >      >    source tree which made my board unbootable. This time I build
> the
> >      image
> >      >    from main
> >      >    u-boot git source while using the download tool and it powered
> up
> >      as
> >      >    smooth as it
> >      >    can without any issues. so I believe that main u-boot source is
> >      perfect.
> >      >
> >      >    Sorry about any confusion. Will have to now figure out how to
> >      restore
> >      >    linux kernel
> >      >    back? ... :)
> >      >
> >      >    Please kindly let me know if you want me to perform any kind of
> >      testing
> >      >    for ep9302.
> >      >    I will be more than happy if I could be of any help to you.
> >
> >      as i told you in a previous mail the current SDRAM initialization
> >      isn't totally correct. it works on most boards, but doesn't follow
> the
> >      sequence in the specification. below is a patch that works on my
> >      edb9301 and edb9307a boards, it would be good to know if this is
> also
> >      true for the edb9302.
> >
> >      when you find some time could you please apply it on your tree and
> >      tell me if the board boots?
> >
> >      thanks
> >
> >      Matthias
> >
> >      ---
> >
> >      diff --git a/board/edb93xx/sdram_cfg.c b/board/edb93xx/sdram_cfg.c
> >      index 6155f0e..61950f3 100644
> >      --- a/board/edb93xx/sdram_cfg.c
> >      +++ b/board/edb93xx/sdram_cfg.c
> >      @@ -1,5 +1,6 @@
> >       /*
> >      - * Copyright (C) 2009 Matthias Kaehlcke <matthias@kaehlcke.net>
> >      + * Copyright (C) 2010, 2009
> >      + * Matthias Kaehlcke <matthias@kaehlcke.net>
> >       *
> >       * Copyright (C) 2006 Dominic Rath <Dominic.Rath@gmx.de>
> >       *
> >      @@ -26,13 +27,13 @@
> >       #include "sdram_cfg.h"
> >       #include "early_udelay.h"
> >
> >      +#define PRECHARGE_BANK(bank)           (*(volatile uint32_t *)
> >      \
> >      +               (SDRAM_BASE_ADDR | SDRAM_BANK_SEL_##bank)) = 0
> >      +
> >       #define PROGRAM_MODE_REG(bank)         (*(volatile uint32_t *)
> >      \
> >                     (SDRAM_BASE_ADDR | SDRAM_BANK_SEL_##bank |
> >      SDRAM_MODE_REG_VAL))
> >
> >      -#define PRECHARGE_BANK(bank)           (*(volatile uint32_t *)
> >      \
> >      -                               (SDRAM_BASE_ADDR |
> >      SDRAM_BANK_SEL_##bank))
> >      -
> >      -static void force_precharge(void);
> >      +static void precharge_all_banks(void);
> >       static void setup_refresh_timer(void);
> >       static void program_mode_registers(void);
> >
> >      @@ -47,7 +48,7 @@ void sdram_cfg(void)
> >
> >             early_udelay(200);
> >
> >      -       force_precharge();
> >      +       precharge_all_banks();
> >
> >             setup_refresh_timer();
> >
> >      @@ -57,19 +58,37 @@ void sdram_cfg(void)
> >             writel(GLCONFIG_CKE, &sdram->glconfig);
> >       }
> >
> >      -static void force_precharge(void)
> >      +static void precharge_all_banks(void)
> >       {
> >      +       struct sdram_regs *sdram = (struct sdram_regs *)SDRAM_BASE;
> >      +
> >      +       /* Issue PRECHARGE ALL commands */
> >      +       writel(GLCONFIG_INIT | GLCONFIG_CKE, &sdram->glconfig);
> >      +
> >             /*
> >      -        * Errata most EP93xx revisions say that PRECHARGE ALL isn't
> >      always
> >      -        * issued.
> >      +        * Errata of most EP93xx revisions say that PRECHARGE ALL
> isn't
> >      always
> >      +        * issued
> >              *
> >      -        * Do a read from each bank to make sure they're precharged
> >      +        * Cirrus proposes a workaround which consists in performing
> a
> >      read from
> >      +        * each bank to force the precharge. This causes some boards
> to
> >      hang.
> >      +        * Writing to the SDRAM banks instead of reading has the
> same
> >      +        * side-effect (the SDRAM controller issues the necessary
> >      precharges),
> >      +        * but is known to work on all supported boards
> >              */
> >
> >             PRECHARGE_BANK(0);
> >      +
> >      +#if (CONFIG_NR_DRAM_BANKS >= 2)
> >             PRECHARGE_BANK(1);
> >      +#endif
> >      +
> >      +#if (CONFIG_NR_DRAM_BANKS >= 3)
> >             PRECHARGE_BANK(2);
> >      +#endif
> >      +
> >      +#if (CONFIG_NR_DRAM_BANKS == 4)
> >             PRECHARGE_BANK(3);
> >      +#endif
> >       }
> >
> >       static void setup_refresh_timer(void)
> >      @@ -101,6 +120,11 @@ static void setup_refresh_timer(void)
> >
> >       static void program_mode_registers(void)
> >       {
> >      +       struct sdram_regs *sdram = (struct sdram_regs *)SDRAM_BASE;
> >      +
> >      +       /* Select mode register update mode */
> >      +       writel(GLCONFIG_MRS | GLCONFIG_CKE, &sdram->glconfig);
> >      +
> >
> >          La guerra es un acto abominable en el que se matan personas que
> no
> >           se conocen, dirigidas por personas que se conocen y no se matan
> >
>  .''`.
> >         using free software / Debian GNU/Linux | http://debian.org  : :'
>  :
> >                                                                     `.
> `'`
> >      gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4
>  `-
>
>
> > --- board/edb93xx/sdram_cfg.c
> > +++ board/edb93xx/sdram_cfg.c
> > @@ -1,5 +1,6 @@
> >  /*
> > - * Copyright (C) 2009 Matthias Kaehlcke <matthias@kaehlcke.net>
> > + * Copyright (C) 2010, 2009
> > + * Matthias Kaehlcke <matthias@kaehlcke.net>
> >  *
> >  * Copyright (C) 2006 Dominic Rath <Dominic.Rath@gmx.de>
> >  *
> > @@ -26,13 +27,13 @@
> >  #include "sdram_cfg.h"
> >  #include "early_udelay.h"
> >
> > +#define PRECHARGE_BANK(bank)           (*(volatile uint32_t *)         \
> > +               (SDRAM_BASE_ADDR | SDRAM_BANK_SEL_##bank)) = 0
> > +
> >  #define PROGRAM_MODE_REG(bank)         (*(volatile uint32_t *)         \
> >                (SDRAM_BASE_ADDR | SDRAM_BANK_SEL_##bank |
> SDRAM_MODE_REG_VAL))
> >
> > -#define PRECHARGE_BANK(bank)           (*(volatile uint32_t *)         \
> > -                               (SDRAM_BASE_ADDR |
> SDRAM_BANK_SEL_##bank))
> > -
> > -static void force_precharge(void);
> > +static void precharge_all_banks(void);
> >  static void setup_refresh_timer(void);
> >  static void program_mode_registers(void);
> >
> > @@ -47,7 +48,7 @@ void sdram_cfg(void)
> >
> >        early_udelay(200);
> >
> > -       force_precharge();
> > +       precharge_all_banks();
> >
> >        setup_refresh_timer();
> >
> > @@ -57,19 +58,37 @@ void sdram_cfg(void)
> >        writel(GLCONFIG_CKE, &sdram->glconfig);
> >  }
> >
> > -static void force_precharge(void)
> > +static void precharge_all_banks(void)
> >  {
> > +       struct sdram_regs *sdram = (struct sdram_regs *)SDRAM_BASE;
> > +
> > +       /* Issue PRECHARGE ALL commands */
> > +       writel(GLCONFIG_INIT | GLCONFIG_CKE, &sdram->glconfig);
> > +
> >        /*
> > -        * Errata most EP93xx revisions say that PRECHARGE ALL isn't
> always
> > -        * issued.
> > +        * Errata of most EP93xx revisions say that PRECHARGE ALL isn't
> always
> > +        * issued
> >         *
> > -        * Do a read from each bank to make sure they're precharged
> > +        * Cirrus proposes a workaround which consists in performing a
> read from
> > +        * each bank to force the precharge. This causes some boards to
> hang.
> > +        * Writing to the SDRAM banks instead of reading has the same
> > +        * side-effect (the SDRAM controller issues the necessary
> precharges),
> > +        * but is known to work on all supported boards
> >         */
> >
> >        PRECHARGE_BANK(0);
> > +
> > +#if (CONFIG_NR_DRAM_BANKS >= 2)
> >        PRECHARGE_BANK(1);
> > +#endif
> > +
> > +#if (CONFIG_NR_DRAM_BANKS >= 3)
> >        PRECHARGE_BANK(2);
> > +#endif
> > +
> > +#if (CONFIG_NR_DRAM_BANKS == 4)
> >        PRECHARGE_BANK(3);
> > +#endif
> >  }
> >
> >  static void setup_refresh_timer(void)
> > @@ -101,6 +120,11 @@ static void setup_refresh_timer(void)
> >
> >  static void program_mode_registers(void)
> >  {
> > +       struct sdram_regs *sdram = (struct sdram_regs *)SDRAM_BASE;
> > +
> > +       /* Select mode register update mode */
> > +       writel(GLCONFIG_MRS | GLCONFIG_CKE, &sdram->glconfig);
> > +
>
>
> --
> Matthias Kaehlcke
> Embedded Linux Developer
> Barcelona
>
>              You must have a plan. If you don't have a plan,
>               you'll become part of somebody else's plan
>                                                                  .''`.
>    using free software / Debian GNU/Linux | http://debian.org  : :'  :
>                                                                `. `'`
> gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-
>

[U-Boot] building and updating u-boot on redboot based

[Matthias Kaehlcke]

Hi Vipul,

El Mon, Feb 22, 2010 at 01:25:01PM -0800 Vipul Jain ha dit:

>    I did update my board after applying the patch you sent and I found no
>    problem with booting up
>    of the board. The only visible change to me was in U-Boot version string
>    with latest time stamp
>    and -dirty appended as below.

good news!

>    Before Update:
>    U-Boot 2009.11-00400-g77e7273 (Feb 21 2010 - 01:15:31)
> 
>    After Update:
>    U-Boot 2009.11-00400-g77e7273-dirty (Feb 22 2010 - 13:06:39)
> 
>    Is there any specific test/command you would like me to execute?

if the board boots with the modified SDRAM initialization no further
testing is required

thanks a lot for testing!

-- 
Matthias Kaehlcke
Embedded Linux Developer
Barcelona

    Tant qu'il y aura sur terre des hommes pour qui existe un concept
    d' 'honneur national', la menace d'une nouvelle guerre subsistera
                              (B. Traven)
                                                                 .''`.
    using free software / Debian GNU/Linux | http://debian.org  : :'  :
                                                                `. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-