Flameman/dht-walnut/firmware

= Firmware Bootloaders =


 * ppcboot (not suggested)
 * U-Boot (it can't load kernel >=2.5.25)
 * U-Boot-kanojio (it's able to boot kernel >2.6.25 from {scsi, pata, sata, firewire, usb, net})

status:
 * uboot-1.2.0-kanojo: under development
 * uboot-1.2.0-hack-new: tftpboot is working with ramrootfs, ide is working
 * uboot-2009: tftpboot is working with ramrootfs, ide is not working, eth0 issued, tftpboot issued with a download > 6Mb ... aborted at all

download the latest uboot tested firmware
[[Media:uboot-dht-walnut-install-kit.tgz|uboot-dht-walnut-install-kit.tgz]]

U-Boot 1.1.4
!!!NOTE!!! uboot-v1.1.4 has an issue with tftp-boot ramrootfs, but it works well with disk-boot, you'd better use uboot-v1.2 for a good firmware replacement: good and solid rock state out of my tests !

uboot is a significantly updated replacement for ppcboot. U-Boot for the DHT-Walnut DENX U-Boot and Linux Guide for Walnut


 * Information on U-Boot can be found at
 * The source for U-Boot 1.1.4 is downloadable from ftp://ftp.denx.de/pub/u-boot/u-boot-1.1.4.tar.bz2
 * Here is a patch that makes it work on the DHT-Walnut: u-boot-dht-walnut-df2.patch.
 * A binary that can be copied to the DHT-Walnut flash at 0xfffc0000 is available here: u-boot-1.1.4-df2.bin

Changes since u-boot-1.1.4-df1.bin:
 * A default ethaddr is now set: de:ad:be:ef:00:00
 * The ethaddr can be changed as often as you like. Use: setenv ethaddr be:ef:be:ef:be:ef ; saveenv
 * Only the first two memory banks of a DIMM are used. This allows us to use (half of) double-sided DIMMS.

Some things to note when changing from ppcboot to U-Boot:
 * Default baudrate is 115200.
 * Occupies flash addresses 0xfffc0000-0xffffffff
 * Maintains two copies of environment data, primary copy at 0xfffb0000, backup copy at 0xfffa0000.

Installing

 * Boot the board and bring it to the ppcboot (or U-Boot) console prompt.
 * Download the new bootloader u-boot-1.1.4-df2.bin into RAM:

(1) Using Kermit (you'll need a terminal emulator that supports the kermit file transfer mode): loadb 800000 115200''
 * Switch baudrate to 115200 bps and press ENTER ...
 * Ready for binary (kermit) download ...
 * Start Addr=0x00800000
 * Switch baudrate to 9600 bps and press ESC ...

(2) Using tftpboot (requires a tftp server and setting the environment variables ethaddr, ipaddr and serverip) * TFTP from server 192.168.1.1; our IP address is 192.168.1.2 * Filename 'u-boot.bin'. * Load address: 0x800000 * Loading: done * Bytes transferred = 262144 (40000 hex)
 * tftpboot 800000 u-boot-1.1.4-df2.bin Using ppc_4xx_eth0 device
 * Verify that the download was received correctly (crc should be 0xd3cef189):
 * crc 800000 40000
 * CRC32 for 00800000 ... 0083ffff ==> d3cef189
 * Unprotect the last 4 sectors:
 * protect off fffc0000 ffffffff
 * Un-Protected 4 sectors

'''From this point on, do *not* power down the board, and type *very* carefully. This is the critical section.'''

* Erase Flash from 0xfffc0000 to 0xffffffff * Erasing sector fffc0000 * Erasing sector fffd0000 * Erasing sector fffe0000 * Erasing sector ffff0000 * done * Erased 4 sectors * Copy to Flash... done * CRC32 for fffc0000 ... ffffffff ==> d3cef189
 * Erase the last four sectors:
 * erase fffc0000 ffffffff
 * Copy the new bootloader into flash:
 * cp.b 800000 fffc0000 40000
 * Verify that the image is correct (crc of u-boot-1.1.4-df2.bin is 0xd3cef189).
 * crc fffc0000 40000

'''End of critical section. Congratulations!'''


 * Reset the board and see that the new version booted!
 * Don't forget to change your baud rate to 115200!
 * reset

You will see a message like : *** Warning - bad CRC, using default environment. That's normal. It will go away after you issue a saveenv command.

ppcboot 1.1.6
the latest ported ppcboot is 1.1.6, it need a patch and it will build for flashing at 0xfff80000 as a replacement for the pcboot-1.1.2 that comes with the board.


 * sources ftp://ftp.denx.de/pub/ppcboot/ppcboot-1.1.6.tar.bz2
 * patch [[Media:patch-ppcboot-1.1.6-km2|patch-ppcboot-1.1.6-km2]]
 * binary [[Media:ppcboot1.1.6.1.bin|ppcboot1.1.6.1.bin]] crc = 083fb0a3

Installing
Quick notes on installing ppcboot v1.1.6.1


 * Boot the board and bring it to the ppcboot console prompt.
 * Check current flash configuration:

=> flinfo

Bank # 1: AMD AM29F040 (512 Kbit, uniform sector size) Size: 512 KB in 8 Sectors Sector Start Addresses: FFF80000 RO  FFF90000  RO  FFFA0000  RO  FFFB0000      FFFC0000 FFFD0000     FFFE0000      FFFF0000

Note that the bottom three sectors, containing the existing 1.1.2 bootloader, are protected. We also want to protect the last sector, which contains the initial jump instruction, so:

=> protect on ffff0000 ffffffff

Protected 1 sectors


 * Zero out a section of ram before the download:

=> mw.b 400000 0 30000
 * Now download the new bootloader ppcboot1.1.6.1.bin into ram (you'll need a terminal emulator that supports the kermit file transfer mode):

=> loadb 400000 115200


 * 1) Switch baudrate to 115200 bps and press ENTER ...
 * 2) Ready for binary (kermit) download ...
 * 3) Start Addr      = 0x00400000
 * 4) Switch baudrate to 9600 bps and press ESC ...


 * Verify that the download was received correctly (crc should be 0x083fb0a3):

=> crc 400000 30000

CRC32 for 00400000 ... 0042ffff ==> 083fb0a3


 * Erase the three spare sectors, which we'll use to backup the 1.1.2 bootloader:

=> erase fffc0000 fffeffff

Erase Flash from 0xfffc0000 to 0xfffeffff Erasing sector fffc0000 .Erasing sector fffd0000 .Erasing sector fffe0000 . done Erased 3 sectors


 * (Optional: erase the 0xfffb0000 sector, which will be used for non-volatile environment storage.)

=> erase fffb0000 fffbffff

Erase Flash from 0xfffb0000 to 0xfffbffff Erasing sector fffb0000 . done Erased 1 sectors


 * Check that sectors 0xfffc0000 to 0xfffe0000 are erased, and sector 0xffff0000 is protected:

=> flinfo

Bank # 1: AMD AM29F040 (512 Kbit, uniform sector size) Size: 512 KB in 8 Sectors Sector Start Addresses: FFF80000 RO  FFF90000  RO  FFFA0000  RO  FFFB0000 E    FFFC0000 E    FFFD0000 E    FFFE0000 E    FFFF0000  RO


 * Now we're ready to backup the 1.1.2 bootloader. Copy three sectors from 0xfff80000 to 0xfffc0000:

=> cp.b fff80000 fffc0000 30000

Copy to Flash... done


 * Easy enough, right? Compare just to be sure it went ok:

=> cmp.b fff80000 fffc0000 30000

Total of 196608 bytes were the same


 * Now we're ready to modify the bootsectors. We'll turn off protection, erase the three bottom sectors, and copy the new 1.1.6.1 bootloader from ram.

=> protect off fff80000 fffaffff
 * Unprotect the bottom three sectors:

Un-Protected 3 sectors

'''From this point on, do *not* power down the board. This is the critical section.'''
 * Erase the bottom three sectors with the original 1.1.2 bootloader:

=> erase fff80000 fffaffff

Erase Flash from 0xfff80000 to 0xfffaffff Erasing sector fff80000 .Erasing sector fff90000 .Erasing sector fffa0000 . done Erased 3 sectors

=> cp.b 400000 fff80000 30000
 * Copy the new bootloader into flash:

Copy to Flash... done

=> cmp.b 400000 fff80000 30000
 * Verify the copy:

Total of 196608 bytes were the same

=> crc fff80000 30000
 * Verify that the image is correct (crc of ppcboot1.1.6.1.bin is 0x083fb0a3).

CRC32 for fff80000 ... fffaffff ==> 083fb0a3

'''End of critical section. Congratulations

=> protect on fff80000 fffaffff
 * We've finished modifying flash, so turn the write protection back on:

Protected 3 sectors


 * Reset the board and see that the new version booted

=> reset

PPCBoot 1.1.6 (Feb 5 2006 - 21:38:51)

CPU:  IBM PowerPC 405GP Rev. E at 266.640 MHz (PLB=66, OPB=33, EBC=33 MHz) PCI async ext clock used, internal PCI arbiter enabled 16 kB I-Cache 8 kB D-Cache

To sum up, you'll end up executing these commands:

=> protect on ffff0000 ffffffff

=> mw.b 400000 0 30000

=> loadb 400000 115200

=> crc 400000 30000

=> erase fffc0000 fffeffff

=> cp.b fff80000 fffc0000 30000

=> cmp.b fff80000 fffc0000 30000

=> protect off fff80000 fffaffff

=> erase fff80000 fffaffff

=> cp.b 400000 fff80000 30000

=> cmp.b 400000 fff80000 30000

=> crc fff80000 30000

=> protect on fff80000 fffaffff

brief about how to install on flash
=> printenv stdin=serial stdout=serial stderr=serial ...

=> setenv baudrate 9600 => setenv loads_echo 1 => ethaddr DE:AD:BE:EF:DE:AD => ethaddr serverip 192.168.1.14 => ethaddr ipaddr 192.168.1.2 => tftpboot 800000 uboot-v1.2.img TFTP from server 192.168.1.14; our IP address is 192.$ Filename 'uboot-v1.2.img'. Load address: 0x800000 Loading: *^H#########################################$ done Bytes transferred = 262144 (40000 hex)

=> crc 800000 40000 CRC32 for 00800000 ... 0083ffff ==> 3aae52fa

=> protect off fffc0000 ffffffff Un-Protected 4 sectors

=> erase fffc0000 ffffffff Erase Flash from 0xfffc0000 to 0xffffffff Erasing sector fffc0000 .Erasing sector fffd0000 .Erasing sector fffe0000 .Erasing sector ffff0000 . done Erased 4 sectors

=> cp.b 800000 fffc0000 40000 Copy to Flash... done

=> crc fffc0000 40000 CRC32 for fffc0000 ... ffffffff ==> 3aae52fa

=> protect on fffc0000 ffffffff => reset

brief about set baud and env

 * 1) setenv baudrate 9600
 * 2) Switch baudrate to 9600 bps and press ENTER ...

Saving Environment to Flash... Un-Protected 1 sectors Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... done Protected 1 sectors Protected 1 sectors
 * 1) saveenv

there are problem to upload file to this wiki, email me if you need uboot, i will send you by email

issues
this setion need to be updated

uboot-2009 (not mature, not good, under development)
it was under development, i will not released: too many issue, aborted

uboot problem with kernel >=2.6.25, ARCH=POWERPC
Based on kernel version 2.6.32. Page generated on 2009-12-11 16:23 EST.

1	The PowerPC boot wrapper 2	3	4	5	PowerPC image targets compresses and wraps the kernel image (vmlinux) with 6	a boot wrapper to make it usable by the system firmware. There is no 7	standard PowerPC firmware interface, so the boot wrapper is designed to 8	be adaptable for each kind of image that needs to be built. 9	10	The boot wrapper can be found in the arch/powerpc/boot/ directory. The 11	Makefile in that directory has targets for all the available image types. 12	The different image types are used to support all of the various firmware 13	interfaces found on PowerPC platforms. OpenFirmware is the most commonly 14	used firmware type on general purpose PowerPC systems from Apple, IBM and 15	others. U-Boot is typically found on embedded PowerPC hardware, but there 16	are a handful of other firmware implementations which are also popular. Each 17	firmware interface requires a different image format. 18	19	The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and 20	it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target 21	image. The details of the build system is discussed in the next section. 22	Currently, the following image format targets exist: 23	24	  cuImage.%:		Backwards compatible uImage for older version of 25				U-Boot (for versions that don't understand the device 26				tree). This image embeds a device tree blob inside 27				the image. The boot wrapper, kernel and device tree 28				are all embedded inside the U-Boot uImage file format 29				with boot wrapper code that extracts data from the old 30				bd_info structure and loads the data into the device 31				tree before jumping into the kernel. 32				 Because of the series of #ifdefs found in the 33				bd_info structure used in the old U-Boot interfaces, 34				cuImages are platform specific. Each specific 35				U-Boot platform has a different platform init file 36				which populates the embedded device tree with data 37				from the platform specific bd_info file. The platform 38				specific cuImage platform init code can be found in 39				arch/powerpc/boot/cuboot.*.c. Selection of the correct 40				cuImage init code for a specific board can be found in 41				the wrapper structure. 42	  dtbImage.%:		Similar to zImage, except device tree blob is embedded 43				inside the image instead of provided by firmware. The 44				output image file can be either an elf file or a flat 45				binary depending on the platform. 46				 dtbImages are used on systems which do not have an 47				interface for passing a device tree directly. 48				dtbImages are similar to simpleImages except that 49				dtbImages have platform specific code for extracting 50				data from the board firmware, but simpleImages do not 51				talk to the firmware at all. 52				 PlayStation 3 support uses dtbImage. So do Embedded 53				Planet boards using the PlanetCore firmware. Board 54				specific initialization code is typically found in a 55				file named arch/powerpc/boot/ .c; but this 56				can be overridden by the wrapper script. 57	  simpleImage.%:	Firmware independent compressed image that does not 58				depend on any particular firmware interface and embeds 59				a device tree blob. This image is a flat binary that 60				can be loaded to any location in RAM and jumped to. 61				Firmware cannot pass any configuration data to the 62				kernel with this image type and it depends entirely on 63				the embedded device tree for all information. 64				 The simpleImage is useful for booting systems with 65				an unknown firmware interface or for booting from 66				a debugger when no firmware is present (such as on 67				the Xilinx Virtex platform). The only assumption that 68				simpleImage makes is that RAM is correctly initialized 69				and that the MMU is either off or has RAM mapped to 70				base address 0. 71				 simpleImage also supports inserting special platform 72				specific initialization code to the start of the bootup 73				sequence. The virtex405 platform uses this feature to 74				ensure that the cache is invalidated before caching 75				is enabled. Platform specific initialization code is 76				added as part of the wrapper script and is keyed on 77				the image target name. For example, all 78				simpleImage.virtex405-* targets will add the 79				virtex405-head.S initialization code (This also means 80				that the dts file for virtex405 targets should be 81				named (virtex405- .dts). Search the wrapper 82				script for 'virtex405' and see the file 83				arch/powerpc/boot/virtex405-head.S for details. 84	   treeImage.%;		Image format for used with OpenBIOS firmware found 85				on some ppc4xx hardware.  This image embeds a device 86				tree blob inside the image. 87	   uImage:		Native image format used by U-Boot.  The uImage target 88				does not add any boot code.  It just wraps a compressed 89				vmlinux in the uImage data structure.  This image 90				requires a version of U-Boot that is able to pass 91				a device tree to the kernel at boot.  If using an older 92				version of U-Boot, then you need to use a cuImage 93				instead. 94	   zImage.%:		Image format which does not embed a device tree. 95				Used by OpenFirmware and other firmware interfaces 96				which are able to supply a device tree. This image 97				expects firmware to provide the device tree at boot. 98				Typically, if you have general purpose PowerPC 99				hardware then you want this image format. 100	101	Image types which embed a device tree blob (simpleImage, dtbImage, treeImage, 102	and cuImage) all generate the device tree blob from a file in the 103	arch/powerpc/boot/dts/ directory. The Makefile selects the correct device 104	tree source based on the name of the target. Therefore, if the kernel is 105	built with 'make treeImage.walnut simpleImage.virtex405-ml403', then the 106	build system will use arch/powerpc/boot/dts/walnut.dts to build 107	treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to build 108	the simpleImage.virtex405-ml403. 109	110	Two special targets called 'zImage' and 'zImage.initrd' also exist. These 111	targets build all the default images as selected by the kernel configuration. 112	Default images are selected by the boot wrapper Makefile 113	(arch/powerpc/boot/Makefile) by adding targets to the $image-y variable. Look 114	at the Makefile to see which default image targets are available. 115	116	How it is built 117	--- 118	arch/powerpc is designed to support multiplatform kernels, which means 119	that a single vmlinux image can be booted on many different target boards. 120	It also means that the boot wrapper must be able to wrap for many kinds of 121	images on a single build. The design decision was made to not use any 122	conditional compilation code (#ifdef, etc) in the boot wrapper source code. 123	All of the boot wrapper pieces are buildable at any time regardless of the 124	kernel configuration. Building all the wrapper bits on every kernel build 125	also ensures that obscure parts of the wrapper are at the very least compile 126	tested in a large variety of environments. 127	128	The wrapper is adapted for different image types at link time by linking in 129	just the wrapper bits that are appropriate for the image type. The 'wrapper 130	script' (found in arch/powerpc/boot/wrapper) is called by the Makefile and 131	is responsible for selecting the correct wrapper bits for the image type. 132	The arguments are well documented in the script's comment block, so they 133	are not repeated here. However, it is worth mentioning that the script 134	uses the -p (platform) argument as the main method of deciding which wrapper 135	bits to compile in. Look for the large 'case "$platform" in' block in the 136	middle of the script. This is also the place where platform specific fixups 137	can be selected by changing the link order. 138	139	In particular, care should be taken when working with cuImages. cuImage 140	wrapper bits are very board specific and care should be taken to make sure 141	the target you are trying to build is supported by the wrapper bits.

solution & issues
"uboot requires a version of U-Boot that is able to pass a device tree to the kernel at boot" "If using an older version of U-Boot, then you need to use a cuImage instead"

1) which uboot version is able to boot new style uImage ? 2) what about the porting of the IDE support for dht-walnut to newer uBoot ? 3) what about the tftp buffer overflow bug ?

kanojio-2n-stage-kexecboot loader has been developed for ARM, but it is also fixing the dht-walnut boot issues

uboot-kanojio
kernel>=2.6.25 requires ARCH=POWERPC, but they simply do not boot with uBoot: it seems the problem is that no "old-style" uImage is available for dht-walnut/walnut in unified powerpc source; it now requires the device tree.

From Documentation/powerpc/bootwrapper.txt:

uImage:     Native image format used by U-Boot. The uImage target does not add any boot code. It just wraps a compressed vmlinux in the uImage data structure. This image requires a version of U-Boot that is able to pass a device tree to the kernel at boot. If using an older version of U-Boot, then you need to use a cuImage instead.

There is no walnut cuImage(???), so the only choice is to use this "new-style" uImage and have uboot pass a walnut device-tree file to the kernel.

device-tree stuff is NOT supported with uboot, so ... you may use the new kanojio boot second stage loader

second stage kexec boot loader
uboot is the first stage bootloader, it's the first thing fetched by the cpu when you switch on the board.

the suggested (and hacked) uboot release is working fine, it's able to RAW read a PC partition from the hard drive putting the contents on the ram .. you could load a kernel from the HD and boot it.

it is also able to tftp a kernel from the net, but .. a bug is surviving from the 1.1.* release: this bug is limiting the amount of data you can tftp boot: 4.5Mb !

if your kernel+ramrootf is greater than 4.5Mb it will not be decompressed right cause of memory corruption (probably cause of a buffer overflow somewhere i dunno in the firmware)

so ! i developed a special second stage boot loader: it will be smaller than 4.5Mb and it will able to boot from net, pata, sata, scsi, firewire

and it should be able to read and boot all the binary format: elf, uImage, zImage, ecc

01/2010, first shot, the proof of concept
[ .k.a.n.o.j.o. ] kexec boot loader v01.2, 2010-01-28

press a key to stop the autoboot process

231 help 230 cmdlist 252 ver 232 macaddr 233 tcpscan 234 ifconfig 235 endian 236 ttftp 240 exec 241 cmdline 237 env 237 printenv 238 saveenv 239 setenv 254 255 reboot 255 exit
 * 1) cmdlist

show all the environment entries
 * 1) help printenv

env.machinename="dht-walnut" env.root="/dev/hda3,ro" env.fstype="ext3" env.console="ttyS0,9600" env.net_dev="eth0" env.net_ip="192.168.1.11" env.net_mask="255.255.255.0" env.ttftp_server_ip="192.168.1.14" env.ttftp_server_port="2001" env.rmshell_port="2002" env.timeout="5s" env.boot="net" env.bootfile="dht-walnut--kernel-2.6.22-ramrootfs.img" env.net="ttftp $ttfpt_server_ip $ttftp_server_port $bootfile autoexec"
 * 1) printenv

connect: Connection refused, no ttftp server found
 * 1) ttftp

TCP port scanning connect_port={ 22 23  80  111  443 2000}
 * 1) tcpscan $ttftp_server 1 2100


 * 1) setenv ttftp_server_port 2000

method=net downloading "dht-walnut--kernel-2.6.22-ramrootfs.img" from 192.168.1.14/2000 ... done kexec ... kernel loaded into ram ... jumping to it
 * 1) boot

i will release as soon as possible