[U-Boot-Users] U-Boot port to a new AT91RM9200 board

[U-Boot-Users] U-Boot port to a new AT91RM9200 board

[Guido Classen]

Hello,

I am working on a port of U-Boot to our CCM2200 board. This board is
composed of an Atmel AT91RM9200 CPU, NOR and NAND Flashes and also some
serial and parallel I/O.

My port is running well row using the latest git sources. If someone is
interested in the board specific code I can contribute it.

But first I want to ask some questions about the ARM U-Boot source and clean
up my patches according your answer.

- include/asm/mach-types.h
  this file seems to be taken from the ARM-Linux kernel. But it is really
  outdated. Is there a periodically update for this file? I need the
  definition for our board machine id. The file will be generated
  automatically by the Linux kernel using a text file as template which comes
  from the board database on the ARM-Linux website. If the file is not
  automatically generated I can send you a patch containing the current
  version.

- include/asm/arch-at91rm9200/AT91RM9200.h
  I miss some definitions in this file like the constants to access the
  PIOD. Is it okay to add this definitions or should they go to the board
  specific header? I have seen the current Linux kernel has new own header
  files for the definition of AT91RM9200 registers and doesn't rely longer on
  the files supplied by Atmel. Is it considered to include these files in
  future u-boot releases?

Our board is designed for outdoor usage, so it is not handy to do software
updates using a laptop computer. The good support of USB-storage devices was
one reason for us to choose u-boot. Updating flash images works well with USB
Flash memory sticks. But it must be triggered by entering U-Boot commands.  Is
there a way to redirect U-Boot's STDIN to a file on VFAT medium in terms of
getting a real disk shell script facility? I've read README.console but there
is now word about FAT files? I think in combination with the hush shell this
would be a very powerful way to do all kind of updates and complex boot
sequences.  Sorry if I have overseen something and this feature is already
present in U-Boot.

Many thanks in advance for reading and answering my questions.

  Guido

[U-Boot-Users] U-Boot port to a new AT91RM9200 board

[Marco Cavallini]

Guido Classen ha scritto:
> Hello,
> 
> I am working on a port of U-Boot to our CCM2200 board. This board is
> composed of an Atmel AT91RM9200 CPU, NOR and NAND Flashes and also some
> serial and parallel I/O.

There are some important patches for AT91 you must apply to u-boot-1.1.4 
before starting customizing it, look at ML history messages.

HTH
ciao
-- 
Marco Cavallini
Koan s.a.s. - Bergamo - ITALIA
Embedded and Real-Time Software Engineering
www.koansoftware.com    |    www.klinux.org

[U-Boot-Users] U-Boot port to a new AT91RM9200 board

[Guido Classen]

Hi Marco,

> There are some important patches for AT91 you must apply to u-boot-1.1.4
> before starting customizing it, look at ML history messages.
>

Thanks for your answer. I am relative new at U-Boot. I've started with a
customized U-Boot 1.1.3 using "boot.bin" as primary bootstrap code.
Shortly I switch to U-Boot 1.1.4 using the current GIT sources. So I am not
sure which patches are already applied here.
My board doesn't boot from serial flashes so I think I don't need these
flashes. I have a normal parallel NOR-Flash for booting U-Boot.

U-Boot 1.1.4 now boots perfectly without using an primary bootloader and
without CONFIG_SKIP_LOWLEVEL_INIT define it initializes clocks and SDRAM
controller successfully by itself!

Now I am cleaning up my code and trying to move my modifications in the board
specific code. Therefore my questions in the first mail.

Regards
  Guido

[U-Boot-Users] U-Boot port to a new AT91RM9200 board

[Stefan Roese]

Hi Guido,

On Friday 26 May 2006 20:32, Guido Classen wrote:
> Our board is designed for outdoor usage, so it is not handy to do software
> updates using a laptop computer. The good support of USB-storage devices
> was one reason for us to choose u-boot. Updating flash images works well
> with USB Flash memory sticks. But it must be triggered by entering U-Boot
> commands.  Is there a way to redirect U-Boot's STDIN to a file on VFAT
> medium in terms of getting a real disk shell script facility? I've read
> README.console but there is now word about FAT files? I think in
> combination with the hush shell this would be a very powerful way to do all
> kind of updates and complex boot sequences.  Sorry if I have overseen
> something and this feature is already present in U-Boot.

If I understand you correctly, you would like to have an automatic update when 
a specific USB stick is connected to your board. Right? If yes, then take a 
look at the file "board/esd/common/auto_update.c". Could be helpful for you.

Best regards,
Stefan

[U-Boot-Users] U-Boot port to a new AT91RM9200 board

[Guido Classen]

Hi Stefan,

> If I understand you correctly, you would like to have an automatic update when
> a specific USB stick is connected to your board. Right? If yes, then take a
> look at the file "board/esd/common/auto_update.c". Could be helpful for you.

Thank you!

I have taken a short look at your file. The AU_SCRIPT case seems to be very
close to me intention. It seems you have additional types containing the
concrete flash images. My idea was to create a initial script file on the
USB stick containing a sequences of commands to do the necessary flash updates
like:

fatload usb 0 $(loadaddr) my_nor_image;
erase ... ...
cp.b $(loadaddr) ... $(filesize)
fatload usb 0 $(loadaddr) my_nand_image;
nand erase clean ... ...
nand write.jffs2 $(loadaddr) ... $(filesize)

By modification of a such script you can define which memory regions on the
target are actually update. It should by also possible to do other things
by suitable scritps like directly boot a Linux-Kernel from the USB-stick.
But I think it is also true for your solution.

It seems you are using compact flash, not USB, is this right? For me it is
not important to detect a special update USB flash stick using a magically
file or similar. Important is if you can do the update in field without
using an computer, terminal program and typing in commands. USB seems to be
more problematic if it is enabled on every boot as I read in the U-Boot
documentation. So I prefer to use a DIP-switch on the board to set in an
"update mode".

Regards
  Guido

[U-Boot-Users] U-Boot port to a new AT91RM9200 board

[Wolfgang Denk]

In message <5c01f02f0605261132m343a1632pc166dfc4f52db3cd@mail.gmail.com> you wrote:
> 
> But first I want to ask some questions about the ARM U-Boot source and clean
> up my patches according your answer.
> 
> - include/asm/mach-types.h
>   this file seems to be taken from the ARM-Linux kernel. But it is really
>   outdated. Is there a periodically update for this file? I need the

No. The file gets updated on demand only.

> - include/asm/arch-at91rm9200/AT91RM9200.h
>   I miss some definitions in this file like the constants to access the
>   PIOD. Is it okay to add this definitions or should they go to the board

It is OK to add missing definitions here.

>   specific header? I have seen the current Linux kernel has new own header
>   files for the definition of AT91RM9200 registers and doesn't rely longer > on
>   the files supplied by Atmel. Is it considered to include these files in
>   future u-boot releases?

Not yet. But feel free to submit a patch to  implement  this;  if  it
works on the existing boards...

> Flash memory sticks. But it must be triggered by entering U-Boot commands. Is
> there a way to redirect U-Boot's STDIN to a file on VFAT medium in terms of
> getting a real disk shell script facility? I've read README.console but there

No. But you can create script images (= shell scripts) and run these.
See the manual.

> is now word about FAT files? I think in combination with the hush shell this
> would be a very powerful way to do all kind of updates and complex boot
> sequences.  Sorry if I have overseen something and this feature is already
> present in U-Boot.

It's present. It's called script images.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anything free is worth what you pay for it.