Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
uboot hangs with ARCH=POWERPC, kernel >=2.6.25 need it
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on PPC
View previous topic :: View next topic  
Author Message
ddc
Guru
Guru


Joined: 29 Aug 2006
Posts: 527

PostPosted: Sun Jan 31, 2010 12:47 pm    Post subject: uboot hangs with ARCH=POWERPC, kernel >=2.6.25 need it Reply with quote

hello
i m developing around a pretty ppc405GB board

i have successfully booted kernel from 2.6.12 to 2.6.22 on the uBoot-1.2, which is the firmare bootloader

in the actual kernel tree i see 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; it now requires the device tree.

From Documentation/powerpc/bootwrapper.txt:

Code:
 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.


There is no walnut cuImage(???), so the only choice is to use this "new-style" uImage and have uboot pass a right device-tree file to the kernel

so ... no way


any idea ?
Back to top
View user's profile Send private message
JoseJX
Retired Dev
Retired Dev


Joined: 28 Apr 2002
Posts: 2774

PostPosted: Sun Jan 31, 2010 4:30 pm    Post subject: Reply with quote

You should be able to upgrade your bootloader to a version which supports flattened device trees. Take a look at http://www.denx.de/wiki/U-Boot/UBootFdtInfo for more info. Which board are you working on specifically?
_________________
Gentoo PPC FAQ: http://www.gentoo.org/doc/en/gentoo-ppc-faq.xml
Back to top
View user's profile Send private message
ddc
Guru
Guru


Joined: 29 Aug 2006
Posts: 527

PostPosted: Sun Jan 31, 2010 8:08 pm    Post subject: Reply with quote

JoseJX wrote:
You should be able to upgrade your bootloader to a version which supports flattened device trees. Take a look at http://www.denx.de/wiki/U-Boot/UBootFdtInfo for more info. Which board are you working on specifically?



no i can't upgrade my bootloader (uboot-1.2) cause it has a specific patch (hack) that makes it able to load kernel from harddrive, and i need it: porting the patch to newer uboot is too difficult for me, and this patch has not been approved in the uBoot stuff ... so no way


my target boards are: dht-walnut and walnut (which has no hard drive, so i could update the bootloader, but i'd like to have both boards in sync)

also i have the ebony: CPU=ppc440, firmware=uboot
and the sandpointX3: CPU=ppc7450, firmware=dink32 (not tested yet)


i am developing a special kexec bootloader (mostly designed to solve a pretty ARMv5-board problem)
so ... i can also use it for powerPC and

1) use the actual uboot-1.2 to boot
2) && tftp load a pretty 2.6.22+kexec app in the "early rootfs"
3) use kexec to load a kernel >=2.6.25 into memory
4) jump to it, boot it

yes, a bit complicate, but it's working with: {elf, zImage} (tested on apple powerbook G3)


anyway i prefer to use the "old style" uImage ... so, as far as what i read in 2.6.32 documentation ... i should use something like "cuImage" or treeImage .... or simplyImage


well, not yet tested


Last edited by ddc on Mon Feb 01, 2010 12:34 pm; edited 1 time in total
Back to top
View user's profile Send private message
ddc
Guru
Guru


Joined: 29 Aug 2006
Posts: 527

PostPosted: Mon Feb 01, 2010 12:31 pm    Post subject: Reply with quote

Code:
Based on kernel version 2.6.32. Page generated on 2009-12-11 16:23 EST.

1   The PowerPC boot wrapper
2   ------------------------
3   Copyright (C) Secret Lab Technologies Ltd.
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.
Back to top
View user's profile Send private message
ddc
Guru
Guru


Joined: 29 Aug 2006
Posts: 527

PostPosted: Wed Feb 10, 2010 5:06 pm    Post subject: Reply with quote

anybody experimenting it ?
anybody needs support about these boards ?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on PPC All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum