ARM: shmobile: kzm9g-reference: 0x48008000 load address

From: Magnus Damm <[email protected]>

Adjust the load address for the KZM9G DT reference case to make it compatible with upcoming sh73a0 Multiplatform and CONFIG_AUTO_ZRELADDR=y.

Without the not-yet-merged sh73a0 multiplatform support the KZM9G uImage can be built without any special care, but once we go DTS-only then the Makefile.boot entry will disappear and the Multiplatform image will be built using CONFIG_AUTO_ZRELADDR=y. To generate an uImage for KZM9G the following example can be followed:

$ make ARCH=arm LOADADDR=0x48008000 uImage

For now simply adjust the non-multiplatform KZM9G DT reference implementation to be compatible with ZRELADDR.

Signed-off-by Magnus Damm <[email protected]>

Hi Magnus,

Quoted 13 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Adjust the load address for the KZM9G DT reference case to make it compatible with upcoming sh73a0 Multiplatform and CONFIG_AUTO_ZRELADDR=y.

Without the not-yet-merged sh73a0 multiplatform support the KZM9G uImage can be built without any special care, but once we go DTS-only then the Makefile.boot entry will disappear and the Multiplatform image will be built using CONFIG_AUTO_ZRELADDR=y. To generate an uImage for KZM9G the following example can be followed:

Quoted 6 lines

$ make ARCH=arm LOADADDR=0x48008000 uImage

For now simply adjust the non-multiplatform KZM9G DT reference implementation to be compatible with ZRELADDR.

Signed-off-by Magnus Damm <[email protected]>

Does this mean it now boots with reg = <0x41000000 0x1e800000> in the memory node, and
[PATCH/RFC 1/2] ARM: shmobile: kzm9g dts: Declare the full 512 MiB of RAM
http://www.spinics.net/lists/linux-sh/msg37196.html
[PATCH/RFC 2/2] ARM: shmobile: kzm9g-reference dts: Declare the full 512 MiB of RAM
http://www.spinics.net/lists/linux-sh/msg37195.html
are not needed?

Quoted 21 lines · Geert Uytterhoeven

Quoted 13 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Adjust the load address for the KZM9G DT reference case to make it compatible with upcoming sh73a0 Multiplatform and CONFIG_AUTO_ZRELADDR=y.

Without the not-yet-merged sh73a0 multiplatform support the KZM9G uImage can be built without any special care, but once we go DTS-only then the Makefile.boot entry will disappear and the Multiplatform image will be built using CONFIG_AUTO_ZRELADDR=y. To generate an uImage for KZM9G the following example can be followed:

Quoted 6 lines

$ make ARCH=arm LOADADDR=0x48008000 uImage

For now simply adjust the non-multiplatform KZM9G DT reference implementation to be compatible with ZRELADDR.

Signed-off-by Magnus Damm <[email protected]>

Quoted 8 lines

Does this mean it now boots with reg = <0x41000000 0x1e800000> in the memory node, and
[PATCH/RFC 1/2] ARM: shmobile: kzm9g dts: Declare the full 512 MiB of RAM
http://www.spinics.net/lists/linux-sh/msg37196.html
[PATCH/RFC 2/2] ARM: shmobile: kzm9g-reference dts: Declare the full 512 MiB of RAM
http://www.spinics.net/lists/linux-sh/msg37195.html
are not needed?

Thanks, but I believe they are not needed.

The new load address is compatible with the ZRELADDR 0xf8000000 mask and that's all it takes.

I may be wrong though, let me know if you run into trouble.

Hi Magnus,

Quoted 34 lines · Magnus Damm

Quoted 21 lines · Geert Uytterhoeven

Quoted 13 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Adjust the load address for the KZM9G DT reference case to make it compatible with upcoming sh73a0 Multiplatform and CONFIG_AUTO_ZRELADDR=y.

Without the not-yet-merged sh73a0 multiplatform support the KZM9G uImage can be built without any special care, but once we go DTS-only then the Makefile.boot entry will disappear and the Multiplatform image will be built using CONFIG_AUTO_ZRELADDR=y. To generate an uImage for KZM9G the following example can be followed:

Quoted 6 lines

$ make ARCH=arm LOADADDR=0x48008000 uImage

For now simply adjust the non-multiplatform KZM9G DT reference implementation to be compatible with ZRELADDR.

Signed-off-by Magnus Damm <[email protected]>

Quoted 8 lines

Does this mean it now boots with reg = <0x41000000 0x1e800000> in the memory node, and
[PATCH/RFC 1/2] ARM: shmobile: kzm9g dts: Declare the full 512 MiB of RAM
http://www.spinics.net/lists/linux-sh/msg37196.html
[PATCH/RFC 2/2] ARM: shmobile: kzm9g-reference dts: Declare the full 512 MiB of RAM
http://www.spinics.net/lists/linux-sh/msg37195.html
are not needed?

Thanks, but I believe they are not needed.

Quoted 4 lines

The new load address is compatible with the ZRELADDR 0xf8000000 mask and that's all it takes.

I may be wrong though, let me know if you run into trouble.

Oops, I hadn't noticed this is for CONFIG_MACH_KZM9G_REFERENCE, so this not used for not multi-platform.

Hence no change is made for multi-platform.
How can the memory address in the DTS of 0x41000000 work with CONFIG_AUTO_ZRELADDR?

Do you boot a zImage or a uImage?

I usually use a zImage with appended DTB on kzm9g. It fails as before:

TFTP from server 192.168.97.21; our IP address is 192.168.97.35 Filename 'kzm9g/zImage.dtb'.
Load address: 0x43000000
Loading: #################################################################

         #################################################################
         ###############################################################

done
Bytes transferred = 2829743 (2b2daf hex)

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.18.0-kzm9g-multiplatform-11069-g3086a70162bdec42 (geert@ramsan) (gcc version 4.9.0 (GCC) ) #274 SMP Wed Dec 17 13:28:08 CET 2014
CPU: ARMv7 Processor [412fc098] revision 8 (ARMv7), crc5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: KZM-A9-GT
bootconsole [earlycon0] enabled
debug: ignoring loglevel setting.
Memory policy: Data cache writealloc
On node 0 totalpages: 124928
free_area_init_node: node 0, pgdat c058f640, node_mem_map df428000
Normal zone: 976 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 124928 pages, LIFO batch:31

When trying with a uImage with the "new" load address i.e.

make ARCH=arm LOADADDR=0x48008000 uImage

it still fails:

TFTP from server 192.168.97.21; our IP address is 192.168.97.35 Filename 'kzm9g/uImage'.
Load address: 0x43000000
Loading: #################################################################

         #################################################################
         ##############################################################

done
Bytes transferred = 2811440 (2ae630 hex)
KZM-A9-GT# tftp 0x50000000 kzm9g/sh73a0-kzm9g.dtb
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 00:01:9b:04:04:20
Using smc911x-0 device
TFTP from server 192.168.97.21; our IP address is 192.168.97.35 Filename 'kzm9g/sh73a0-kzm9g.dtb'.
Load address: 0x50000000
Loading: ##
done
Bytes transferred = 18367 (47bf hex)
KZM-A9-GT# bootm 0x43000000 - 0x50000000
## Booting kernel from Legacy Image at 43000000 ...

   Image Name:   Linux-3.18.0-kzm9g-multiplatform
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2811376 Bytes = 2.7 MiB

Load Address: 48008000
Entry Point: 48008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 50000000
Booting using the fdt blob at 0x50000000 Loading Kernel Image ... OK
OK
Loading Device Tree to 417f8000, end 417ff7be ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.18.0-kzm9g-multiplatform-11069-g3086a70162bdec42 (geert@ramsan) (gcc version 4.9.0 (GCC) ) #274 SMP Wed Dec 17 13:28:08 CET 2014
CPU: ARMv7 Processor [412fc098] revision 8 (ARMv7), crc5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: KZM-A9-GT
Ignoring memory range 0x41000000 - 0x48000000
bootconsole [earlycon0] enabled
debug: ignoring loglevel setting.
Memory policy: Data cache writealloc
On node 0 totalpages: 98304
free_area_init_node: node 0, pgdat c058f640, node_mem_map d7cf8000
Normal zone: 768 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 98304 pages, LIFO batch:31

Unable to handle kernel paging request at virtual address b97f8000
pgd = c0004000
[b97f8000] *pgd000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted
3.18.0-kzm9g-multiplatform-11069-g3086a70162bdec42 #274
Hardware name: Generic SH73A0 (Flattened Device Tree)
task: c0562968 ti: c0558000 task.ti: c0558000
PC is at fdt_check_header+0xc/0x80
LR is at __unflatten_device_tree+0x24/0xf4

Am I missing something?

Quoted 1 line

Do you boot a zImage or a uImage?

uImage built from zImage with appended DTB.

These 4 steps actually:
rm arch/arm/boot/zImage
make -j 9 ARCH=arm CROSS_COMPILE=_ dtbs zImage
cat arch/arm/boot/dts/sh73a0-kzm9g.dtb >> arch/arm/boot/zImage make -j 9 ARCH=arm CROSS_COMPILE=_ LOADADDR=0x48008000 uImage

Quoted 18 lines

I usually use a zImage with appended DTB on kzm9g. It fails as before:

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.18.0-kzm9g-multiplatform-11069-g3086a70162bdec42 (geert@ramsan) (gcc version 4.9.0 (GCC) ) #274 SMP Wed Dec 17 13:28:08 CET 2014
CPU: ARMv7 Processor [412fc098] revision 8 (ARMv7), crc5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: KZM-A9-GT
bootconsole [earlycon0] enabled
debug: ignoring loglevel setting.
Memory policy: Data cache writealloc
On node 0 totalpages: 124928
free_area_init_node: node 0, pgdat c058f640, node_mem_map df428000
Normal zone: 976 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 124928 pages, LIFO batch:31

Wow, earlycon. Luxury. =)

The string above says "kzm9g-multiplatform". Did you try legacy or DT reference without CCF?

Quoted 11 lines

When trying with a uImage with the "new" load address i.e.

make ARCH=arm LOADADDR=0x48008000 uImage

it still fails:

## Flattened Device Tree blob at 50000000
Booting using the fdt blob at 0x50000000 Loading Kernel Image ... OK
OK
Loading Device Tree to 417f8000, end 417ff7be ... OK

Quoted 1 line

Unable to handle kernel paging request at virtual address b97f8000

You seem to be using "bootm 0x43000000 - 0x50000000".
In my case I simply use "bootp; bootm". I also tend to use appended

DTB and compile-in the command line to rely on the boot loader as little as ever possible.

One thing that bit me for quite some time was when handling the case CONFIG_AUTO_ZRELADDR=n. I built the zImage using my steps above but I did not pass the LOADADDR when building the zImage - so the "zreladdr-y" value in Makefile.boot was still the default value which ended up in the kernel image. What I mistakenly ended up doing was to only adjust the uImage load address. And your bootm line above has even more magic to it - so you may have 3 different versions... =)

Hi Magnus,

Quoted 9 lines · Magnus Damm

Quoted 1 line

Do you boot a zImage or a uImage?

uImage built from zImage with appended DTB.

These 4 steps actually:
rm arch/arm/boot/zImage
make -j 9 ARCH=arm CROSS_COMPILE=_ dtbs zImage
cat arch/arm/boot/dts/sh73a0-kzm9g.dtb >> arch/arm/boot/zImage make -j 9 ARCH=arm CROSS_COMPILE=_ LOADADDR=0x48008000 uImage

Thanks, that works!
But the machine lost 128 MiB of RAM, compared to adjusting the "reg" property of the memory node :-(

Quoted 19 lines

Quoted 18 lines

I usually use a zImage with appended DTB on kzm9g. It fails as before:

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.18.0-kzm9g-multiplatform-11069-g3086a70162bdec42 (geert@ramsan) (gcc version 4.9.0 (GCC) ) #274 SMP Wed Dec 17 13:28:08 CET 2014
CPU: ARMv7 Processor [412fc098] revision 8 (ARMv7), crc5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: KZM-A9-GT
bootconsole [earlycon0] enabled
debug: ignoring loglevel setting.
Memory policy: Data cache writealloc
On node 0 totalpages: 124928
free_area_init_node: node 0, pgdat c058f640, node_mem_map df428000
Normal zone: 976 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 124928 pages, LIFO batch:31

Quoted 1 line

Wow, earlycon. Luxury. =)

Noh, a necessity when developing ;-)

Quoted 2 lines

The string above says "kzm9g-multiplatform". Did you try legacy or DT reference without CCF?

Yes, they both work (with zImage and appended DTB), as before.

Quoted 11 lines

Quoted 11 lines

When trying with a uImage with the "new" load address i.e.

make ARCH=arm LOADADDR=0x48008000 uImage

it still fails:

## Flattened Device Tree blob at 50000000
Booting using the fdt blob at 0x50000000 Loading Kernel Image ... OK
OK
Loading Device Tree to 417f8000, end 417ff7be ... OK

Aarghl, u-Boot copied the DT below 0x48000000. That's why it fails:

Quoted 1 line

Quoted 1 line

Unable to handle kernel paging request at virtual address b97f8000

Hence no choice but to use uImage+DTB.

Quoted 2 lines

You seem to be using "bootm 0x43000000 - 0x50000000".
In my case I simply use "bootp; bootm". I also tend to use appended

My DHCP server (OpenWRT dnsmasq) doesn't provide TFTP/NFS information to its clients.

Quoted 2 lines

DTB and compile-in the command line to rely on the boot loader as little as ever possible.

Indeed.

Quoted 7 lines

One thing that bit me for quite some time was when handling the case CONFIG_AUTO_ZRELADDR=n. I built the zImage using my steps above but I did not pass the LOADADDR when building the zImage - so the "zreladdr-y" value in Makefile.boot was still the default value which ended up in the kernel image. What I mistakenly ended up doing was to only adjust the uImage load address. And your bootm line above has even more magic to it - so you may have 3 different versions... =)

I usually use zImage, which is better for multiplatform. In theory the same multiplatform zImage should boot on all machines.

Quoted 8 lines

Quoted 7 lines

uImage built from zImage with appended DTB.

These 4 steps actually:
rm arch/arm/boot/zImage
make -j 9 ARCH=arm CROSS_COMPILE=_ dtbs zImage
cat arch/arm/boot/dts/sh73a0-kzm9g.dtb >> arch/arm/boot/zImage make -j 9 ARCH=arm CROSS_COMPILE=_ LOADADDR=0x48008000 uImage

Quoted 3 lines

Thanks, that works!
But the machine lost 128 MiB of RAM, compared to adjusting the "reg" property of the memory node :-(

Huh, I wasn't aware that we also loose memory!?

I suppose we need to update the code to allow registering memory below the kernel load address.

Quoted 4 lines · Magnus Damm

Quoted 1 line

Do you boot a zImage or a uImage?

uImage built from zImage with appended DTB.

Quoted 5 lines

These 4 steps actually:
rm arch/arm/boot/zImage
make -j 9 ARCH=arm CROSS_COMPILE=_ dtbs zImage
cat arch/arm/boot/dts/sh73a0-kzm9g.dtb >> arch/arm/boot/zImage make -j 9 ARCH=arm CROSS_COMPILE=_ LOADADDR=0x48008000 uImage

Thanks, that works!

But the machine lost 128 MiB of RAM, compared to adjusting the "reg" property of the memory node :-(

Quoted 16 lines

Quoted 16 lines

I usually use a zImage with appended DTB on kzm9g. It fails as before:

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.18.0-kzm9g-multiplatform-11069-g3086a70162bdec42 (geert@ramsan) (gcc version 4.9.0 (GCC) ) #274 SMP Wed Dec 17 13:28:08 CET 2014
CPU: ARMv7 Processor [412fc098] revision 8 (ARMv7), crc5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: KZM-A9-GT
bootconsole [earlycon0] enabled
debug: ignoring loglevel setting.
Memory policy: Data cache writealloc
On node 0 totalpages: 124928
free_area_init_node: node 0, pgdat c058f640, node_mem_map df428000

Quoted 5 lines

Quoted 3 lines

Normal zone: 976 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 124928 pages, LIFO batch:31

Wow, earlycon. Luxury. =)

Noh, a necessity when developing ;-)

Quoted 2 lines

The string above says "kzm9g-multiplatform". Did you try legacy or DT reference without CCF?

Yes, they both work (with zImage and appended DTB), as before.

Quoted 6 lines

Quoted 6 lines

When trying with a uImage with the "new" load address i.e.

make ARCH=arm LOADADDR=0x48008000 uImage

it still fails:

Quoted 8 lines

Quoted 8 lines

## Flattened Device Tree blob at 50000000

Booting using the fdt blob at 0x50000000
Loading Kernel Image ... OK

OK

Loading Device Tree to 417f8000, end 417ff7be ... OK

Aarghl, u-Boot copied the DT below 0x48000000. That's why it fails:

Quoted 1 line

Quoted 1 line

Unable to handle kernel paging request at virtual address b97f8000

Hence no choice but to use uImage+DTB.

Quoted 2 lines

You seem to be using "bootm 0x43000000 - 0x50000000".
In my case I simply use "bootp; bootm". I also tend to use appended

My DHCP server (OpenWRT dnsmasq) doesn't provide TFTP/NFS information to its clients.

Quoted 2 lines

DTB and compile-in the command line to rely on the boot loader as little as ever possible.

Indeed.

Quoted 7 lines

One thing that bit me for quite some time was when handling the case CONFIG_AUTO_ZRELADDR=n. I built the zImage using my steps above but I did not pass the LOADADDR when building the zImage - so the "zreladdr-y" value in Makefile.boot was still the default value which ended up in the kernel image. What I mistakenly ended up doing was to only adjust the uImage load address. And your bootm line above has even more magic to it - so you may have 3 different versions... =)

I usually use zImage, which is better for multiplatform. In theory the same multiplatform zImage should boot on all machines.

Quoted 5 lines · On Wednesday 17 December 2014 14:35:32 Geert Uytterhoeven wrote:

Quoted 4 lines · Magnus Damm

Quoted 1 line

Do you boot a zImage or a uImage?

uImage built from zImage with appended DTB.

Quoted 7 lines

Quoted 5 lines

These 4 steps actually:
rm arch/arm/boot/zImage
make -j 9 ARCH=arm CROSS_COMPILE=_ dtbs zImage
cat arch/arm/boot/dts/sh73a0-kzm9g.dtb >> arch/arm/boot/zImage make -j 9 ARCH=arm CROSS_COMPILE=_ LOADADDR=0x48008000 uImage

Thanks, that works!

And it doesn't for me :-/

Any idea why NFS root doesn't work with your wip branch and shmobile_defconfig (with NFSv4 and NFSv3 ACL disabled) ? The kernel stops after

[    6.630000] Sending DHCP requests ., OK
[    6.670000] IP-Config: Got DHCP answer from 192.168.1.47, my address is
192.168.1.254
[    6.680000] IP-Config: Complete:
[    6.690000]      device=eth0, hwaddr:01:9b:04:04:22,
ipaddr2.168.1.254, mask%5.255.255.0, gw%5.255.255.255
[    6.700000]      host2.168.1.254, domain=, nis-domain=(none)
[    6.700000]      bootserver2.168.1.47, rootserver2.168.1.47,
rootpath=/home/laurent/src/iob/netboot/renesas
[    6.710000]      nameserver02.168.1.47
[    6.720000] SDHI2 Vcc: disabling
[    6.720000] SDHI0 Vcc: disabling
[    6.720000] vccq_mc0: disabling
[    6.730000] ALSA device list:
[    6.730000]   #0: fsia-dai-ak4642-hifi

and then oopses after a timeout. No NFS-related packet is received by the host according to tcpdump.

Quoted 19 lines

Any idea why NFS root doesn't work with your wip branch and shmobile_defconfig (with NFSv4 and NFSv3 ACL disabled) ? The kernel stops after

[    6.630000] Sending DHCP requests ., OK
[    6.670000] IP-Config: Got DHCP answer from 192.168.1.47, my address is
192.168.1.254
[    6.680000] IP-Config: Complete:
[    6.690000]      device=eth0, hwaddr:01:9b:04:04:22,
ipaddr2.168.1.254, mask%5.255.255.0, gw%5.255.255.255
[    6.700000]      host2.168.1.254, domain=, nis-domain=(none)
[    6.700000]      bootserver2.168.1.47, rootserver2.168.1.47,
rootpath=/home/laurent/src/iob/netboot/renesas
[    6.710000]      nameserver02.168.1.47
[    6.720000] SDHI2 Vcc: disabling
[    6.720000] SDHI0 Vcc: disabling
[    6.720000] vccq_mc0: disabling
[    6.730000] ALSA device list:
[    6.730000]   #0: fsia-dai-ak4642-hifi

Quoted 2 lines

and then oopses after a timeout. No NFS-related packet is received by the host according to tcpdump.

Strange, my WIP should work for kzm9g-legacy and kzm9g-multiplatform.

Quoted 20 lines · Geert Uytterhoeven

Quoted 20 lines

Any idea why NFS root doesn't work with your wip branch and shmobile_defconfig (with NFSv4 and NFSv3 ACL disabled) ? The kernel stops after

[    6.630000] Sending DHCP requests ., OK
[    6.670000] IP-Config: Got DHCP answer from 192.168.1.47, my address
is 192.168.1.254
[    6.680000] IP-Config: Complete:
[    6.690000]      device=eth0, hwaddr:01:9b:04:04:22,
ipaddr2.168.1.254, mask%5.255.255.0, gw%5.255.255.255
[    6.700000]      host2.168.1.254, domain=, nis-domain=(none)
[    6.700000]      bootserver2.168.1.47, rootserver2.168.1.47,
rootpath=/home/laurent/src/iob/netboot/renesas
[    6.710000]      nameserver02.168.1.47
[    6.720000] SDHI2 Vcc: disabling
[    6.720000] SDHI0 Vcc: disabling
[    6.720000] vccq_mc0: disabling
[    6.730000] ALSA device list:
[    6.730000]   #0: fsia-dai-ak4642-hifi

Quoted 4 lines

Quoted 2 lines

and then oopses after a timeout. No NFS-related packet is received by the host according to tcpdump.

Strange, my WIP should work for kzm9g-legacy and kzm9g-multiplatform.

Sorry, I missed that you're using shmobile_defconfig. That may indeed fail. Does it have CONFIG_RENESAS_BSC=y?

From: Magnus Damm <[email protected]>

Adjust the load address for the KZM9G DT reference case to make it compatible with upcoming sh73a0 Multiplatform and CONFIG_AUTO_ZRELADDR=y.

Without the not-yet-merged sh73a0 multiplatform support the KZM9G uImage can be built without any special care, but once we go DTS-only then the Makefile.boot entry will disappear and the Multiplatform image will be built using CONFIG_AUTO_ZRELADDR=y. To generate an uImage for KZM9G the following example can be followed:

