Problem with cuImage Linux entry from old U-boot

Problem with cuImage Linux entry from old U-boot

[Stephen Horton]

[-- Attachment #1: Type: text/plain, Size: 8742 bytes --]

Hello folks,

 

As I have posted recently before, in a current work project, I have
inherited a compactPCI board that has an mpc7447/7448 powerpc processor
as well as a Marvell system controller, model mv64462 (stripped down
mv64460). The board has a somewhat working Gentoo Linux port running on
it from long ago and a company far far away (kernel version 2.6.9 built
using arch/ppc). To prepare for an upcoming deployment, I would like to
bring the OS up-to-date on this board with a newer kernel (targeting
2.6.24r3).

 

I have made great strides with help from this mailing list and its
archives. I now have a compiled cuImage ready to boot from my older
working u-boot 1.1.2. I now seem to be stuck at the kernel entry point.
I'm not sure if I'm trying to jump into the kernel at the wrong address,
or if I have a serial console issue that prevents me from seeing anymore
progress. Here is my output:

 

debug> bootm
## Booting image at 00800000 ...
   Image Name:   Linux-2.6.24-gentoo-r3
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1515921 Bytes =  1.4 MB
   Load Address: 00400000
   Entry Point:  0040095c
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Transferring control to Linux (at address 0040095c) ...
Memory <- <0x0 0x10000000> (256MB)
ENET0: local-mac-address <- 00:a0:d6:62:38:89
CPU clock-frequency <- 0x3b9ac9d8 (1000MHz)
CPU timebase-frequency <- 0x27bc86a (42MHz)
CPU bus-frequency <- 0x9ef21aa (167MHz)

 

zImage starting: loaded at 0x00400000 (sp: 0x0febfa38)
Allocating 0x35f040 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x00735db0)...done 0x312b34 bytes

 

Linux/PowerPC load: ip=bootp root=/dev/nfs rw nfsroot=/opt/gentoo
console=ttyMM0,9600n8
Finalizing device tree... flat tree at 0x7423a0

 

------

 

If I run 'nm' on my elf image, I expect to find some entry point address
that corresponds to 0x7423a0, but this is not the case. See nm output
below.  Does anyone know what I might be doing wrong?

 

[root@blade3 boot]# nm cuImage.giganew.elf

00736060 b alloc_min

00736058 b alloc_tbl

00400838 T backwards_memcpy

0073606c b bd

00736000 b bridge_base

00736000 A __bss_start

00736010 b chr1

00736014 b chr2

0040aadc d cmdline

00741ee0 B console_ops

00404620 t copy_val

00736018 b cpcr

00736004 b cpld_base

004060f4 t cpm1_cmd

00406174 t cpm2_cmd

00736028 b cpm_cmd

00405d84 T cpm_console_init

00406440 t cpm_serial_getc

00406334 t cpm_serial_open

004062c0 t cpm_serial_putc

00405d3c t cpm_serial_tstc

00405c60 T cuboot_init

00741c14 b cxt

0040a1e4 d dbase.1092

0040a1a4 d dext.1093

0073603c b disable_port

00741d30 b discard_buf.1378

00409922 d distfix.1169

004022e8 T __div64_32

00736034 b do_cmd

0040c098 A _dtb_end

0040ace0 A _dtb_start

00404c38 T dt_fixup_clock

00404cbc T dt_fixup_cpu_clocks

00404aec T dt_fixup_mac_address

00404b7c T __dt_fixup_mac_addresses

00404dec T dt_fixup_memory

00404500 T dt_get_reg_format

00404584 T dt_is_compatible

00741ef4 B dt_ops

00404684 t dt_xlate

00404a00 T dt_xlate_addr

00404a80 T dt_xlate_reg

00736000 A _edata

00736038 b enable_port

00742000 A _end

00408c98 A _etext

00400108 t exit

00401640 t exit

00402420 t exit

004044c4 t exit

00401cac t fdtm_create_node

00401c10 t fdtm_finalize

00401de4 t fdtm_finddevice

00401c54 t fdtm_find_node_by_prop_value

00401cf4 t fdtm_get_parent

00401bc0 t fdtm_get_path

00401d8c t fdtm_getprop

00401d34 t fdtm_setprop

00400000 t finddevice

00401e28 t finddevice

0040430c t finddevice

004050b8 t find_node_by_devtype

004000b0 t find_node_by_prop_value

0040446c t find_node_by_prop_value

0040092c T flush_cache

004073ac T ft_add_rsvmap

004077d4 T ft_begin

00408024 T ft_begin_node

004078b0 T ft_begin_tree

004080c4 T ft_create_node

004072d8 T ft_del_prop

004069b0 T ft_end_node

00406b7c T ft_end_tree

00407428 T ft_find_descendent

004075ec T ft_find_device

004079f0 T __ft_find_node_by_prop_value

00407af8 T ft_find_node_by_prop_value

00407b88 T __ft_get_parent

00407c74 T ft_get_parent

004078c4 T ft_get_path

00406890 t ft_get_phandle

00406ab4 t __ft_get_prop

00406e4c T ft_get_prop

00401b24 T ft_init

00406f48 t ft_make_space

004069d4 t ft_next

0040690c t ft_node_ph2node

00406938 t ft_node_update_after

004081b4 T ft_nop

00407674 T ft_open

00407cdc T ft_prop

00407f84 T ft_prop_int

00407fc8 T ft_prop_str

00406edc t ft_put_bin

00407e44 T ft_set_prop

00406c78 t ft_shuffle

00404414 t get_parent

00400058 t getprop

00401e80 t getprop

00404364 t getprop

00404fec t getprop

004057e8 t getprop

00405ce4 t getprop

0040820c t getprop

0040023c t giganew_fixups

00400530 t giganew_reset

0040aadc D __got2_end

0040a6e0 D __got2_start

004025dc T gunzip_discard

00402574 T gunzip_exactly

0040251c T gunzip_finish

0040245c T gunzip_partial

0040264c T gunzip_start

007364a4 b gzstate

00408804 T inflate_fast

00736000 A _initrd_end

00736000 A _initrd_start

0040a262 d lbase.1090

004099a2 d lenfix.1168

0040a224 d lext.1091

00741eb0 B loader_info

004008dc T memchr

00400904 T memcmp

00400780 T memcpy

00400778 T memmove

0040071c T memset

0040650c T mpc5200_psc_console_init

00736008 b mpsc_base

004058e8 T mpsc_console_init

00405a68 t mpsc_getc

00405840 t mpsc_get_virtreg_of_phandle

0073600c b mpscintr_base

00405b64 t mpsc_open

00405ae4 t mpsc_putc

00405c14 t mpsc_tstc

00736030 b muram_offset

0073602c b muram_start

0040520c T mv64x60_cfg_read

004052f8 T mv64x60_cfg_write

00405288 T mv64x60_config_cpu2pci_window

004055cc T mv64x60_config_ctlr_windows

00405408 T mv64x60_config_pci_windows

0040a4a4 d mv64x60_cpu2mem

0040a6a0 D mv64x60_cpu2pci_io

0040a6c0 D mv64x60_cpu2pci_mem

0040a59c d mv64x60_dram_selects

0040a5ac d mv64x60_enet2mem

00405134 T mv64x60_get_bridge_base

004051a0 T mv64x60_get_bridge_pbase

0040536c T mv64x60_get_mem_size

0040a60c d mv64x60_idma2mem

00405044 T mv64x60_is_coherent

0040a5dc d mv64x60_mpsc2mem

0040a564 d mv64x60_pci2mem

0040a584 d mv64x60_pci2reg

0040a4d4 d mv64x60_pci_acc

0040a63c d mv64x60_pci_cfgio

00736064 b next_base

00406980 t next_start

004082c0 T ns16550_console_init

004083f0 t ns16550_getc

00408264 t ns16550_open

00408464 t ns16550_putc

00408394 t ns16550_tstc

00400abc t number

004098fc d order.1221

0073601c b param

00402854 T parse_elf32

004027b4 T parse_elf64

00400144 T platform_init

00741ec4 B platform_ops

         w _platform_stack_top

004014c8 T printf

00741db0 b prop_buf

00736048 b psc

00406614 t psc_getc

004064b0 t psc_open

004065b8 t psc_putc

004064c0 t psc_tstc

00736040 B rbdf

0073604c b reg_base

00736050 b reg_base

00736054 b reg_shift

00736024 b scc

00406258 t scc_disable_port

004061f0 t scc_enable_port

00741d1c b serial_cd

00401f84 t serial_close

00401fd4 T serial_console_init

004021a8 t serial_edit_cmdline

00401ed8 t serial_open

00401f20 t serial_write

004015e8 t setprop

004043bc t setprop

0040868c T simple_alloc_init

004085d4 t simple_find_entry

00408658 t simple_free

004084d0 t simple_malloc

00408754 t simple_realloc

00400a78 t skip_atoi

00736020 b smc

0040608c t smc_disable_port

00406024 t smc_enable_port

00736068 b space_left

007360a4 b sprint_buf

00401574 T sprintf

0040167c T start

00400000 A _start

0040aadc A __start___builtin_cmdline

0040acdc A __stop___builtin_cmdline

0040066c T strcat

00400698 T strchr

004006b8 T strcmp

00400628 T strcpy

00400704 T strlen

004006dc T strncmp

00400644 T strncpy

00400a44 T strnlen

00736044 B tbdf

0073605c b tbl_entries

0040a69c D timebase_period_ns

004066c4 T uartlite_console_init

004067d0 t uartlite_getc

00406678 t uartlite_open

00406834 t uartlite_putc

00406784 t uartlite_tstc

00402384 T udelay

004023b0 t .udelay_not_601

00735db0 A _vmlinux_end

0040d000 A _vmlinux_start

00400dd4 T vsprintf

00400968 W _zimage_start

00400968 T _zimage_start_lib

00400958 T _zimage_start_opd

004028f4 t zlib_adler32

00402dc0 T zlib_inflate

00402bb4 T zlib_inflateEnd

00402cf8 T zlib_inflateIncomp

00402b1c T zlib_inflateInit2

00402a90 T zlib_inflateReset

00403dd4 T zlib_inflate_table

00402a7c T zlib_inflate_workspacesize

00402be0 t zlib_updatewindow


[-- Attachment #2: Type: text/html, Size: 42482 bytes --]

Re: Problem with cuImage Linux entry from old U-boot

[Scott Wood]

On Mon, Jul 21, 2008 at 03:39:55PM -0500, Stephen Horton wrote:
> I have made great strides with help from this mailing list and its
> archives. I now have a compiled cuImage ready to boot from my older
> working u-boot 1.1.2. I now seem to be stuck at the kernel entry point.
> I'm not sure if I'm trying to jump into the kernel at the wrong address,
> or if I have a serial console issue that prevents me from seeing anymore
> progress.

Most likely the latter, or some other issue that prevents the kernel from
booting to the point where the serial console functions.

> Linux/PowerPC load: ip=bootp root=/dev/nfs rw nfsroot=/opt/gentoo
> console=ttyMM0,9600n8
> Finalizing device tree... flat tree at 0x7423a0
> 
>  
> 
> ------
> 
>  
> 
> If I run 'nm' on my elf image, I expect to find some entry point address
> that corresponds to 0x7423a0, but this is not the case. 

Why would you expect that?  It's a dynamically allocated chunk of memory
that holds the device tree that is passed to the kernel.  It's not an entry
point; the entry point to the kernel is zero.

-Scott

RE: Problem with cuImage Linux entry from old U-boot

[Mike Timmons]

Related question: I'm using a newer U-boot and managing the load of the
kernel and the device tree from separate partitions of my boot media.

Having the two partitions and managing the kernel and the tree
separately is a bit cumbersome, or maybe I'm just lazy. Regardless, can
I just use that "static" file name option when I build the kernel, load
the cuImage, and just invoke=20

bootm <cuImageLoadAddress> ?

Will it work to just leave off the - <device tree Ram address>

I think I had it set-p right yesterday and I gave it a try, but no joy.

Can it be this simple to statically link the device tree with the kernel
build? For my application I don't see a benefit in keeping them separate
(the kernel and the tree).

Thanks,
Mike


-----Original Message-----
From: linuxppc-embedded-bounces+mike_timmons=3Dtrimble.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+mike_timmons=3Dtrimble.com@ozlabs.org]
On Behalf Of Scott Wood
Sent: Tuesday, July 22, 2008 1:05 PM
To: Stephen Horton
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Problem with cuImage Linux entry from old U-boot

On Mon, Jul 21, 2008 at 03:39:55PM -0500, Stephen Horton wrote:
> I have made great strides with help from this mailing list and its
> archives. I now have a compiled cuImage ready to boot from my older
> working u-boot 1.1.2. I now seem to be stuck at the kernel entry
point.
> I'm not sure if I'm trying to jump into the kernel at the wrong
address,
> or if I have a serial console issue that prevents me from seeing
anymore
> progress.

Most likely the latter, or some other issue that prevents the kernel
from
booting to the point where the serial console functions.

> Linux/PowerPC load: ip=3Dbootp root=3D/dev/nfs rw =
nfsroot=3D/opt/gentoo
> console=3DttyMM0,9600n8
> Finalizing device tree... flat tree at 0x7423a0
>=20
> =20
>=20
> ------
>=20
> =20
>=20
> If I run 'nm' on my elf image, I expect to find some entry point
address
> that corresponds to 0x7423a0, but this is not the case.=20

Why would you expect that?  It's a dynamically allocated chunk of memory
that holds the device tree that is passed to the kernel.  It's not an
entry
point; the entry point to the kernel is zero.

-Scott
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Problem with cuImage Linux entry from old U-boot

[Scott Wood]

Mike Timmons wrote:
> Related question: I'm using a newer U-boot and managing the load of the
> kernel and the device tree from separate partitions of my boot media.
> 
> Having the two partitions and managing the kernel and the tree
> separately is a bit cumbersome, or maybe I'm just lazy. Regardless, can
> I just use that "static" file name option when I build the kernel, load
> the cuImage, and just invoke 
> 
> bootm <cuImageLoadAddress> ?
> 
> Will it work to just leave off the - <device tree Ram address>
> 
> I think I had it set-p right yesterday and I gave it a try, but no joy.
> 
> Can it be this simple to statically link the device tree with the kernel
> build? For my application I don't see a benefit in keeping them separate
> (the kernel and the tree).

Yes, you can use cuImage to bundle the device tree with the kernel (note 
that the type of image you use *must* match the type of bootm command 
you use), though it's not recommended if you have a u-boot that can 
properly pass a device tree.  cuImage relies on the bd_t to get 
information from u-boot, and this is a very fragile structure, and 
contains less information than the device tree.

-Scott

RE: Problem with cuImage Linux entry from old U-boot

[Stephen Horton]

Thanks Scott for the tip. I'll redouble my efforts to compare the code
in my older 1.1.2 U-boot source (that the board boots from) with my new
.dts and cuboot source.

-----Original Message-----
From: Scott Wood [mailto:scottwood@freescale.com]=20
Sent: Tuesday, July 22, 2008 1:05 PM
To: Stephen Horton
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Problem with cuImage Linux entry from old U-boot

On Mon, Jul 21, 2008 at 03:39:55PM -0500, Stephen Horton wrote:
> I have made great strides with help from this mailing list and its
> archives. I now have a compiled cuImage ready to boot from my older
> working u-boot 1.1.2. I now seem to be stuck at the kernel entry
point.
> I'm not sure if I'm trying to jump into the kernel at the wrong
address,
> or if I have a serial console issue that prevents me from seeing
anymore
> progress.

Most likely the latter, or some other issue that prevents the kernel
from
booting to the point where the serial console functions.

> Linux/PowerPC load: ip=3Dbootp root=3D/dev/nfs rw =
nfsroot=3D/opt/gentoo
> console=3DttyMM0,9600n8
> Finalizing device tree... flat tree at 0x7423a0
>=20
> =20
>=20
> ------
>=20
> =20
>=20
> If I run 'nm' on my elf image, I expect to find some entry point
address
> that corresponds to 0x7423a0, but this is not the case.=20

Why would you expect that?  It's a dynamically allocated chunk of memory
that holds the device tree that is passed to the kernel.  It's not an
entry
point; the entry point to the kernel is zero.

-Scott