public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Nicholas Kinar <n.kinar@usask.ca>
To: u-boot@lists.denx.de
Subject: [U-Boot] Booting kernel from NAND flash on AT91SAM9 custom board using fsload
Date: Sat, 02 Apr 2011 11:38:44 -0600	[thread overview]
Message-ID: <4D975F24.8060409@usask.ca> (raw)
In-Reply-To: <20110329215106.DF78AEDFFCF@gemini.denx.de>

On 11-03-29 03:46 PM, Nicholas Kinar wrote:
>> Thanks for your response, Wolfgang - I will switch the file system to
>> UBI/UBIFS, and then post back what I've done.  I've been looking in the
>> include/configs/sheevaplug.h directory, and I think that this small
>> embedded computer is now using UBIFS as the NAND flash file system.  So
>> changing the configs for my embedded system should be reasonably
>> straightforward.
>>

On 11-03-29 03:51 PM, Wolfgang Denk wrote:
> Dear Nicholas Kinar,
>
> In message<4D92531E.4030206@usask.ca>  you wrote:
>> I would assume that the "fsload" command will also work with UBIFS as well.
> No. UBIFS uses it's own command set; you will use "ubifsload" instead.
>
>> In my custom system, At91Bootstrap is situated on SPI Dataflash.  The
>> At91Bootstrap loads U-Boot from the same Dataflash.  Then, I would like
>> U-Boot to load the Linux kernel from the UBI file system on a large 2
>> GByte NAND flash.  This should be much better than using JFFS2 on the
>> large NAND flash.
> Indeed.
>
> Best regards,
>
> Wolfgang Denk
>

Thanks again for your help, Wolfgang; this is greatly appreciated.  I've 
now set up U-Boot so that I can read and mount UBI partitions on my NAND 
flash.  (Booting the kernel from UBI is another matter - see below for 
further details.)  Qualitatively, I find that UBI mounts much quicker 
than JFFS2, and I will be using this file system for my new embedded system.

To turn on U-Boot support, I had to include the following defines in my 
board config file.  After doing so, I was able see the ubi commands 
after typing the U-Boot help command.  These are the defines from my 
board config file:

#define CONFIG_CMD_NAND
#define CONFIG_CMD_UBI
#define CONFIG_CMD_UBIFS
#define CONFIG_RBTREE
#define CONFIG_MTD_DEVICE
#define CONFIG_MTD_PARTITIONS
#define CONFIG_CMD_MTDPARTS
#define CONFIG_LZO

I set up three partitions on the NAND flash by defining the mtdids and 
mtdparts environment variables.  Here is the output of the "mtdparts" 
command in U-Boot:

U-Boot> mtdparts

device nand0 <flash>, # parts = 3
  #: name                size            offset          mask_flags
  0: kernel              0x00a00000      0x00000000      0
  1: root                0x06400000      0x00a00000      0
  2: storage             0x79200000      0x06e00000      0

active partition: nand0,0 - (kernel) 0x00a00000 @ 0x00000000

defaults:
mtdids  : nand0=flash
mtdparts: mtdparts=flash:10M(kernel),100M(root),-(storage)


Then, I switched to each partition using the ubi part commands.  After 
switching to each partition, I created a volume on each partition.  The 
sequence of commands are shown below.  Each command completed 
successfully without errors:

U-Boot> ubi part kernel
U-Boot> ubi create container
U-Boot> ubi part root
U-Boot> ubi create container
U-Boot> ubi part storage
U-Boot> ubi create container


On the host Linux system, I created kernel and root image files using 
the mkfs.ubifs command-line tools (compiled from git):

mkfs.ubifs -x none -r ./images -m 4096 -e 258048 -c 43 -U -v -o kernel.img
mkfs.ubifs -x none -r ./target -m 4096 -e 258048 -c 450 -U -v -o root.img

These image files were transferred to the target system over the serial 
port using the U-Boot "loadb" command.  The image files were then copied 
to each UBI partition using the "ubi write" command.  By using the 
"ubifsmount" command, I am able to mount each of the "container" 
partitions and read the contents using the "ubifsls" command.  For example:

U-Boot> ubi part kernel
Creating 1 MTD partitions on "nand0":
0x000000000000-0x000000a00000 : "mtd=0"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   262144 bytes (256 KiB)
UBI: logical eraseblock size:    258048 bytes
UBI: smallest flash I/O unit:    4096
UBI: sub-page size:              1024
UBI: VID header offset:          1024 (aligned 1024)
UBI: data offset:                4096
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=0"
UBI: MTD device size:            10 MiB
UBI: number of good PEBs:        40
UBI: number of bad PEBs:         0
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             0
UBI: total number of reserved PEBs: 40
UBI: number of PEBs reserved for bad PEB handling: 2
UBI: max/mean erase counter: 4/1
U-Boot> ubifsmount container
UBIFS: mounted UBI device 0, volume 0, name "container"
UBIFS: mounted read-only
UBIFS: file system size:   6193152 bytes (6048 KiB, 5 MiB, 24 LEBs)
UBIFS: journal size:       2322433 bytes (2268 KiB, 2 MiB, 8 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: no compression
UBIFS: reserved for root:  0 bytes (0 KiB)
U-Boot> ubifsls
           1256920  Thu Mar 31 16:19:57 2011  uImage


I then used the "ubifsload" command to load the uImage into SDRAM memory:

U-Boot> ubifsload 0x22000000 uImage
Loading file 'uImage' to addr 0x22000000 with size 1256920 (0x00132dd8)...
Done

The "bootargs" environment variable was set to be the following:

U-Boot> setenv bootargs console=ttyS0,115200 rootfstype=ubifs ubi.mtd=1 
root=ubi0:container mtdparts=flash:10M(kernel),100M(root),-(storage)

However, after running the "bootm" command, I find that I cannot boot 
the Linux kernel, and the booting process hangs:

U-Boot> bootm
## Booting kernel from Legacy Image at 22000000 ...
    Image Name:   Linux-2.6.37
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    1256856 Bytes = 1.2 MiB
    Load Address: 20008000
    Entry Point:  20008000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
OK

Starting kernel ...

In the Linux kernel xconfig, I've switched on support for UBI and 
UBIFS.  I am wondering what might be the problem here.  Are the bootargs 
being passed properly to the Linux kernel?

Nicholas

  reply	other threads:[~2011-04-02 17:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-29 16:14 [U-Boot] Booting kernel from NAND flash on AT91SAM9 custom board using fsload Nicholas Kinar
2011-03-29 17:37 ` Nicholas Kinar
2011-03-29 17:56   ` Scott Wood
2011-03-29 20:35     ` Nicholas Kinar
2011-03-29 20:46       ` Scott Wood
2011-03-29 20:57         ` Nicholas Kinar
2011-03-29 21:05       ` Wolfgang Denk
2011-03-29 21:46         ` Nicholas Kinar
2011-03-29 21:51           ` Wolfgang Denk
2011-04-02 17:38             ` Nicholas Kinar [this message]
2011-04-03  1:50               ` Nicholas Kinar
2011-04-04  1:25                 ` Nicholas Kinar
2011-03-30  7:17         ` Joakim Tjernlund
2011-03-30  8:54           ` Wolfgang Denk

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=4D975F24.8060409@usask.ca \
    --to=n.kinar@usask.ca \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox