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
next prev parent 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 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.