$ make ARCH=arm LOADADDR=0x48008000 uImage

For now simply adjust the non-multiplatform KZM9G DT reference implementation to be compatible with ZRELADDR.

Signed-off-by Magnus Damm <[email protected]>

---

Quoted 15 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Adjust the load address for the KZM9G DT reference case to make it compatible with upcoming sh73a0 Multiplatform and CONFIG_AUTO_ZRELADDR=y.

Without the not-yet-merged sh73a0 multiplatform support the KZM9G uImage can be built without any special care, but once we go DTS-only then the Makefile.boot entry will disappear and the Multiplatform image will be built using CONFIG_AUTO_ZRELADDR=y. To generate an uImage for KZM9G the following example can be followed:

$ make ARCH=arm LOADADDR=0x48008000 uImage

Quoted 5 lines

For now simply adjust the non-multiplatform KZM9G DT reference implementation to be compatible with ZRELADDR.

Signed-off-by Magnus Damm <[email protected]>

---

Simon, this seems to work for both Geert and Laurent. Can you please pick up?

Quoted 19 lines · Magnus Damm

Quoted 18 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Adjust the load address for the KZM9G DT reference case to make it compatible with upcoming sh73a0 Multiplatform and CONFIG_AUTO_ZRELADDR=y.

Without the not-yet-merged sh73a0 multiplatform support the KZM9G uImage can be built without any special care, but once we go DTS-only then the Makefile.boot entry will disappear and the Multiplatform image will be built using CONFIG_AUTO_ZRELADDR=y. To generate an uImage for KZM9G the following example can be followed:

$ make ARCH=arm LOADADDR=0x48008000 uImage

For now simply adjust the non-multiplatform KZM9G DT reference implementation to be compatible with ZRELADDR.

Quoted 4 lines

Quoted 2 lines

Signed-off-by Magnus Damm <[email protected]>

---

Simon, this seems to work for both Geert and Laurent. Can you please pick up?

I really don't like losing 25% of RAM...

Quoted 1 line

I really don't like losing 25% of RAM...

Sure, so the ARM arch needs to be beaten into shape somehow. =)

But compared to before we can at least boot multiplatform.

Hi Magnus,

Quoted 5 lines · Magnus Damm

Quoted 1 line

I really don't like losing 25% of RAM...

Sure, so the ARM arch needs to be beaten into shape somehow. =)

But compared to before we can at least boot multiplatform.

An alternative solution is to change the memory region to include the first 16 MiB of RAM.

Quoted 5 lines · Geert Uytterhoeven

Quoted 4 lines · Magnus Damm

Quoted 1 line

I really don't like losing 25% of RAM...

Sure, so the ARM arch needs to be beaten into shape somehow. =)

Quoted 4 lines

Quoted 1 line

But compared to before we can at least boot multiplatform.

An alternative solution is to change the memory region to include the first 16 MiB of RAM.

If that is possible then sure! I however always assumed that part of the memory is reserved due to the SH core (or some other piece of hardware) is using for other purposes.

Hi Simon,

Quoted 15 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Adjust the load address for the KZM9G DT reference case to make it compatible with upcoming sh73a0 Multiplatform and CONFIG_AUTO_ZRELADDR=y.

Without the not-yet-merged sh73a0 multiplatform support the KZM9G uImage can be built without any special care, but once we go DTS-only then the Makefile.boot entry will disappear and the Multiplatform image will be built using CONFIG_AUTO_ZRELADDR=y. To generate an uImage for KZM9G the following example can be followed:

$ make ARCH=arm LOADADDR=0x48008000 uImage

Quoted 5 lines

For now simply adjust the non-multiplatform KZM9G DT reference implementation to be compatible with ZRELADDR.

Signed-off-by Magnus Damm <[email protected]>

---

Simon, this seems to work for both Geert and Laurent. Can you please pick up?