U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] board: rpi: Update memory layout for Aarch64
@ 2024-07-16 17:16 Walter Lozano
  2024-07-16 17:21 ` Tom Rini
  0 siblings, 1 reply; 6+ messages in thread
From: Walter Lozano @ 2024-07-16 17:16 UTC (permalink / raw)
  To: u-boot, Martyn Welch
  Cc: Walter Lozano, Matthias Brugger, Peter Robinson, Simon Glass,
	Tom Rini

ARM and Aarch64 have different restrictions and trying to accommodate
larger kernels like the ones used in distros can be challenging. For this
reason, separate the layout and rearrange the map for Aarch64 to support
kernels larger than 36 MB.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
---

 board/raspberrypi/rpi/rpi.env | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
index 30228285edd..37c7f6a920e 100644
--- a/board/raspberrypi/rpi/rpi.env
+++ b/board/raspberrypi/rpi/rpi.env
@@ -42,13 +42,19 @@ dfu_alt_info+=zImage fat 0 1
  *   For Aarch64, the kernel image is uncompressed and must be loaded at
  *   text_offset bytes (specified in the header of the Image) into a 2MB
  *   boundary. The 'booti' command relocates the image if necessary. Linux uses
- *   a default text_offset of 0x80000.  In summary, loading at 0x80000
- *   satisfies all these constraints and reserving memory up to 0x02400000
- *   permits fairly large (roughly 36M) kernels.
+ *   a default text_offset of 0x80000.  However, loading it at 0x80000
+ *   will allow to reserve only up to 0x02400000 which permits medium size
+ *   kernels (roughly 36M). This is good enough for customized kernels but
+ *   not for distros which by default enable drivers for many different
+ *   boards. Under these circumstances, using 0x00200000 provides room for
+ *   larger kernels.
  *
  * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
  * conflict with something else. Reserving 1M for each of them at
- * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty.
+ * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty for ARM.
+ *
+ *   For Aarch64, since the kernel is placed in different location,
+ *   accommodate them to reserver 1M for each of them.
  *
  * On ARM, both the DTB and any possible initrd must be loaded such that they
  * fit inside the lowmem mapping in Linux. In practice, this usually means not
@@ -62,16 +68,21 @@ dfu_alt_info+=zImage fat 0 1
  * large initrds before they start colliding with U-Boot.
  */
 #ifdef CONFIG_ARM64
+pxefile_addr_r=0x00080000
+scriptaddr=0x00100000
+kernel_addr_r=0x00200000
+fdt_addr_r=0x03400000
+ramdisk_addr_r=0x03500000
 fdt_high=ffffffffffffffff
 initrd_high=ffffffffffffffff
 #else
-fdt_high=ffffffff
-initrd_high=ffffffff
-#endif
 kernel_addr_r=0x00080000
 scriptaddr=0x02400000
 pxefile_addr_r=0x02500000
 fdt_addr_r=0x02600000
 ramdisk_addr_r=0x02700000
+fdt_high=ffffffff
+initrd_high=ffffffff
+#endif
 
 boot_targets=mmc usb pxe dhcp
-- 
2.40.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] board: rpi: Update memory layout for Aarch64
  2024-07-16 17:16 [PATCH] board: rpi: Update memory layout for Aarch64 Walter Lozano
@ 2024-07-16 17:21 ` Tom Rini
  2024-07-17 10:59   ` Peter Robinson
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2024-07-16 17:21 UTC (permalink / raw)
  To: Walter Lozano
  Cc: u-boot, Martyn Welch, Matthias Brugger, Peter Robinson,
	Simon Glass

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

On Tue, Jul 16, 2024 at 02:16:02PM -0300, Walter Lozano wrote:

> ARM and Aarch64 have different restrictions and trying to accommodate
> larger kernels like the ones used in distros can be challenging. For this
> reason, separate the layout and rearrange the map for Aarch64 to support
> kernels larger than 36 MB.
> 
> Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
> ---
> 
>  board/raspberrypi/rpi/rpi.env | 25 ++++++++++++++++++-------
>  1 file changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
> index 30228285edd..37c7f6a920e 100644
> --- a/board/raspberrypi/rpi/rpi.env
> +++ b/board/raspberrypi/rpi/rpi.env
> @@ -42,13 +42,19 @@ dfu_alt_info+=zImage fat 0 1
>   *   For Aarch64, the kernel image is uncompressed and must be loaded at
>   *   text_offset bytes (specified in the header of the Image) into a 2MB
>   *   boundary. The 'booti' command relocates the image if necessary. Linux uses
> - *   a default text_offset of 0x80000.  In summary, loading at 0x80000
> - *   satisfies all these constraints and reserving memory up to 0x02400000
> - *   permits fairly large (roughly 36M) kernels.
> + *   a default text_offset of 0x80000.  However, loading it at 0x80000
> + *   will allow to reserve only up to 0x02400000 which permits medium size
> + *   kernels (roughly 36M). This is good enough for customized kernels but
> + *   not for distros which by default enable drivers for many different
> + *   boards. Under these circumstances, using 0x00200000 provides room for
> + *   larger kernels.
>   *
>   * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
>   * conflict with something else. Reserving 1M for each of them at
> - * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty.
> + * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty for ARM.
> + *
> + *   For Aarch64, since the kernel is placed in different location,
> + *   accommodate them to reserver 1M for each of them.
>   *
>   * On ARM, both the DTB and any possible initrd must be loaded such that they
>   * fit inside the lowmem mapping in Linux. In practice, this usually means not
> @@ -62,16 +68,21 @@ dfu_alt_info+=zImage fat 0 1
>   * large initrds before they start colliding with U-Boot.
>   */
>  #ifdef CONFIG_ARM64
> +pxefile_addr_r=0x00080000
> +scriptaddr=0x00100000
> +kernel_addr_r=0x00200000
> +fdt_addr_r=0x03400000
> +ramdisk_addr_r=0x03500000
>  fdt_high=ffffffffffffffff
>  initrd_high=ffffffffffffffff
>  #else
> -fdt_high=ffffffff
> -initrd_high=ffffffff
> -#endif
>  kernel_addr_r=0x00080000
>  scriptaddr=0x02400000
>  pxefile_addr_r=0x02500000
>  fdt_addr_r=0x02600000
>  ramdisk_addr_r=0x02700000
> +fdt_high=ffffffff
> +initrd_high=ffffffff
> +#endif
>  
>  boot_targets=mmc usb pxe dhcp

We need to drop the disabling of device tree / initrd relocation as
that's sure not going to help matters. What's the minimum amount of
memory an aarch64 Pi will have? I really prefer reserving 128MiB (even
if that's not the maximum Linux Kernel Image size anymore) and then
device tree and then initrd.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] board: rpi: Update memory layout for Aarch64
  2024-07-16 17:21 ` Tom Rini
@ 2024-07-17 10:59   ` Peter Robinson
  2024-07-17 15:44     ` Tom Rini
  0 siblings, 1 reply; 6+ messages in thread
From: Peter Robinson @ 2024-07-17 10:59 UTC (permalink / raw)
  To: Tom Rini; +Cc: Walter Lozano, u-boot, Martyn Welch, Matthias Brugger,
	Simon Glass

On Tue, 16 Jul 2024 at 18:21, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Jul 16, 2024 at 02:16:02PM -0300, Walter Lozano wrote:
>
> > ARM and Aarch64 have different restrictions and trying to accommodate
> > larger kernels like the ones used in distros can be challenging. For this
> > reason, separate the layout and rearrange the map for Aarch64 to support
> > kernels larger than 36 MB.
> >
> > Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
> > ---
> >
> >  board/raspberrypi/rpi/rpi.env | 25 ++++++++++++++++++-------
> >  1 file changed, 18 insertions(+), 7 deletions(-)
> >
> > diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
> > index 30228285edd..37c7f6a920e 100644
> > --- a/board/raspberrypi/rpi/rpi.env
> > +++ b/board/raspberrypi/rpi/rpi.env
> > @@ -42,13 +42,19 @@ dfu_alt_info+=zImage fat 0 1
> >   *   For Aarch64, the kernel image is uncompressed and must be loaded at
> >   *   text_offset bytes (specified in the header of the Image) into a 2MB
> >   *   boundary. The 'booti' command relocates the image if necessary. Linux uses
> > - *   a default text_offset of 0x80000.  In summary, loading at 0x80000
> > - *   satisfies all these constraints and reserving memory up to 0x02400000
> > - *   permits fairly large (roughly 36M) kernels.
> > + *   a default text_offset of 0x80000.  However, loading it at 0x80000
> > + *   will allow to reserve only up to 0x02400000 which permits medium size
> > + *   kernels (roughly 36M). This is good enough for customized kernels but
> > + *   not for distros which by default enable drivers for many different
> > + *   boards. Under these circumstances, using 0x00200000 provides room for
> > + *   larger kernels.
> >   *
> >   * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
> >   * conflict with something else. Reserving 1M for each of them at
> > - * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty.
> > + * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty for ARM.
> > + *
> > + *   For Aarch64, since the kernel is placed in different location,
> > + *   accommodate them to reserver 1M for each of them.
> >   *
> >   * On ARM, both the DTB and any possible initrd must be loaded such that they
> >   * fit inside the lowmem mapping in Linux. In practice, this usually means not
> > @@ -62,16 +68,21 @@ dfu_alt_info+=zImage fat 0 1
> >   * large initrds before they start colliding with U-Boot.
> >   */
> >  #ifdef CONFIG_ARM64
> > +pxefile_addr_r=0x00080000
> > +scriptaddr=0x00100000
> > +kernel_addr_r=0x00200000
> > +fdt_addr_r=0x03400000
> > +ramdisk_addr_r=0x03500000
> >  fdt_high=ffffffffffffffff
> >  initrd_high=ffffffffffffffff
> >  #else
> > -fdt_high=ffffffff
> > -initrd_high=ffffffff
> > -#endif
> >  kernel_addr_r=0x00080000
> >  scriptaddr=0x02400000
> >  pxefile_addr_r=0x02500000
> >  fdt_addr_r=0x02600000
> >  ramdisk_addr_r=0x02700000
> > +fdt_high=ffffffff
> > +initrd_high=ffffffff
> > +#endif
> >
> >  boot_targets=mmc usb pxe dhcp
>
> We need to drop the disabling of device tree / initrd relocation as
> that's sure not going to help matters. What's the minimum amount of
> memory an aarch64 Pi will have? I really prefer reserving 128MiB (even
> if that's not the maximum Linux Kernel Image size anymore) and then
> device tree and then initrd.

512Mb on the Zero2W and RPi3A.

We've not seen an issue here on the very large Fedora kernel, but I
suspect that's because using UEFI mitigates this somewhat because here
we're actually loading shim/grub.

Peter

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] board: rpi: Update memory layout for Aarch64
  2024-07-17 10:59   ` Peter Robinson
@ 2024-07-17 15:44     ` Tom Rini
  2024-07-17 18:32       ` Walter Lozano
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2024-07-17 15:44 UTC (permalink / raw)
  To: Peter Robinson
  Cc: Walter Lozano, u-boot, Martyn Welch, Matthias Brugger,
	Simon Glass

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

On Wed, Jul 17, 2024 at 11:59:50AM +0100, Peter Robinson wrote:
> On Tue, 16 Jul 2024 at 18:21, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Jul 16, 2024 at 02:16:02PM -0300, Walter Lozano wrote:
> >
> > > ARM and Aarch64 have different restrictions and trying to accommodate
> > > larger kernels like the ones used in distros can be challenging. For this
> > > reason, separate the layout and rearrange the map for Aarch64 to support
> > > kernels larger than 36 MB.
> > >
> > > Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
> > > ---
> > >
> > >  board/raspberrypi/rpi/rpi.env | 25 ++++++++++++++++++-------
> > >  1 file changed, 18 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
> > > index 30228285edd..37c7f6a920e 100644
> > > --- a/board/raspberrypi/rpi/rpi.env
> > > +++ b/board/raspberrypi/rpi/rpi.env
> > > @@ -42,13 +42,19 @@ dfu_alt_info+=zImage fat 0 1
> > >   *   For Aarch64, the kernel image is uncompressed and must be loaded at
> > >   *   text_offset bytes (specified in the header of the Image) into a 2MB
> > >   *   boundary. The 'booti' command relocates the image if necessary. Linux uses
> > > - *   a default text_offset of 0x80000.  In summary, loading at 0x80000
> > > - *   satisfies all these constraints and reserving memory up to 0x02400000
> > > - *   permits fairly large (roughly 36M) kernels.
> > > + *   a default text_offset of 0x80000.  However, loading it at 0x80000
> > > + *   will allow to reserve only up to 0x02400000 which permits medium size
> > > + *   kernels (roughly 36M). This is good enough for customized kernels but
> > > + *   not for distros which by default enable drivers for many different
> > > + *   boards. Under these circumstances, using 0x00200000 provides room for
> > > + *   larger kernels.
> > >   *
> > >   * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
> > >   * conflict with something else. Reserving 1M for each of them at
> > > - * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty.
> > > + * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty for ARM.
> > > + *
> > > + *   For Aarch64, since the kernel is placed in different location,
> > > + *   accommodate them to reserver 1M for each of them.
> > >   *
> > >   * On ARM, both the DTB and any possible initrd must be loaded such that they
> > >   * fit inside the lowmem mapping in Linux. In practice, this usually means not
> > > @@ -62,16 +68,21 @@ dfu_alt_info+=zImage fat 0 1
> > >   * large initrds before they start colliding with U-Boot.
> > >   */
> > >  #ifdef CONFIG_ARM64
> > > +pxefile_addr_r=0x00080000
> > > +scriptaddr=0x00100000
> > > +kernel_addr_r=0x00200000
> > > +fdt_addr_r=0x03400000
> > > +ramdisk_addr_r=0x03500000
> > >  fdt_high=ffffffffffffffff
> > >  initrd_high=ffffffffffffffff
> > >  #else
> > > -fdt_high=ffffffff
> > > -initrd_high=ffffffff
> > > -#endif
> > >  kernel_addr_r=0x00080000
> > >  scriptaddr=0x02400000
> > >  pxefile_addr_r=0x02500000
> > >  fdt_addr_r=0x02600000
> > >  ramdisk_addr_r=0x02700000
> > > +fdt_high=ffffffff
> > > +initrd_high=ffffffff
> > > +#endif
> > >
> > >  boot_targets=mmc usb pxe dhcp
> >
> > We need to drop the disabling of device tree / initrd relocation as
> > that's sure not going to help matters. What's the minimum amount of
> > memory an aarch64 Pi will have? I really prefer reserving 128MiB (even
> > if that's not the maximum Linux Kernel Image size anymore) and then
> > device tree and then initrd.
> 
> 512Mb on the Zero2W and RPi3A.
> 
> We've not seen an issue here on the very large Fedora kernel, but I
> suspect that's because using UEFI mitigates this somewhat because here
> we're actually loading shim/grub.

OK, that should be enough to put a 128MiB spot for kernel, then 512KiB
for device tree, and then rest for initrd, and not be disabling
relocation (and thus preventing U-Boot from fixing failures).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] board: rpi: Update memory layout for Aarch64
  2024-07-17 15:44     ` Tom Rini
@ 2024-07-17 18:32       ` Walter Lozano
  2024-07-18 13:52         ` Tom Rini
  0 siblings, 1 reply; 6+ messages in thread
From: Walter Lozano @ 2024-07-17 18:32 UTC (permalink / raw)
  To: Tom Rini, Peter Robinson
  Cc: u-boot, Martyn Welch, Matthias Brugger, Simon Glass



On 7/17/24 12:44, Tom Rini wrote:
> On Wed, Jul 17, 2024 at 11:59:50AM +0100, Peter Robinson wrote:
>> On Tue, 16 Jul 2024 at 18:21, Tom Rini <trini@konsulko.com> wrote:
>>>
>>> On Tue, Jul 16, 2024 at 02:16:02PM -0300, Walter Lozano wrote:
>>>
>>>> ARM and Aarch64 have different restrictions and trying to accommodate
>>>> larger kernels like the ones used in distros can be challenging. For this
>>>> reason, separate the layout and rearrange the map for Aarch64 to support
>>>> kernels larger than 36 MB.
>>>>
>>>> Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
>>>> ---
>>>>
>>>>   board/raspberrypi/rpi/rpi.env | 25 ++++++++++++++++++-------
>>>>   1 file changed, 18 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
>>>> index 30228285edd..37c7f6a920e 100644
>>>> --- a/board/raspberrypi/rpi/rpi.env
>>>> +++ b/board/raspberrypi/rpi/rpi.env
>>>> @@ -42,13 +42,19 @@ dfu_alt_info+=zImage fat 0 1
>>>>    *   For Aarch64, the kernel image is uncompressed and must be loaded at
>>>>    *   text_offset bytes (specified in the header of the Image) into a 2MB
>>>>    *   boundary. The 'booti' command relocates the image if necessary. Linux uses
>>>> - *   a default text_offset of 0x80000.  In summary, loading at 0x80000
>>>> - *   satisfies all these constraints and reserving memory up to 0x02400000
>>>> - *   permits fairly large (roughly 36M) kernels.
>>>> + *   a default text_offset of 0x80000.  However, loading it at 0x80000
>>>> + *   will allow to reserve only up to 0x02400000 which permits medium size
>>>> + *   kernels (roughly 36M). This is good enough for customized kernels but
>>>> + *   not for distros which by default enable drivers for many different
>>>> + *   boards. Under these circumstances, using 0x00200000 provides room for
>>>> + *   larger kernels.
>>>>    *
>>>>    * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
>>>>    * conflict with something else. Reserving 1M for each of them at
>>>> - * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty.
>>>> + * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty for ARM.
>>>> + *
>>>> + *   For Aarch64, since the kernel is placed in different location,
>>>> + *   accommodate them to reserver 1M for each of them.
>>>>    *
>>>>    * On ARM, both the DTB and any possible initrd must be loaded such that they
>>>>    * fit inside the lowmem mapping in Linux. In practice, this usually means not
>>>> @@ -62,16 +68,21 @@ dfu_alt_info+=zImage fat 0 1
>>>>    * large initrds before they start colliding with U-Boot.
>>>>    */
>>>>   #ifdef CONFIG_ARM64
>>>> +pxefile_addr_r=0x00080000
>>>> +scriptaddr=0x00100000
>>>> +kernel_addr_r=0x00200000
>>>> +fdt_addr_r=0x03400000
>>>> +ramdisk_addr_r=0x03500000
>>>>   fdt_high=ffffffffffffffff
>>>>   initrd_high=ffffffffffffffff
>>>>   #else
>>>> -fdt_high=ffffffff
>>>> -initrd_high=ffffffff
>>>> -#endif
>>>>   kernel_addr_r=0x00080000
>>>>   scriptaddr=0x02400000
>>>>   pxefile_addr_r=0x02500000
>>>>   fdt_addr_r=0x02600000
>>>>   ramdisk_addr_r=0x02700000
>>>> +fdt_high=ffffffff
>>>> +initrd_high=ffffffff
>>>> +#endif
>>>>
>>>>   boot_targets=mmc usb pxe dhcp
>>>
>>> We need to drop the disabling of device tree / initrd relocation as
>>> that's sure not going to help matters. What's the minimum amount of
>>> memory an aarch64 Pi will have? I really prefer reserving 128MiB (even
>>> if that's not the maximum Linux Kernel Image size anymore) and then
>>> device tree and then initrd.
>>
>> 512Mb on the Zero2W and RPi3A.
>>
>> We've not seen an issue here on the very large Fedora kernel, but I
>> suspect that's because using UEFI mitigates this somewhat because here
>> we're actually loading shim/grub.
> 
> OK, that should be enough to put a 128MiB spot for kernel, then 512KiB
> for device tree, and then rest for initrd, and not be disabling
> relocation (and thus preventing U-Boot from fixing failures).
> 

Thanks for the feedback! If I understood it correctly a layout like the
the one bellow would be the right thing. The only difference is in
device tree for which is reserved a bit more.

pxefile_addr_r=0x00080000
scriptaddr=0x00100000
kernel_addr_r=0x00200000
fdt_addr_r=0x09800000
ramdisk_addr_r=0x09900000

If this matches the expectations I will prepare the V2.

Thanks in advance,

Walter

-- 
Walter Lozano
Collabora Ltd.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] board: rpi: Update memory layout for Aarch64
  2024-07-17 18:32       ` Walter Lozano
@ 2024-07-18 13:52         ` Tom Rini
  0 siblings, 0 replies; 6+ messages in thread
From: Tom Rini @ 2024-07-18 13:52 UTC (permalink / raw)
  To: Walter Lozano
  Cc: Peter Robinson, u-boot, Martyn Welch, Matthias Brugger,
	Simon Glass

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

On Wed, Jul 17, 2024 at 03:32:00PM -0300, Walter Lozano wrote:
> 
> 
> On 7/17/24 12:44, Tom Rini wrote:
> > On Wed, Jul 17, 2024 at 11:59:50AM +0100, Peter Robinson wrote:
> > > On Tue, 16 Jul 2024 at 18:21, Tom Rini <trini@konsulko.com> wrote:
> > > > 
> > > > On Tue, Jul 16, 2024 at 02:16:02PM -0300, Walter Lozano wrote:
> > > > 
> > > > > ARM and Aarch64 have different restrictions and trying to accommodate
> > > > > larger kernels like the ones used in distros can be challenging. For this
> > > > > reason, separate the layout and rearrange the map for Aarch64 to support
> > > > > kernels larger than 36 MB.
> > > > > 
> > > > > Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
> > > > > ---
> > > > > 
> > > > >   board/raspberrypi/rpi/rpi.env | 25 ++++++++++++++++++-------
> > > > >   1 file changed, 18 insertions(+), 7 deletions(-)
> > > > > 
> > > > > diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
> > > > > index 30228285edd..37c7f6a920e 100644
> > > > > --- a/board/raspberrypi/rpi/rpi.env
> > > > > +++ b/board/raspberrypi/rpi/rpi.env
> > > > > @@ -42,13 +42,19 @@ dfu_alt_info+=zImage fat 0 1
> > > > >    *   For Aarch64, the kernel image is uncompressed and must be loaded at
> > > > >    *   text_offset bytes (specified in the header of the Image) into a 2MB
> > > > >    *   boundary. The 'booti' command relocates the image if necessary. Linux uses
> > > > > - *   a default text_offset of 0x80000.  In summary, loading at 0x80000
> > > > > - *   satisfies all these constraints and reserving memory up to 0x02400000
> > > > > - *   permits fairly large (roughly 36M) kernels.
> > > > > + *   a default text_offset of 0x80000.  However, loading it at 0x80000
> > > > > + *   will allow to reserve only up to 0x02400000 which permits medium size
> > > > > + *   kernels (roughly 36M). This is good enough for customized kernels but
> > > > > + *   not for distros which by default enable drivers for many different
> > > > > + *   boards. Under these circumstances, using 0x00200000 provides room for
> > > > > + *   larger kernels.
> > > > >    *
> > > > >    * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
> > > > >    * conflict with something else. Reserving 1M for each of them at
> > > > > - * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty.
> > > > > + * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty for ARM.
> > > > > + *
> > > > > + *   For Aarch64, since the kernel is placed in different location,
> > > > > + *   accommodate them to reserver 1M for each of them.
> > > > >    *
> > > > >    * On ARM, both the DTB and any possible initrd must be loaded such that they
> > > > >    * fit inside the lowmem mapping in Linux. In practice, this usually means not
> > > > > @@ -62,16 +68,21 @@ dfu_alt_info+=zImage fat 0 1
> > > > >    * large initrds before they start colliding with U-Boot.
> > > > >    */
> > > > >   #ifdef CONFIG_ARM64
> > > > > +pxefile_addr_r=0x00080000
> > > > > +scriptaddr=0x00100000
> > > > > +kernel_addr_r=0x00200000
> > > > > +fdt_addr_r=0x03400000
> > > > > +ramdisk_addr_r=0x03500000
> > > > >   fdt_high=ffffffffffffffff
> > > > >   initrd_high=ffffffffffffffff
> > > > >   #else
> > > > > -fdt_high=ffffffff
> > > > > -initrd_high=ffffffff
> > > > > -#endif
> > > > >   kernel_addr_r=0x00080000
> > > > >   scriptaddr=0x02400000
> > > > >   pxefile_addr_r=0x02500000
> > > > >   fdt_addr_r=0x02600000
> > > > >   ramdisk_addr_r=0x02700000
> > > > > +fdt_high=ffffffff
> > > > > +initrd_high=ffffffff
> > > > > +#endif
> > > > > 
> > > > >   boot_targets=mmc usb pxe dhcp
> > > > 
> > > > We need to drop the disabling of device tree / initrd relocation as
> > > > that's sure not going to help matters. What's the minimum amount of
> > > > memory an aarch64 Pi will have? I really prefer reserving 128MiB (even
> > > > if that's not the maximum Linux Kernel Image size anymore) and then
> > > > device tree and then initrd.
> > > 
> > > 512Mb on the Zero2W and RPi3A.
> > > 
> > > We've not seen an issue here on the very large Fedora kernel, but I
> > > suspect that's because using UEFI mitigates this somewhat because here
> > > we're actually loading shim/grub.
> > 
> > OK, that should be enough to put a 128MiB spot for kernel, then 512KiB
> > for device tree, and then rest for initrd, and not be disabling
> > relocation (and thus preventing U-Boot from fixing failures).
> > 
> 
> Thanks for the feedback! If I understood it correctly a layout like the
> the one bellow would be the right thing. The only difference is in
> device tree for which is reserved a bit more.
> 
> pxefile_addr_r=0x00080000
> scriptaddr=0x00100000
> kernel_addr_r=0x00200000
> fdt_addr_r=0x09800000
> ramdisk_addr_r=0x09900000
> 
> If this matches the expectations I will prepare the V2.

Looks right to me, Peter or Matthias ? Thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-07-18 13:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-16 17:16 [PATCH] board: rpi: Update memory layout for Aarch64 Walter Lozano
2024-07-16 17:21 ` Tom Rini
2024-07-17 10:59   ` Peter Robinson
2024-07-17 15:44     ` Tom Rini
2024-07-17 18:32       ` Walter Lozano
2024-07-18 13:52         ` Tom Rini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox