PPC405GP DHT-Walnut support

hi, guys
I am the team leader of a small forum [1] dedicated to hobbyistic projects made for fun; we have recently incurred into a weird problem with the Promise chip mounted on the dht-walnut board.

Googling I see there was support from OpenWRT, but it's clear "how" OpenWrt compiles the kernel, and if it adds more specific support to arch/powerpc/boot.

does, for any chance, anyone happens to remember how was the dth-walnut handled regarding the boot wrapper? The documentation reports the possibilities below listed, but there is something wrong

I mean a dude yesterday told me there is an OpenWRT trunk with the DHT-Walnut able to use the Promise chip in Native mode, and this is the only patch I find in their repository, but it doesn't look sufficient, and in fact, our kernels crash when the chip is in "PCI native mode".

..
pATA_PROMISE_PDC20265 0008:00:04.0: enabling device (0005 -> 0007)
pci: drivers/ata/libata-sf.addr=4160
Data
machine check in kernel mode.
Oops: Machine check, sig: 7 [#1]
Walnut
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.11.0-walnut #144
task: c2820000 task.stack: c281e000
NIP: c0012538 LR: c03ac9f8 CTR: 00000000
REGS: c2ff7f50 TRAP: 0202 Not tainted (4.11.0-walnut)
MSR: 00029030 <EE,ME,IR,DR>
CR: 24018444 XER: 00000000
DEAR: c4011002 ESR: 00000000
GPR00: c03ac8cc c281fd30 c2820000 00000000 c20f5310 00000000 00000000 0000103f
GPR08: 00000000 00000000 00040101 0000003f 24018442 00000000 c00028d0 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c0760000 c07072c0
GPR24: c06ac4c8 c074de2c c20cd880 00000000 c20cd850 c212c000 c2856c68 00000000
NIP [c0012538] ioread8+0x8/0x20
LR [c03ac9f8] ata_pci_bmdma_init+0x1c8/0x200
Call Trace:
[c281fd30] [c03ac8cc] ata_pci_bmdma_init+0x9c/0x200 (unreliable)
[c281fd60] [c03aca5c] ata_pci_bmdma_prepare_host+0x2c/0x50
[c281fd70] [c03acbd8] ata_pci_init_one+0x158/0x210
[c281fdb0] [c03b4ec8] pdc202xx_init_one+0x78/0xb0
[c281fdd0] [c02cdb18] pci_device_probe+0xd8/0x160
[c281fdf0] [c034f2a4] really_probe+0xe4/0x2e0
[c281fe20] [c034f5a8] __driver_attach+0x108/0x110
[c281fe40] [c034cea8] bus_for_each_dev+0x78/0xd0
[c281fe70] [c034e768] bus_add_driver+0x148/0x2a0
[c281fe90] [c034ffac] driver_register+0x8c/0x150
[c281fea0] [c00026e8] do_one_initcall+0x48/0x1b0
[c281ff00] [c0707adc] kernel_init_freeable+0x130/0x1f0
[c281ff30] [c00028e8] kernel_init+0x18/0x120
[c281ff40] [c000e134] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
60000000 60000000 81230008 81290068 81290080 7d2903a6 4e800420 00000000
00000000 00000000 7c0004ac 88630000 <0c030000> 4c00012c 5463063e 4e800020
---[ end trace 45c91fb6448bc0eb ]---
..

I am not able to understand OpenWRT; how does it compile the kernel? does it invoke make cuboot-walnut? make uImage? make simpletree-walnut? or what else? and is there a new DeviceTree Blob?

we are with u-boot-2017.05

if someone has the time to give an eye into this, it's more than appreciated =)

thanks
ivelegacy &DTB

[1] http://www.downthebunker.com/reloaded/space/viewtopic.php?f=78&p=2882

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.

Have you already tried

git clone https://git.openwrt.org/openwrt/openwrt.git

and looked at the code?

That includes the build system as well as the OpenWrt-specific source code and patches.

Already tried and it's not clear what OpenWRT specifically does.
Can anyone look at this, please?

Besides, what is the current status of support for the walnut and dht-walnut boards?

The OpenWrt build system basically:

  • Builds the cross-compile toolchains and utilities
  • Downloads the required source, including; Linux kernel, third-party applications, and selected packages
  • Applies patches
  • Builds the components
  • Packages the packages ("add-on" software and kernel modules) into opkg-compatible files
  • Assembles the components into images
  • Indexes the packages

As for the "walnut" -- nothing seen

jeff@deb-devel:~/devel/openwrt$ git pull
Already up to date.
jeff@deb-devel:~/devel/openwrt$ fgrep -ri walnut target/linux/
jeff@deb-devel:~/devel/openwrt$ 
1 Like

The dht-Walnut and the walnut boards are PPC40x platforms, and they seem removed from current trunks; what I am asking is which kind of boot wrapper is OpenWrt using to compile the kernel; specifically, when you compile a kernel, inside the kernel folder, you have to issue one of these

  • make cuboot-walnut
  • make treeboot-walnut
  • make uImage
  • make somethingspecial

but it's not clear which one OpenWrt invokes during the process. Where is it defined? In which script? I am a bit confused, as well as I don't understand if there was a special bootstrapper in arch/powerpc/boot/xxxx, or a modified DTS ... I cannot find in the new trunks, but I see there was an OpenWRT trunk made in 2015, with this patch

target/linux/ppc40x/patches-3.18/001-walnut-ide-fixup.patch

I have a substantially a few working kernels, from 2.6.26 to 4.11, except that in none of them the Promise pATA chip seems working, and when I apply that patch to a, for example, kernel 3.10, or 3.18, this is what happens

..
Call Trace:
[c281fd30] [c03ac8cc] ata_pci_bmdma_init+0x9c/0x200 (unreliable)
[c281fd60] [c03aca5c] ata_pci_bmdma_prepare_host+0x2c/0x50
[c281fd70] [c03acbd8] ata_pci_init_one+0x158/0x210
[c281fdb0] [c03b4ec8] pdc202xx_init_one+0x78/0xb0
[c281fdd0] [c02cdb18] pci_device_probe+0xd8/0x160
[c281fdf0] [c034f2a4] really_probe+0xe4/0x2e0
[c281fe20] [c034f5a8] __driver_attach+0x108/0x110
[c281fe40] [c034cea8] bus_for_each_dev+0x78/0xd0
[c281fe70] [c034e768] bus_add_driver+0x148/0x2a0
[c281fe90] [c034ffac] driver_register+0x8c/0x150
[c281fea0] [c00026e8] do_one_initcall+0x48/0x1b0
[c281ff00] [c0707adc] kernel_init_freeable+0x130/0x1f0
[c281ff30] [c00028e8] kernel_init+0x18/0x120
[c281ff40] [c000e134] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
60000000 60000000 81230008 81290068 81290080 7d2903a6 4e800420 00000000
00000000 00000000 7c0004ac 88630000 <0c030000> 4c00012c 5463063e 4e800020
---[ end trace 45c91fb6448bc0eb ]---
..

Lookds like the DMA has some issues, but it also might be a different problem, like a bad support in the bootwrapper part, or something else.

I wonder, did it work in 2015? Has it ever worked after kernel 2.6.26?

By googling, I only find these patches, https://github.com/openwrt/archive/tree/master/target/linux/ppc40x
but they don't help to solve the problem reported in my topic [1]

[1] http://www.downthebunker.com/reloaded/space/viewtopic.php?f=78&t=512&p=2887

From https://openwrt.org/docs/techref/targets/ppc40x

  • Support for this target has been dropped with commit fa0275b
  • ppc40x target has been removed with commit 406a382
1 Like

ARCH:=powerpc
BOARD:=ppc40x
BOARDNAME:=AMCC/IBM PPC40x
FEATURES:=
CPU_TYPE:=405
MAINTAINER:=Imre Kaloz kaloz@openwrt.org

I wrote him an email, hope he will find time to answer.

If you really need these, you could try poking around the historical code to find what you’re looking for.

~/devel/openwrt$ git pull

~/devel/openwrt$ git checkout -b old-state 76ba98d

Based on @tmomas comment, this is 1 commit prior to the build target being dropped. From here you can grep around and look there. Good luck.

1 Like

we have two projects on this board.

PCI: 0008:00:04.0 Forcing PCI IDE into native mode
    drivers/of/of_pci_irq.of_irq_parse_pci
    {
        ( warns ) error3 of_irq_parse_raw
pci 0008:00:00.0: of_irq_parse_pci: failed with rc=-22
        ( warn ) exit with error message
    }
    drivers/of/of_pci_irq.of_irq_parse_pci
    {
    }

my squad needs to understand why this fails. I am not sure OpenWrt really fixed this bug, I have never seen in person a working board, and it seems nobody can confirm ...

anyway, thanks

$ git log -1 406a382

commit 406a3826dc
Author: Hauke Mehrtens <redacted>
Date:   Mon Mar 25 15:16:59 2019 +0100

    ppc40x: Remove unmaintained target
    
    This target only supports kernel 3.18, which is not supported in OpenWrt
    any more for multiple releases. It also looks like there is no active
    maintainer for this target.
    Remove the code and all the packages which are only used by this target.
    
    To add this target to OpenWrt again port it to a recent and supported
    kernel version.

Looks pretty much untouched for six years now

$ git log --pretty='%h %>>(35)%ad     %s' --follow -- target/linux/ppc40x | head -n 40

406a3826dc      Mon Mar 25 15:16:59 2019 +0100     ppc40x: Remove unmaintained target
cf7154db07       Mon Jul 9 20:48:56 2018 +0200     kernel: only optimized for size if small_flash
e0b9ec8e96       Sun Jul 9 12:25:04 2017 +0200     treewide: drop target board_name functions
f12a32630f      Fri May 12 22:36:07 2017 +0200     treewide: use the generic board_name function
78cf5eed6e       Fri Apr 7 18:01:17 2017 +0200     treewide: do board detection during preinit
aa53f78038       Sun Sep 4 13:34:18 2016 +0200     build: fix subtarget descriptions
39f3408732      Wed Jul 20 15:44:49 2016 +0200     ppc4xx: remove booke-wdt watchdog package
09722d0bdc      Sun Apr 12 20:48:13 2015 +0000     ppc40x: upgrade to 3.18
a4d7571367      Tue Mar 24 10:38:50 2015 +0000     mark 3.10 targets as broken
f04a268a04       Fri Mar 6 07:56:34 2015 +0000     kernel: disable ARCH_NEEDS_CPU_IDLE_COUPLED
7cc5b6f9e9       Mon Jan 5 13:02:44 2015 +0000     all targets: remove all =m kernel config symbols
c288d2d6d9      Fri Oct 24 19:34:02 2014 +0000     kernel: makefiles: make use of new var KERNEL_PATCHVER
f35da063bc       Sun Oct 5 20:17:19 2014 +0000     targets: remove useless quotes around KERNELNAME
7d8f187201      Mon Jul 21 18:42:06 2014 +0000     target/linux/*/image/Makefile: use new dts path variable
ba63338d3f      Sun Jul 20 17:31:11 2014 +0000     kernel: update to 3.10.49 Signed-off-by: John Crispin <blogic@openwrt.org>
994e5ce2f9      Thu Jun 26 13:47:42 2014 +0000     kernel: update 3.10.36->3.10.44
f933a741a9       Mon Jun 2 12:43:22 2014 +0000     target/linux/*/base-files/lib/upgrade/platform.sh - wrong check for ARGC
d2812cb036      Sat Apr 12 11:59:07 2014 +0000     kernel: update 3.10 to 3.10.36
627baa28d3      Thu Mar 27 09:28:33 2014 +0000     kernel: update 3.10 to 3.10.34
f677b1bc7e      Sun Feb 23 10:59:40 2014 +0000     kernel: update 3.10 to 3.10.32
a2543d72d8      Sun Jan 26 11:30:34 2014 +0000     kernel: update 3.10 to 3.10.28
0e2586a774      Sat Jan 11 16:06:37 2014 +0000     kernel: update 3.10 to 3.10.26
952db22551      Sun Dec 15 19:16:30 2013 +0000     kernel: update kernel 3.10 to 3.10.24
f1ef0b92be       Sun Dec 1 09:59:53 2013 +0000     kernel: update 3.10 to 3.10.21
35656042f1       Tue Nov 5 08:25:45 2013 +0000     kernel: update 3.10 to 3.10.18
b6b06000eb      Wed Oct 23 12:51:05 2013 +0000     kernel: update 3.10 to 3.10.17
81e2f00367      Sun Oct 13 19:28:29 2013 +0000     kernel: update kernel to 3.10.15
9c8a5ef115      Fri Sep 27 07:19:21 2013 +0000     kernel: update 3.10 to 3.10.13
0db9125157      Thu Sep 26 17:53:28 2013 +0000     build: unify powerpc target cflags
554772a665      Sun Sep 15 16:00:41 2013 +0000     kernel: update 3.10 to 3.10.12
f346e316b4       Sat Sep 7 11:34:08 2013 +0000     ppc40x: remove 3.8 support
8505ccfe74       Sat Sep 7 11:34:06 2013 +0000     ppc40x: switch to 3.10
e9d7620196       Sat Sep 7 11:34:03 2013 +0000     ppc40x: add support for 3.10
73c4d73d6d      Mon Jul 29 09:38:29 2013 +0000     build: unify target independent optimization options
6a4f2922f6      Thu Jun 27 19:58:31 2013 +0000     targets: prepare for supporting normal and initramfs images
c228ed04a1      Fri Jun 21 10:57:05 2013 +0000     increase kernel partition size to fix boot issues
46225b99d9      Sun May 26 16:02:31 2013 +0000     kernel: update linux 3.8 to 3.8.13
e57c7d6c12       Wed May 8 08:53:53 2013 +0000     kernel: update linux 3.8 to 3.8.12
8a9fe26f20       Wed May 1 22:15:18 2013 +0000     kernel: update linux 3.8 to 3.8.11
f718179af5      Tue Apr 30 10:43:59 2013 +0000     kernel: update linux 3.8 to 3.8.10

Solved. It was a firmware bug, combined with an hardware bug, since it seems certain microdrives do not work properly.

Now it works.