[hawkboard.org] tftp alternative for uImage and ramdisk porting

[vijen]

Hi,
I was struggling to download uImage and ramdisk on hawk board using
tftp, since it use to hang in middle and then i have to do power cycle
and try again. This was blocking my development work., later after
exploring u-boot command "nfs" there was no turn back.

I would suggest to use online guide to setup NFS server on your
host machine, and export a folder lets say /nfsroot with our host ip
192.168.0.100 and target (hawk) board ip of 192.168.0.110, and
absolutely make sure that firewall is allowing other computers to talk
on relevant ports for NFS. use this to check out fire wall setting

# system-config-firewall
( if your linux version has one, else use any other way to reach
firewall )

OR
following will do and will almost every time,

# iptable -F
( This is last option, it will temporarily flush all rule. If you
think your NFS server setting are right but not sure of firewall just
use above, else assume your NFS setting are not proper and try again )

then simply send uImage by using

hawkboard.org > nfs 0xc0700000 192.168.0.100:/nfsroot/uImage
hawkboard.org > nfs 0xc1180000 192.168.0.100:/nfsroot/ramdisk.gz

( I have kept the uImage and ramdisk in this folder you can keep it in
any other folder and export that instead )

Set the bootargs as you want either to boot file system over NFS after
sending uImage or to boot from ram after sending both uImage and
ramdisk.gz, see
http://elinux.org/Hawkboard/ for setting bootargs then simply boot
using

hawkboard.org > bootm c0700000

Hope this helps someone struggling with "tftp" .. "/^. .^\"

[Gaston]

Hi all,
My cross development base is a virtual Ubuntu 9.1. To be honest I dont
even know if it is possible to get to that machine from the host
network. Since I had to get a serial link up to be able to fiddle
around with uboot I searched for other options to get the kernel in.
There are several serial transfer protocols included in uboot. I
picked ymodem for its simplicity.
I will include my particular kernel in this example to highlight the
importance of size.

When the Ready signal is given I start the ymodem transfer of the
uImage file (I think it HAS to be named uImage)
--------------
hawkboard.org > loady 0xc0700000 115200
## Ready for binary (ymodem) download to 0xC0700000 at 115200 bps...
CCCCCCCxyzModem - CRC mode, 2(SOH)/2396(STX)/0(CAN) packets, 9 retries
## Total Size = 0x00256de4 = 2452964 Bytes
--------------

As you can see above the size is given both in hex and dec, very nice!

--------------
hawkboard.org > nand info

Device 0: NAND 128MiB 1,8V 8-bit, sector size 128 KiB
hawkboard.org > nand erase 0x200000 0x256de4

NAND erase: device 0 offset 0x200000, size 0x256de4
Erasing at 0x440000 -- 101% complete.
OK
hawkboard.org > nand erase 0x200000 0x260000

NAND erase: device 0 offset 0x200000, size 0x260000
Erasing at 0x440000 -- 100% complete.
OK
--------------

Some of these messages above confuse me, but no errors so lets
continue

--------------
hawkboard.org > nand write.e 0xc0700000 0x200000 0x256de4

NAND write: device 0 offset 0x200000, size 0x256de4
Attempt to write non page aligned data
2452964 bytes written: ERROR
--------------

ERROR, that doesn't sound good, lets try a bit longer section

--------------
hawkboard.org > nand write.e 0xc0700000 0x200000 0x260000

NAND write: device 0 offset 0x200000, size 0x260000
2490368 bytes written: OK
--------------

Now that seems quite ok, so now we have the uImage flashed to NAND at
0x200000 and the length is 0x256de4
I dont use ramdisk so I'll leave that for you to figure out.
I use a sdram with two partitions, first for uImage (not used, but
soon(tm) we hope for a new uboot).
Second is my rootfs, so I continue to set some bootargs and bootcmd in
uboot

-------------
hawkboard.org > setenv bootargs "mem=80M console=ttyS2,115200n8 root=/
dev/mmcblk0p2 rootwait rw init=/sbin/init ip=dhcp"
hawkboard.org > setenv bootcmd "setenv $bootargs;nand read.e
0xc0900000 0x200000 0x256DE4;bootm 0xC0900000"
hawkboard.org > saveenv
Saving Environment to NAND...
Erasing Nand...
Erasing at 0x0 -- 100% complete.
Writing to Nand... done
hawkboard.org >
-------------

This part above have more or less copied from another post here and it
has a typo in it, just ignore the error message on the "mem=80M"
stuff.
mem=80M (or something smaller than 128M at least) needs to be passed
to the kernel in order to get DSPLink to work.

For completeness this is the endresult of my uboot-environment
------------
hawkboard.org > printenv
bootdelay=3
baudrate=115200
bootfile="uImage"
ethaddr=0a:c1:a8:12:fa:c0
filesize=256DE4
bootargs=mem=80M console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootwait
rw init=/sbin/init ip=dhcp
bootcmd=setenv mem=80M console=ttyS2,115200n8 root=/dev/mmcblk0p2
rootwait rw init=/sbin/init ip=dhcp;nand read.e 0xc090
0000 0x200000 0x256DE4;bootm 0xC0900000
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.01-dirty (Nov 18 2009 - 23:30:48)

Environment size: 435/131068 bytes
hawkboard.org >
------------

I hope this inspired someone out there!

[Gaston]

Change of subject

[Syed Mohammed, Khasim]

Beautiful,

I will put this on blog, can you please put this up on elinux and link
it with hawkboard.

Regards,
Khasim

[Gaston]

Thanks!
My plans are to put together a set of notes for a complete
reproducible way of getting everything set up. It will not be generic,
just a reflection of what I did to get up and running.
I posted this part here so at least its off my todo-list. If anyone
wants to post it on elinux that's fine with me.

I just hope that this is one step closer to get to the DSP. What is
the next step?
Right, modifying the K40gstti-init so that it doesnt over run the
kernel space !
Hoppla
/Gaston



On May 18, 8:55 pm, "Syed Mohammed, Khasim " <sm.kha...@gmail.com>
wrote: