8xx: Analogue & Micro Adder875 board support.

---
Please pull for 2.6.25.

 arch/powerpc/Kconfig                            |    3 +
 arch/powerpc/boot/.gitignore                    |    1 +
 arch/powerpc/boot/Makefile                      |    6 +-
 arch/powerpc/boot/dts/adder875-redboot.dts      |  182 +++++
 arch/powerpc/boot/dts/adder875-uboot.dts        |  181 +++++
 arch/powerpc/boot/redboot-8xx.c                 |   58 ++
 arch/powerpc/boot/redboot.h                     |   56 ++
 arch/powerpc/boot/wrapper                       |    2 +-
 arch/powerpc/configs/adder875-redboot_defconfig |  798 +++++++++++++++++++++++
 arch/powerpc/configs/adder875-uboot_defconfig   |  798 +++++++++++++++++++++++
 arch/powerpc/platforms/8xx/Kconfig              |    9 +
 arch/powerpc/platforms/8xx/Makefile             |    1 +
 arch/powerpc/platforms/8xx/adder875.c           |  123 ++++
 13 files changed, 2216 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/adder875-redboot.dts
 create mode 100644 arch/powerpc/boot/dts/adder875-uboot.dts
 create mode 100644 arch/powerpc/boot/redboot-8xx.c
 create mode 100644 arch/powerpc/boot/redboot.h
 create mode 100644 arch/powerpc/configs/adder875-redboot_defconfig
 create mode 100644 arch/powerpc/configs/adder875-uboot_defconfig
 create mode 100644 arch/powerpc/platforms/8xx/adder875.c

index 66a3d8c..47fe256 100644
@@ -140,6 +140,9 @@ config DEFAULT_UIMAGE
 	  Used to allow a board to specify it wants a uImage built by default
 	default n
 
+config REDBOOT
+	bool
+
 config PPC64_SWSUSP
 	bool
 	depends on PPC64 && (BROKEN || (PPC_PMAC64 && EXPERIMENTAL))

index 65f4118..a424be6 100644
@@ -30,6 +30,7 @@ zImage.*lds
 zImage.miboot
 zImage.pmac
 zImage.pseries
+zImage.redboot*
 zImage.sandpoint
 zImage.vmode
 zconf.h

index d1e625c..08bf7aa 100644
@@ -62,7 +62,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
 		ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
 		cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c \
 		fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
-		cuboot-katmai.c cuboot-rainier.c
+		cuboot-katmai.c cuboot-rainier.c redboot-8xx.c
 src-boot := $(src-wlib) $(src-plat) empty.c
 
 src-boot := $(addprefix $(obj)/, $(src-boot))

@@ -208,6 +208,10 @@ image-$(CONFIG_TAISHAN)			+= cuImage.taishan
 image-$(CONFIG_KATMAI)			+= cuImage.katmai
 endif
 
+ifneq ($(CONFIG_REDBOOT),"")
+image-$(CONFIG_PPC_8xx)			+= zImage.redboot-8xx
+endif
+
 # For 32-bit powermacs, build the COFF and miboot images
 # as well as the ELF images.
 ifeq ($(CONFIG_PPC32),y)

index 154df05..a7c4671 100755
@@ -168,7 +168,7 @@ ps3)
     ksection=.kernel:vmlinux.bin
     isection=.kernel:initrd
     ;;
-ep88xc|ep405)
+ep88xc|ep405|redboot*)
     platformo="$object/fixed-head.o $object/$platform.o"
     binary=y
     ;;

index 91fbe42..7fd224c 100644
@@ -44,6 +44,15 @@ config PPC_EP88XC
 	  This board is also resold by Freescale as the QUICCStart
 	  MPC885 Evaluation System and/or the CWH-PPC-885XN-VE.
 
+config PPC_ADDER875
+	bool "Analogue & Micro Adder 875"
+	select CPM1
+	select PPC_CPM_NEW_BINDING
+	select REDBOOT
+	help
+	  This enables support for the Analogue & Micro Adder 875
+	  board.
+
 endchoice
 
 menu "Freescale Ethernet driver platform-specific options"

index 8b70980..7b71d9c 100644
@@ -5,3 +5,4 @@ obj-$(CONFIG_PPC_8xx)	  += m8xx_setup.o
 obj-$(CONFIG_MPC885ADS)   += mpc885ads_setup.o
 obj-$(CONFIG_MPC86XADS)   += mpc86xads_setup.o
 obj-$(CONFIG_PPC_EP88XC)  += ep88xc.o
+obj-$(CONFIG_PPC_ADDER875) += adder875.o

1.5.3.8

Greetings Scott.

Using u-boot Adder_config

U-Boot 1.3.1-g5c740711-dirty (Jan 13 2008 - 13:43:30) - using an ELDK 4.1 uclibc toolchain

I can't boot your board - port.

I've applied your code against Linus' git v2.6.26-rc7 as at today. I have to apply

index 31147a0..8c060ca 100755
@@ -163,7 +163,7 @@ ps3)
     ksection=.kernel:vmlinux.bin
     isection=.kernel:initrd
     ;;
-ep88xc)
+ep88xc|ep405|redboot*)
     platformo="$object/fixed-head.o $object/$platform.o"
     binary=y
     ;;

and

index 18e3271..e426052 100644
@@ -56,7 +56,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83xx.c

cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c
cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
cuboot-bamboo.c \
- fixed-head.S ep88xc.c cuboot-hpc2.c
+ fixed-head.S ep88xc.c cuboot-hpc2.c redboot-8xx.c
src-boot := $(src-wlib) $(src-plat) empty.c

manually since those two fail to apply to Linus' tree - presumably because they depend on other patches - should I be using -mm or some other tree here instead ?

I then run

source /opt/eldk/eldk_init ppc_8xx

export ARCH=powerpc

make adder87x-uboot_defconfig

make uImage

cp arch/powerpc/boot/uImage /tftpboot - which is my tftpd root directory.

In U-Boot then.

=> tftpboot 0x400000 uImage
=> bootm 0x400000

Which doesn't boot.

Attaching a BDI2000 to the target board I see that the kernel is panicing somewhere around line 104 of arch/powerpc/kernel/prom.c in of_scan_flat_dt - presumably because the kernel cannot find an OpenFirmware tree..

I admit not understanding everything I should about where the output of .dts & dtc "go" with respect to booting Linux.... but, didn't want to ask on the list - lest I display a "lack of knowledge" ...

Seriously though, could you offer a pointer as to how I run this code on the Adder875 here ?

My kernel command line is

root=/dev/nfs nfsroot=192.168.1.101:/tftpboot/root_fs rw ip=192.168.1.202:::::eth0:off console=ttyCPM,115200

I've also tried - in ignorance of how OF works I admit to add the following options to u-boot to no avail.

/* pass open firmware flat tree */
#define CONFIG_OF_LIBFDT 1
#undef CONFIG_OF_FLAT_TREE
#define CONFIG_OF_BOARD_SETUP 1
#define CONFIG_OF_HAS_BD_T 1
#define CONFIG_OF_HAS_UBOOT_ENV 1

#define OF_CPU "PowerPC,875@0"
#define OF_SOC "soc875@ff000000"
#define OF_TBCLK (bd->bi_busfreq / 4)

Have I missed a step with the .dts & dtc - and is this why of_scan_flat_dt is failing - or - should the board port simply "just work" with a

make dder87x-uboot_defconfig && make uImage ?

I'm sure I've done something obscenely obvious with respect to not getting the whole OF thing right.... but if you could point to what that is... I'd be highly appreciative.

Regards,
Bryan

[snip]

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

It should apply against paulus's tree.

make zImage, not uImage.

Use cuImage.8xx, not uImage.

0x400000 is where u-boot is going to want to relocate the image to, so loading the uImage there may not work.

Yes, a uImage target will be expecting to be handed a device tree. The cuImage target has a device tree embedded and accepts the old-style bd_t.

Nothing wrong with asking... doing so on the list just means a larger pool of people to respond, and that others with the same question can see the answer.

You'll probably need some 8xx-specific code if you want to go this route. You'd also need to change the bootm command line to the three-argument version, with the third argument being the address of the device tree blob (the second argument can be - if there's no initrd).

If you're not comfortable with the device tree stuff, I recommend just using cuImage for now.

-Scott

Will try.

Hmm, some old code I did to make Linux boot from the former ppc stuff works fine to the loading and booting @ 0x4000000 - this step is pretty much fine, I think.

Ah.

This explains eveything then.. there _is_ a magic image and I haven't been booting it !

Typical.

I'll give the 8xx-centric ucImage a go.

Ah OK, I see so the procedure would be to dtc a dts representing the Adder.

Download both this and a uImage ... and then as you say pass the address of the blob to Linux via U-Boot.

It occurs to me that this type of procedure should really be added to the Documentation...

There's no mention of it in the Linux documentation, nor in the u-boot documentation and uncle Google was not informative for the types of searches I was doing....

Somebody - possibly even me, since I'm mentioning it - should write a copule of paragraphs on booting a ucImage with a of-blob and add it to both U-Boot and Linux..

Indeed.

Thanks for the response Scott. I'll try out the ucImage and all going well with that will try the three parameter Linux + blob based on the .dts, hopefully over the next three or four days....

If I'm unlucky I might bug you again... and if I have more luck, I'll do a follow up on the list.

Happy Monday !

Regards,
Bryan

It is not 8xx centric; it is a compatibility layer for old, non-device-tree aware u-boots (regardless of what chip you're using).

Search for "device tree" in u-boot's README.

-Scott

We should use ethernet0 since its based on the standard naming convention.

- k

Greetings Scott.

I've tried both of the procedures you've outlined on the Adder875 with the patches supplied against the paulus git tree to no avail.

Pass #1 :

Doing it safe with cuImage.8xx

Build system : Debian lenny, ELDK 4.1 uClibc
Kernel : Linux-2.6.24-rc6-g4f43143f-dirty - about two days old Bootloader : U-Boot 1.3.1-g5c740711-dirty (Jan 15 2008 - 21:50)

	#define CONFIG_OF_LIBFDT 1
	#undef CONFIG_OF_FLAT_TREE
	- So that U-Boot will understand the three parameter bootm.

dtc : DTC 1.1.0-rc1

I do

1. source /opt/eldk/eldk_init ppc_8xx
2. export ARCH=powerpc

3. cd linux-2.6-paulus
4. git branch adder875-patchset master
5. git checkout adder875-patchset
6. cat ../adder875_patches/adder875.patch | patch -p1

The patch applies almost perfectly - except for a minor conflict in arch/powerpc/boot/Makefile - where I add redboot-8xx.c right after cuboot-rainer.c manually.

7. make distclean && mrproper && clean
8. make adder875-uboot_defconfig
9. make zImage

That runs just fine - and just to prove to you I haven't done anything funny here the last few lines of output are

HOSTLD arch/powerpc/boot/dtc
WRAP arch/powerpc/boot/cuImage.8xx
DTC: dts->dtb on file "/home/deckard/Development/linux/linux-2.6-paulus/arch/powerpc/boot/dts/adder875-uboot.dts"

Image Name:   Linux-2.6.24-rc6-g4f43143f-dirty
Created:      Tue Jan 15 23:02:52 2008
Image Type:   PowerPC Linux Kernel Image (gzip compressed)
Data Size:    1032266 Bytes = 1008.07 kB = 0.98 MB
Load Address: 0x00400000
Entry Point:  0x00400554

WRAP arch/powerpc/boot/zImage.redboot-8xx
DTC: dts->dtb on file "/home/deckard/Development/linux/linux-2.6-paulus/arch/powerpc/boot/dts/adder875-uboot.dts"

cp arch/powerpc/boot/ucImage.8xx /tftpboot

The U-Boot output is :
=> tftpboot 0x400000 cuImage.8xx
Using FEC ETHERNET device
TFTP from server 192.168.0.101; our IP address is 192.168.0.202 Filename 'cuImage.8xx'.
Load address: 0x400000
Loading:
#################################################################

#################################################################

#################################################################

         #######

done
Bytes transferred = 1032330 (fc08a hex)
=> bootm 0x400000
## Booting image at 00400000 ...

   Image Name:   Linux-2.6.24-rc6-g4f43143f-dirty
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1032266 Bytes = 1008.1 kB

Load Address: 00400000
Entry Point: 00400554
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

I haven't as yet tried to single step through the bootup process - but, just to say that assuming the above procedure isn't _too_ far wrong - the stuff posted to the list agains the tree you've recommended doesn't seem to work..

If you can point out a flaw in my usage of it - that'd help alot. I have some code I'd love to be able to use with the Adder875+powerpc layer - which is why I'm interested in this patchset...

Pass #2 :

Replace step 9 with.

9. make uImage
10 dtc -o ../adder875-uboot.dtb -O dtb
arch/powerpc/boot/dts/adder875-uboot.dts

cp arch/powerpc/boot/uImage /tftpboot
cp ../adder875-uboot.dtb /tftpboot

Finally in u-boot
=> tftpboot 0x400000 uImage
Using FEC ETHERNET device
TFTP from server 192.168.0.101; our IP address is 192.168.0.202 Filename 'uImage'.
Load address: 0x400000
Loading:
#################################################################

#################################################################

#################################################################

         ###

done
Bytes transferred = 1009496 (f6758 hex)
=> tftpboot 0x500000 adder875-uboot.dtb
Using FEC ETHERNET device
TFTP from server 192.168.0.101; our IP address is 192.168.0.202 Filename 'adder875-uboot.dtb'.
Load address: 0x500000
Loading: #
done
Bytes transferred = 3147 (c4b hex)
=> bootm 0x400000 - 0x500000
## Booting image at 00400000 ...

   Image Name:   Linux-2.6.24-rc6-g4f43143f-dirty
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1009432 Bytes = 985.8 kB

Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x500000

Aside from the u-boot modification of including

#define CONFIG_OF_LIBFDT 1

The rest is a pristine version of Yuli Barchoen's original U-Boot Adder stuff.

The uImage + dtb seems to get a good bit further in that it seems to get stuck somewhere inside of some trampoline code in time.c

(gdb) bt
#0 0xc000ee30 in __div64_32 ()
#1 0xc01d71f4 in time_init () at arch/powerpc/kernel/time.c:940

I might have a go at some proper debugging tomorrow after work.

If you have any suggestions as to what's going wrong or what I've not done right I'd appreciate the help.

Best Regards,
BOD

[...]

yes the sequence seems correct, so I'd check cmdline params, contents of chosen node in dts, etc to make sure stuff is being written to the proper UART with proper settings.

following the u-boot way (which is more correct imo) you'll need to add some code that fixes up frequencies and stuff inside dtb, or you may try to hardcode those values inside dts(if you know exactly what should be there). Just adding CONFIG_*LIBFDT is not going to work.

Sincerely, Vitaly

On Wed, 2008-01-16 at 09:16 +0300, Vitaly Bordug wrote:

Greetings Vitaly !

Indeed - thing is for the cuImage.8xx it's definitely _not_ something simple like a UART not set at the expected baud rate.

Using an Adder875 booted from U-Boot and cuImage.8xx with a a bdi2000 as a debugger - after the jump to kernel startup we don't even hit start_kernel ! There's no question about it - for whatever reason the cuImage.8xx for this board is definitely broken.

I've been doing some experiments in the last hour or so mapping vmlinux to 0x400554 in gdb - since that's the entry point above - and setting an instruction breakpoint to do some instruction stepping.

When I do that with cuImage.8xx I find that in kernel/head_8xx.S the code dies before going into virtual memory mode - haven't nailed down exactly where yet.

Point being if I boot a uImage + dtb

bootm 0x400000 - 0x500000 with a breakpoint set at start_kernel - then the uImage + dtb version _will_ hit start_kernel - where we are in virtual mode...

_something_ wierd is for sure wrong with the cuImage.8xx and unfortunately it's not a simple as a silly baud rate.

I agree, makes sense to go with the flow of things tbh.

It still leaves as unanswered why exactly the ucImage.8xx kernel dies suddenly before hitting start_kernel - whereas the uImage + dtb boy is getting much further along in the boot.

I suppose I'll do some debug with the uImage - and try to see what else it wants to complete the boot though, it'd be nice if the cuImage worked so there'd be a safety net to use as a comparison to get the uImage + dtb running properly.