Skip to contentSkip to conversation

powerpc: Add support for OpenBlockS 600

PATCH In review Benjamin Herrenschmidt 3 participants 4 messages Dec 2, 2011

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 powerpc: Add support for OpenBlockS 600

So I've had one of these for a while and it looks like the vendor never bothered submitting the support upstream.

This adds it using ppc40x_simple and provides a device-tree.

There are some changes to the boot wrapper because the way u-boot works on this thing, it seems to expect a multipart image with the kernel, initrd and dtb in it.

The USB support is missing as it needs the yet unmerged driver for the DWC OTG part and the GPIOs may need further definition in the dts.

---
 arch/powerpc/Makefile                      |    2 +-
 arch/powerpc/boot/Makefile                 |    7 +
 arch/powerpc/boot/dts/obs600.dts           |  314 ++++++++++++++++++++++++++++
 arch/powerpc/boot/wrapper                  |   22 ++-
 arch/powerpc/configs/40x/obs600_defconfig  |   83 ++++++++
 arch/powerpc/platforms/40x/Kconfig         |   10 +
 arch/powerpc/platforms/40x/ppc40x_simple.c |    3 +-
 7 files changed, 438 insertions(+), 3 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/obs600.dts
 create mode 100644 arch/powerpc/configs/40x/obs600_defconfig
arch/powerpc/Makefile +1 -1
index 59f462b..ffe4d88 100644
@@ -165,7 +165,7 @@ all: zImage
 
 # With make 3.82 we cannot mix normal and wildcard targets
 BOOT_TARGETS1 := zImage zImage.initrd uImage
-BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
+BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.% uImage.%
 
 PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
 
arch/powerpc/boot/Makefile +7 -0
index 72ee8c1..80c133c 100644
@@ -199,6 +199,7 @@ image-$(CONFIG_EP405)			+= dtbImage.ep405
 image-$(CONFIG_HOTFOOT)			+= cuImage.hotfoot
 image-$(CONFIG_WALNUT)			+= treeImage.walnut
 image-$(CONFIG_ACADIA)			+= cuImage.acadia
+image-$(CONFIG_OBS600)			+= uImage.obs600
 
 # Board ports in arch/powerpc/platform/44x/Kconfig
 image-$(CONFIG_EBONY)			+= treeImage.ebony cuImage.ebony
@@ -316,6 +317,12 @@ $(obj)/zImage.iseries: vmlinux
 $(obj)/uImage: vmlinux $(wrapperbits)
 	$(call if_changed,wrap,uboot)
 
+$(obj)/uImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
+	$(call if_changed,wrap,uboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
+
+$(obj)/uImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
+	$(call if_changed,wrap,uboot-$*,,$(obj)/$*.dtb)
+
 $(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
 	$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
 
arch/powerpc/boot/dts/obs600.dts new file +314 -0

314 lines not on this page · raw message

arch/powerpc/boot/wrapper +21 -1
index c74531a..14cd4bc 100755
@@ -163,7 +163,7 @@ coff)
     link_address='0x500000'
     pie=
     ;;
-miboot|uboot)
+miboot|uboot*)
     # miboot and U-boot want just the bare bits, not an ELF binary
     ext=bin
     objflags="-O binary"
@@ -291,6 +291,26 @@ uboot)
     fi
     exit 0
     ;;
+uboot-obs600)
+    rm -f "$ofile"
+    # obs600 wants a multi image with an initrd, so we need to put a fake
+    # one in even when building a "normal" image.
+    if [ -n "$initrd" ]; then
+	real_rd="$initrd"
+    else
+	real_rd=`mktemp`
+	echo "\0" >>"$real_rd"
+    fi
+    ${MKIMAGE} -A ppc -O linux -T multi -C gzip -a $membase -e $membase \
+	$uboot_version -d "$vmz":"$real_rd":"$dtb" "$ofile"
+    if [ -z "$initrd" ]; then
+	rm -f "$real_rd"
+    fi
+    if [ -z "$cacheit" ]; then
+	rm -f "$vmz"
+    fi
+    exit 0
+    ;;
 esac
 
 addsec() {
arch/powerpc/configs/40x/obs600_defconfig new file +83 -0

83 lines not on this page · raw message

arch/powerpc/platforms/40x/Kconfig +10 -0
index 1530229..bac24a0 100644
@@ -100,6 +100,16 @@ config XILINX_VIRTEX_GENERIC_BOARD
 	  Most Virtex designs should use this unless it needs to do some
 	  special configuration at board probe time.
 
+config OBS600
+	bool "OpenBlockS 600"
+	depends on 40x
+	default n
+	select 405EX
+	select PPC40x_SIMPLE
+	help
+	  This option enables support for PlatHome OpenBlockS 600 server
+
+
 config PPC40x_SIMPLE
 	bool "Simple PowerPC 40x board support"
 	depends on 40x
arch/powerpc/platforms/40x/ppc40x_simple.c +2 -1
index e8dd5c5..ecac237 100644
@@ -55,7 +55,8 @@ static const char *board[] __initdata = {
 	"amcc,haleakala",
 	"amcc,kilauea",
 	"amcc,makalu",
-	"est,hotfoot"
+	"est,hotfoot",
+	"plathome,obs600"
 };
 
 static int __init ppc40x_probe(void)
#1 lore raw

Hi,

Quoted 1 line · Benjamin Herrenschmidt

=A0arch/powerpc/boot/dts/obs600.dts =A0 =A0 =A0 =A0 =A0 | =A0314 ++++++++=

++++++++++++++++++++

It'd be nice to have dtsi files for the SoCs, there's a lot of boiler plate in there. That shouldn't hold up this specific patch though.

Quoted 1 line

=A0arch/powerpc/boot/wrapper =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 22 =

++-

Quoted 1 line

=A0arch/powerpc/configs/40x/obs600_defconfig =A0| =A0 83 ++++++++

A new single-board defconfig? On arm that is a strong NACK, I'd say it's a bad idea on powerpc as well.

-Olof

#2 lore raw
Quoted 9 lines · Olof Johansson

Hi,

Quoted 1 line · Benjamin Herrenschmidt
 arch/powerpc/boot/dts/obs600.dts           |  314 ++++++++++++++++++++++++++++

It'd be nice to have dtsi files for the SoCs, there's a lot of boiler plate in there. That shouldn't hold up this specific patch though.

Right definitely. One thing that I wonder tho (I haven't looked at the dtsi stuff specifically), can it "remove" a node ?

Ie. The 405EX dtsi will probably expose the PCIe bridges in that specific case, but I want them out as they aren't wired and trying to use them causes a hang on this board.

Another approach is to stick in a disabled property and make sure the ppc4xx_pci code checks it.

Quoted 5 lines
Quoted 2 lines
 arch/powerpc/boot/wrapper                  |   22 ++-
 arch/powerpc/configs/40x/obs600_defconfig  |   83 ++++++++

A new single-board defconfig? On arm that is a strong NACK, I'd say it's a bad idea on powerpc as well.

The defconfigs are just there for the user sake, I find them handy myself. I have no objection (as maintainer) to having them since nowadays they are really small and can be handy for embedded systems (ie, on a tiny 405 based machine you really want to cut out the bloat you don't need).

As long as the board -can- be built as part of a combo that is.

So as maintainer, I think I'll keep applying a different policy than ARM in that area ;-)

Cheers,
Ben.

#3 lore raw
In reply to Olof Johansson
Quoted 6 lines · Olof Johansson

Hi,

Quoted 1 line · Benjamin Herrenschmidt

=A0arch/powerpc/boot/dts/obs600.dts =A0 =A0 =A0 =A0 =A0 | =A0314 +++++++=

+++++++++++++++++++++

Quoted 3 lines

It'd be nice to have dtsi files for the SoCs, there's a lot of boiler plate in there. That shouldn't hold up this specific patch though.

That sounds like a cleanup project for me. I just need to figure out how they work and find time.

Quoted 1 line
Quoted 1 line

=A0arch/powerpc/boot/wrapper =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 22=

++-

Quoted 4 lines
Quoted 1 line

=A0arch/powerpc/configs/40x/obs600_defconfig =A0| =A0 83 ++++++++

A new single-board defconfig? On arm that is a strong NACK, I'd say it's a bad idea on powerpc as well.

I like them. Particularly when they're the output of savedefconfig.

josh