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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox