> > I look like it replaces the original uboot on mtd0, is
> that correct ?
>
> I'm not sure anymore. I would have to investigate the
> script again first.
>
> > While openwrt is using original uboot to start another
> version so that if
> > you screw up you still have the original one to get
> things working again
> > without need for jtag.
>
> Yes, that's possible. AFAIK you just have to place the
> second u-boot to the
> NAND address where originally the kernel can be found. If
> it fails to load
> the second u-boot the first u-boot must be able to boot
> from usb to recover
> things. Otherwise without JTAG you are stuck, too.
Not really: you can use uboot to write to load via tftp and write to nand:
That's how I recovered from my dockstar invalid kernel CRC.
For anyone intrested insructions are quite clear on this on openwrt serial
console install.
> IIRC on mikrocontroller.net the layout of the JTAG
> connector can be found.
Yea I saw that but I'd still regard that as being more difficult then plying
with uboot from serial.
>
> > Just incase someone else needs it here is what the 2
> versions of ubuut
> > currently on my dockstar do: U-Boot 1.1.4 (Jul 16 2009
> - 21:02:16) Cloud
> > Engines (3.4.16)
>
> Is this the original one?
Not sure: it's the uboot that I found on my dockstar when I got it second hand.
Along with mtd1 content invalid (and hence no OS booting correctly).
> > ext2load- load binary file from a Ext2 filesystem
> > ext2ls - list files in a directory (default /)
I tryed that but got nothing. meybe because this uboot does not support usb ...
but then again where else would the dockstar have an ext2 filesystem ? directly
on flash without any ware levelling dedicated hardware would not be a smart
thing to do.
>
> This one can load the kernel of an ext2 file system. But I
> did not see any USB
> capabilities.
>
> > bootargs_root=root=/dev/mtdblock2 ro
>
> It expects root on mtd2.
>
> > bootcmd=nand read.e 0x800000 0x100000 0x40000; go
> 0x800000
>
> It loads a kernel from NAND address 0x40000 to RAM and
> boots it:
> > CE>> boot
> >
> > NAND read: device 0 offset 0x100000, size 0x40000
> >
> > Reading data from 0x100000 -- 0% ...
> > 262144 bytes read: OK
> > ## Starting application at 0x00800000 ...
>
>
> Second one:
> > U-Boot 2010.09 (Mar 10 2011 - 00:51:16)
> > Marvell-Sheevaplug
> >
> > SoC: Kirkwood 88F6281_A0
> > DRAM: 128 MiB
> > NAND: 256 MiB
> > *** Warning - bad CRC or NAND, using default
> environment
>
>
> > fatinfo - print information about filesystem
> > fatload - load binary file from a dos filesystem
> > fatls - list files in a directory (default /)
>
> Support loading kernel of a FAT partition but not of ext2
> (no problem).
>
> > usb - USB sub-system
> > usbboot - boot from USB device
>
> It supports loading the kernel from USB devices.
>
> > bootcmd=${x_bootcmd_kernel}; setenv bootargs
> ${x_bootargs}
> > ${x_bootargs_root}; ${x_bootcmd_usb}; bootm 0x6400000;
> bootdelay=3
> > baudrate=115200
> > ipaddr=169.254.254.243
> > serverip=169.254.254.254
>
> > x_bootargs=console=ttyS0,115200
> >
> mtdparts=orion_nand:1M(u-boot),1M@1M(second_stage_u-boot),3M@2M(kernel),32M
> >@5M(rootfs),219M@37M(data) rw x_bootcmd_kernel=nand
> read 0x6400000 0x200000
> > 0x300000
> It loads a kernel from NAND address 0x300000...
>
> > x_bootcmd_usb=usb start
> ... starts the usb system (no idea why) ....
>
> > x_bootargs_root=root=/dev/mtdblock3 rw
> rootfstype=jffs2
> ... and expects the root file system on mtd3 as jffs2.
>
>
> What you can do:
> Prepare a USB stick with a FAT boot partition. Place the
> kernel on it. Use
> usbstart and fatload to load the kernel to the RAM.
> Provide the right bootargs and your ARMed slack rootfs on
> the same USB stick.
> And run bootcmd.
I'll play with both uboot and see if I can boot armedslack in some way other
then using openwrt as an initrd to start armedslack.
If that fails I'll try jeff's enhanced uboot.
Thanks for the help.
_______________________________________________
ARMedslack mailing list
[email protected]
http://lists.armedslack.org/mailman/listinfo/armedslack