Difference between revisions of "Flameman/dht-walnut/firmware"

From eLinux.org
Jump to: navigation, search
(kernel>=2.6.25)
(Firmware Bootloaders)
(Tag: Blanking)
 
Line 1: Line 1:
= 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
 
[http://www.denx.de/wiki/view/DULG/Manual?stickboard=walnut DENX U-Boot and Linux Guide for Walnut  ]
 
 
* Information on U-Boot can be found at [http://u-boot.sourceforge.net/]
 
* 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: [http://www.farnsworth.org/linuxppc/u-boot-dht-walnut-df2.patch u-boot-dht-walnut-df2.patch].
 
* A binary that can be copied to the DHT-Walnut flash at 0xfffc0000 is available here: [http://www.farnsworth.org/linuxppc/u-boot-1.1.4-df2.bin 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)
 
* tftpboot 800000 u-boot-1.1.4-df2.bin Using ppc_4xx_eth0 device
 
* 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)
 
* 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 the last four 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
 
* Copy the new bootloader into flash:
 
* cp.b 800000 fffc0000 40000
 
* Copy to Flash... done
 
* Verify that the image is correct (crc of u-boot-1.1.4-df2.bin is 0xd3cef189).
 
* crc fffc0000 40000
 
* CRC32 for fffc0000 ... ffffffff ==> d3cef189
 
 
'''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''
 
 
<pre>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    </pre>
 
 
 
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''
 
 
<pre>Protected 1 sectors
 
</pre>
 
 
* Zero out a section of ram before the download:
 
 
=> ''mw.b 400000 0 30000''
 
* Now download the new bootloader [http://elinux.org/wiki/DHT-Walnut?action=AttachFile&do=get&target=ppcboot1.1.6.1.bin ppcboot1.1.6.1.bin] into ram (you'll need a terminal emulator that supports the kermit file transfer mode):
 
 
=> ''loadb 400000 115200''
 
 
<pre>## Switch baudrate to 115200 bps and press ENTER ...
 
## Ready for binary (kermit) download ...
 
## Start Addr      = 0x00400000
 
## Switch baudrate to 9600 bps and press ESC ...
 
</pre>
 
 
* Verify that the download was received correctly (crc should be 0x083fb0a3):
 
 
=> ''crc 400000 30000''
 
 
<pre>CRC32 for 00400000 ... 0042ffff ==> 083fb0a3
 
</pre>
 
 
* Erase the three spare sectors, which we'll use to backup the 1.1.2 bootloader:
 
 
=> ''erase fffc0000 fffeffff''
 
 
<pre>Erase Flash from 0xfffc0000 to 0xfffeffff
 
Erasing sector fffc0000
 
.Erasing sector fffd0000
 
.Erasing sector fffe0000
 
. done
 
Erased 3 sectors</pre>
 
 
* (Optional: erase the 0xfffb0000 sector, which will be used for non-volatile environment storage.)
 
 
=> ''erase fffb0000 fffbffff''
 
 
<pre>Erase Flash from 0xfffb0000 to 0xfffbffff
 
Erasing sector fffb0000
 
. done
 
Erased 1 sectors</pre>
 
 
* Check that sectors 0xfffc0000 to 0xfffe0000 are erased, and sector 0xffff0000 is protected:
 
 
=> ''flinfo''
 
 
<pre>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 </pre>
 
 
* Now we're ready to backup the 1.1.2 bootloader.  Copy three sectors from 0xfff80000 to 0xfffc0000:
 
 
=> ''cp.b fff80000 fffc0000 30000''
 
 
<pre>Copy to Flash... done
 
</pre>
 
 
* Easy enough, right?  Compare just to be sure it went ok:
 
 
=> ''cmp.b fff80000 fffc0000 30000''
 
 
<pre>Total of 196608 bytes were the same
 
</pre>
 
 
* 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.
 
 
* Unprotect the bottom three sectors:
 
=> ''protect off fff80000 fffaffff''
 
 
<pre>Un-Protected 3 sectors
 
</pre>
 
 
'''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''
 
 
<pre>Erase Flash from 0xfff80000 to 0xfffaffff
 
Erasing sector fff80000
 
.Erasing sector fff90000
 
.Erasing sector fffa0000
 
. done
 
Erased 3 sectors</pre>
 
 
* Copy the new bootloader into flash:
 
=> ''cp.b 400000 fff80000 30000''
 
 
<pre>Copy to Flash... done
 
</pre>
 
 
* Verify the copy:
 
=> ''cmp.b 400000 fff80000 30000''
 
 
<pre>Total of 196608 bytes were the same
 
</pre>
 
 
* Verify that the image is correct (crc of ppcboot1.1.6.1.bin is 0x083fb0a3).
 
=> ''crc fff80000 30000''
 
 
<pre>CRC32 for fff80000 ... fffaffff ==> 083fb0a3
 
</pre>
 
 
'''End of critical section.  Congratulations''''
 
 
* We've finished modifying flash, so turn the write protection back on:
 
=> ''protect on fff80000 fffaffff''
 
 
<pre>Protected 3 sectors
 
</pre>
 
 
* Reset the board and see that the new version booted
 
 
=> ''reset''
 
 
<pre>
 
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
 
</pre>
 
 
 
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''
 
 
== new firmware, uboot-v1.2-hack (the most mature i suggest) ==
 
 
=== brief about how to install on flash ===
 
 
<pre>
 
 
=> 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
 
</pre>
 
 
=== brief about set baud and env ===
 
 
<pre>
 
# setenv baudrate 9600
 
## Switch baudrate to 9600 bps and press ENTER ...
 
 
# saveenv
 
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
 
</pre>
 
 
 
 
there are problem to upload file to this wiki, email me if you need uboot, i will send you by email
 
 
 
 
=== issues ===
 
 
<pre>
 
 
this setion need to be updated
 
 
</pre>
 
 
== 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 ==
 
 
<pre>
 
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/<platform>.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-<board>.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.
 
</pre>
 
 
 
=== solution? ===
 
 
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
 
 
== kernel>=2.6.25 ==
 
 
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; new kernels now require the device tree.
 
 
<pre>
 
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.
 
</pre>
 
 
There is no cuImage.walnut, so the only choice is to use
 
new uboot-2009/10/.. and force it to pass the device-tree file (walnut.dtb)
 
to the kernel.
 
 
tftp $loadaddr walnut.uImage
 
 
tftp $fdtaddr walnut.dtb
 
 
bootm $loadaddr - $fdtaddr
 
 
The primary difference here is that it'd needed to load two images. The larger image is the kernel image. The smaller image (16KB) is the flat device tree.
 

Latest revision as of 11:49, 23 September 2019