[PPC] t1024rdb: CONFIG_KERNEL_START=0x0 equivalent for ppc64 (Kernel 3.16.85)

[PPC] t1024rdb: CONFIG_KERNEL_START=0x0 equivalent for ppc64 (Kernel 3.16.85)

[Alex Fetzner]

Hello all,

I have a legacy product using linux 3.12.19 that I am updating to use linux 4 and eventually 5. 
The product use an NXT (Freescale) t1024rdb (e5500 processor).
I am right now trying to compile a 3.16.85 kernel that works as a stand-in replacement for the existing kernel. The product uses a u-boot load address 0x1000000 (1MB) and flattened device tree address 0x2000000 (2MB). The deployment of this kernel is such that I cannot alter these address.
The original uImage header has load address and entry point 0x0.
The original vmlinux ELF from the uImage has entry point address 0x0.

How do I appropriately alter a ppc64 kernel to have entry point 0x0?
I can create a uImage header with load and entry point 0x0, but the kernel uses a virtual address 0xc000000000000000 as entry point. 
I see that 32 bit kernels have the configurable option CONFIG_KERNEL_START, but this is not available for 64 bit. 

Kind regards,
AF

Re: [PPC] t1024rdb: CONFIG_KERNEL_START=0x0 equivalent for ppc64 (Kernel 3.16.85)

[Christophe Leroy]

Hi Alex,

