Hi Michael,

On Mon, 4 Mar 2013 12:23:05 -0500, Michael Cashwell mboards@prograde.net wrote:

On Mar 4, 2013, at 10:40 AM, JPT j-p-t@gmx.net wrote:

...

It's a Netgear ReadyNAS Duo V2, and the original sofware sucks. ;) standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000; bootcmd=nand read.e 0x1200000 0x200000 0x600000;nand read.e 0x2000000 0x800000 0x1000000;bootm 0x1200000 0x2000000

Strange for a NAS to have a u-boot environment variable called "mvPhoneConfig". But anyway...

OT: that's (older) Marvell/LaCie U-Boots for you. They have lots of these weird ad hoc env vars, which exist across a whole range of products even when they make sense only for a few.

Amicalement,

Hi Jagan,

On Mon, 4 Mar 2013 23:02:58 +0530, Jagan Teki jagannadh.teki@gmail.com wrote:

Hi JPT,

On Mon, Mar 4, 2013 at 9:10 PM, JPT j-p-t@gmx.net wrote:

...

Hi,

I've got a NAS which uses uboot: U-Boot 1.1.4 (Feb 6 2012 - 14:40:46) Marvell version: 3.4.27

It's a Netgear ReadyNAS Duo V2, and the original sofware sucks. ;)

I would like to start with the original kernel (because it contains some patches) and a custom debian made with multistrap.

Where do I start?

I'll add some information about the config.

I believe these are the most important boot options.

standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;

bootcmd=nand read.e 0x1200000 0x200000 0x600000;nand read.e 0x2000000 0x800000 0x1000000;bootm 0x1200000 0x2000000

bootargs=console=ttyS0,115200 reason=normal mtdparts=nand_mtd:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x1000000@0x800000(minirootfs),0x6800000@0x1800000(jffs2);

there are 5 mtds: 1,5M mtd0 - ? 128K mtd1 - ? 6,0M mtd2 - kernel 2,2M mtd3 - initrd (gzipped) 89M mtd4 - jffs2 image, I think it contains a rescue image of the filesystem which is applied to the harddisks.

I dumped the kernel from mtd2, it is: u-boot legacy uImage, Linux-2.6.31.8.duov2, Linux/ARM, OS Kernel Image (Not compressed), 3442208 bytes, Tue Aug 28 05:21:43 2012, Load Address: 0x00008000, Entry Point: 0x00008000, Header CRC: 0xDA1ECA31, Data CRC: 0x269C27DE

I tried to load the kernel through tftp, but it crashed:

Marvell>> dhcp

BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 28 *** Unhandled DHCP Option in OFFER/ACK: 28 DHCP client bound to address 192.168.20.35 Marvell>> set serverip 192.168.20.24

Marvell>> tftpboot 0x02000000 /boot/kernel.img

Using egiga0 device TFTP from server 192.168.20.24; our IP address is 192.168.20.35 Filename '/boot/kernel.img'. Load address: 0x2000000 Loading: ################################################################# ... done Bytes transferred = 3442272 (348660 hex) Marvell>> go 0x02000000

Is this load address for kernel is correct? likely to have 8000 multiples.. check it once.

Just about any address can be used to load and bootm (as Michael notes) a kernel image. And 2000000 is a multiple of 8000, as we are talking hex here. :)

...

## Starting application at 0x02000000 ... software interrupt pc : [<0200001c>] lr : [<00633cac>] sp : 005fef68 ip : ffffffff fp : 005ff7de r10: 005ff3de r9 : ffffe804 r8 : 005fffcc r7 : 005ff388 r6 : 00000001 r5 : 005ff38c r4 : 02000000 r3 : 30383101 r2 : f1012000 r1 : 005ff38c r0 : c0c0e0c4 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...

Try to debug the value from pc. Use the pc value using the instructions from doc/README.arm-unaligned-accesses

doc/README.unaligned-accesses is about data aborts, not SW interrupts.

Thanks, Jagan.

Amicalement,

On Mar 5, 2013, at 2:25 PM, JPT j-p-t@gmx.net wrote:

Hi,

wow, thanks. bootm worked fine. :)

Spiffy.

*** Next step, booting from disk I created a root fs on USB drive and tried to boot it.

usb start ext2load usb 0:1 0x02000000 /boot/kernel-DUO-1.0.22 bootm

this works, but the kernel doesn't know where to find the root partition. how do I have to pass the root= parameter to linux kernel?

this didn't work: set bootargs console=ttyS0,115200 root=/dev/sda1

bootargs is how you pass arguments to the kernel, so you're on track there.

The trick is what to pass. Your root= item is in the right direction. But the kernel needs to be configured appropriately. By that I'm talking about things like what bus (ATA, SATA, USB, etc.), what partitioning (MBR, GUID, MTD, etc.) and what file system (FAT*, ext2/3/4, etc.) the root fs will have. You have to have the supporting kernel configs enabled for those things.

You also need /dev to be setup early or the root argument will hit a dead end. I use these often: CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y

How do I find out the correct root device?

One trick is to look at the console log of the device booting whatever came with it. That will show you many of the kernel args. And if you have the matching kernel source and config it will make changes much easier than starting from nothing.

Or do I have to boot the "real" system after booting from inited?

You need to decide that. It can be done either way, either a small initrd that then does a pivot root or will it just directly mount. Both are possible but a kernel/rootfs setup for one will likely be unhappy trying to do the other.

*** Last step: save settings setting for automated boot up.

I tried to save, it writes something, but after issuing "reset" it's back to initial values. what's wrong?

Marvell>> saveenv Saving Environment to NAND... Erasing Nand...Writing to Nand... done

Sorry but I don't know about this one. I avoid raw NAND like the plague.

I don't know why it would write the env but not then read it back the next time.

When u-boot starts does it complain about the environment CRC being bad even after what appears to be a successful saveenv? That would sounds like a basic NAND flash problem (wrong part or geometry).

One last trick is to define DEBUG early in your config.h file and rebuild. Such a u-boot will spew enormous amounts of stuff to the console but it often will show what's happening in a case like that.

HTH, -Mike