hi guys 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 with only that patch [1] ------------------------------------------------------------ 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 Device Tree Blob? if someone has the time to give an eye into this, it's more than appreciated =) thanks Carlo &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. _______________________________________________ Openembedded-architecture mailing list Openembedded-architecture@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