Le 12/10/2025 à 00:18, Alex Fetzner a écrit :
> [Vous ne recevez pas souvent de courriers de alex@fetzner.me. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hello all,
> 
> I have a legacy product using linux 3.12.19 that I am updating to use linux 4 and eventually 5.
> The product use an NXT (Freescale) t1024rdb (e5500 processor).
> I am right now trying to compile a 3.16.85 kernel that works as a stand-in replacement for the existing kernel. The product uses a u-boot load address 0x1000000 (1MB) and flattened device tree address 0x2000000 (2MB). The deployment of this kernel is such that I cannot alter these address.
> The original uImage header has load address and entry point 0x0.
> The original vmlinux ELF from the uImage has entry point address 0x0.
> 
> How do I appropriately alter a ppc64 kernel to have entry point 0x0?
> I can create a uImage header with load and entry point 0x0, but the kernel uses a virtual address 0xc000000000000000 as entry point.
> I see that 32 bit kernels have the configurable option CONFIG_KERNEL_START, but this is not available for 64 bit.

Even with the CONFIG_KERNEL_START you can't expect any kernel to have a 
virtual start address of 0, because the KERNEL needs to be above user space.

But you shouldn't need that. It is the role of the loader to set the MMU 
so that the kernel is running with the correct virtual address.

I don't understand why you need the virtual starting address of vmlinux 
to be 0x0.

Here is what I get with ppc64e_defconfig with v6.18-rc1:

CPU:   Unknown, Version: 0.0, (0x00000000)
Core:  e5500, Version: 2.0, (0x80240020)
Clock Configuration:
        CPU0:400  MHz,
        CCB:400  MHz,
        DDR:200  MHz (400 MT/s data rate), LBC: unknown (LCRR[CLKDIV] = 
0x00)
L1:    D-cache 32 KiB enabled
        I-cache 32 KiB enabled
DRAM:  1 GiB
L2:    disabled

PCI: base address e0008000
   00:01.0     - 1af4:1000 - Network controller
PCI1: Bus 00 - 00

In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 02000000 ...
    Image Name:   Linux-6.18.0-rc1-00010-g179dbcda
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    7217834 Bytes = 6.9 MiB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
## Flattened Device Tree blob at e8000000
    Booting using the fdt blob at 0xe8000000
    Uncompressing Kernel Image ... OK
    Loading Device Tree to 03efc000, end 03ffefff ... OK
random: crng init done
Activating Kernel Userspace Access Protection
Activating Kernel Userspace Execution Prevention
MMU: Supported page sizes
          4 KB as direct
       4096 KB as direct
      16384 KB as direct
      65536 KB as direct
     262144 KB as direct
    1048576 KB as direct
MMU: Book3E HW tablewalk not supported
Linux version 6.18.0-rc1-00010-g179dbcda9eb3 
(chleroy@PO20335.IDSI0.si.c-s.fr) (powerpc64-linux-gcc (GCC) 15.1.0, GNU 
ld (GNU Binutils) 2.44) #1697 SMP Wed Oct 15 13:47:20 CEST 2025
OF: reserved mem: Reserved memory: No reserved-memory node in the DT
Found initrd at 0xc000000004000000:0xc0000000041d1a3b
Hardware name: QEMU ppce500 e5500 0x80240020 QEMU e500
printk: legacy bootconsole [udbg0] enabled
CPU maps initialized for 1 thread per core
-----------------------------------------------------
phys_mem_size     = 0x40000000
dcache_bsize      = 0x40
icache_bsize      = 0x40
cpu_features      = 0x0000000300800194
   possible        = 0x0000000300900394
   always          = 0x0000000300800394
cpu_user_features = 0xcc008000 0x08000000
mmu_features      = 0x000a0010
firmware_features = 0x0000000000000000
-----------------------------------------------------
qemu_e500_setup_arch()
barrier-nospec: using isync; sync as speculation barrier
Zone ranges:
   DMA      [mem 0x0000000000000000-0x000000003fffffff]
   Normal   empty
Movable zone start for each node
Early memory node ranges
   node   0: [mem 0x0000000000000000-0x000000003fffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x000000003fffffff]
MMU: Allocated 2112 bytes of context maps for 255 contexts
percpu: Embedded 27 pages/cpu s70232 r0 d40360 u1048576
Kernel command line: noreboot
Unknown kernel command line parameters "noreboot", will be passed to 
user space.
printk: log buffer data + meta data: 131072 + 458752 = 589824 bytes
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
Built 1 zonelists, mobility grouping on.  Total pages: 262144
mem auto-init: stack:all(zero), heap alloc:off, heap free:off
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
rcu: Hierarchical RCU implementation.
rcu: 	RCU event tracing is enabled.
rcu: 	RCU restricting CPUs from NR_CPUS=32 to nr_cpu_ids=1.
	Tracing variant of Tasks RCU enabled.
rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
RCU Tasks Trace: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1 
rcu_task_cpu_ids=1.
NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
mpic: Setting up MPIC " OpenPIC  " version 1.2 at fe0040000, max 1 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
...

Christophe

Re: [PPC] t1024rdb: CONFIG_KERNEL_START=0x0 equivalent for ppc64 (Kernel 3.16.85)

[Alex Fetzner]

Thanks Christophe

> > How do I appropriately alter a ppc64 kernel to have entry point 0x0?
After working with the issue further, I determined my original question was 
ill-formed because I had an incomplete understanding. 

> Even with the CONFIG_KERNEL_START you can't expect any kernel to have a
> virtual start address of 0, because the KERNEL needs to be above user space.
>
> But you shouldn't need that. It is the role of the loader to set the MMU
> so that the kernel is running with the correct virtual address.
> 
> I don't understand why you need the virtual starting address of vmlinux
> to be 0x0.
Indeed, it doesn't make sense for kernel start address 0x0.
As I am trying to make a stand-in for another kernel image without changing
the U-Boot load address, I saw that the original vmlinux ELF header had
Entry point address: 0x0 
But critically, as I now understand, it also had 
Type: DYN , not EXEC

What I determined is that I needed CONFIG_RELOCATABLE=y; I did not need to
alter the load address. After making a relocatable kernel, I was able to get 
it to boot on my hardware.

> 
> Here is what I get with ppc64e_defconfig with v6.18-rc1:
>
Thank you for taking the time to find this for me.

Kind regards,
Alex