[PATCH 1/2] sunxi: allow bigger images for all

[PATCH 1/2] sunxi: allow bigger images for all

[Karl Palsson]

No reason to limit bigger images to 64bit targets, it's quite easy to go
over the limit with a kernel+initramfs

Signed-off-by: Karl Palsson <karlp@tweak.net.au>
---
 include/configs/sunxi-common.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 0ef289fd64..ef5b1d866e 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -31,9 +31,7 @@
 # define CONFIG_MACH_TYPE_COMPAT_REV	1
 #endif
 
-#ifdef CONFIG_ARM64
 #define CONFIG_SYS_BOOTM_LEN		(32 << 20)
-#endif
 
 /* Serial & console */
 #define CONFIG_SYS_NS16550_SERIAL
-- 
2.21.1

[PATCH 2/2] sunxi: defconfig for FriendlyArm nanopi-duo2

[Karl Palsson]

Nothing standout, but provide a defconfig that matches the dts available
for this board. Effectively identical to the nanopi_neo_air.

Signed-off-by: Karl Palsson <karlp@tweak.net.au>
---
 configs/nanopi_duo2_defconfig | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 configs/nanopi_duo2_defconfig

diff --git a/configs/nanopi_duo2_defconfig b/configs/nanopi_duo2_defconfig
new file mode 100644
index 0000000000..e81141fa0d
--- /dev/null
+++ b/configs/nanopi_duo2_defconfig
@@ -0,0 +1,11 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_SPL=y
+CONFIG_MACH_SUN8I_H3=y
+CONFIG_DRAM_CLK=408
+# CONFIG_VIDEO_DE2 is not set
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_CONSOLE_MUX=y
+CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-nanopi-duo2"
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
-- 
2.21.1

[PATCH 1/2] sunxi: allow bigger images for all

[Maxime Ripard]

Hi,

On Mon, Apr 06, 2020 at 03:51:39PM +0000, Karl Palsson wrote:
> No reason to limit bigger images to 64bit targets, it's quite easy
> to go over the limit with a kernel+initramfs

There's a reason: we support some boards with 32 and 64MB of RAM.

It would obviously not fit with 32MB boards, and I'm pretty sure it
wouldn't with 64MB either.

It would make more sense to put that in Kconfig so that boards that
need less have a chance at setting a lower limit, just like
FASTBOOT_BUF_SIZE

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200406/e7f98950/attachment.sig>

[PATCH 1/2] sunxi: allow bigger images for all

[Karl Palsson]

Maxime Ripard <maxime@cerno.tech> wrote:
> Hi,
> 
> On Mon, Apr 06, 2020 at 03:51:39PM +0000, Karl Palsson wrote:
> > No reason to limit bigger images to 64bit targets, it's quite easy
> > to go over the limit with a kernel+initramfs
> 
> There's a reason: we support some boards with 32 and 64MB of
> RAM.
> 
> It would obviously not fit with 32MB boards, and I'm pretty
> sure it wouldn't with 64MB either.
> 
> It would make more sense to put that in Kconfig so that boards
> that need less have a chance at setting a lower limit, just
> like FASTBOOT_BUF_SIZE

Well, one difference is that the fastboot buffer is memory that's _used_  the CONFIG_SYS_BOOTM_LEN is just an artificial limit to prevent attempting to boot an image that's "too big" and the limit is fairly arbitrary.  Could it just be removed altogether?  You would "allow" users to run a command that might result in a hang/crash, but right now you need to recompile your bootloader based on this arbitrary fixed number.  

The bootm code already mallocs len * 4, then just artificially
limits it (or changes the error message) based on this
CONFIG_SYS_BOOTM_LEN.

```
       /* Allow the image to expand by a factor of 4, should be safe */
        load_buf = malloc((1 << 20) + len * 4);
        ret = image_decomp(imape_comp, 0, data, image_type, load_buf,
                           (void *)data, len, CONFIG_SYS_BOOTM_LEN,
                           &load_end);
```

Sincerely,
Karl Palsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP-digital-signature.html
Type: application/pgp-signature
Size: 1175 bytes
Desc: OpenPGP Digital Signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200406/c8877b32/attachment-0001.sig>

[PATCH 1/2] sunxi: allow bigger images for all

[Maxime Ripard]

On Mon, Apr 06, 2020 at 08:24:26PM -0000, Karl Palsson wrote:
>
> Maxime Ripard <maxime@cerno.tech> wrote:
> > Hi,
> >
> > On Mon, Apr 06, 2020 at 03:51:39PM +0000, Karl Palsson wrote:
> > > No reason to limit bigger images to 64bit targets, it's quite easy
> > > to go over the limit with a kernel+initramfs
> >
> > There's a reason: we support some boards with 32 and 64MB of
> > RAM.
> >
> > It would obviously not fit with 32MB boards, and I'm pretty
> > sure it wouldn't with 64MB either.
> >
> > It would make more sense to put that in Kconfig so that boards
> > that need less have a chance at setting a lower limit, just
> > like FASTBOOT_BUF_SIZE
>
> Well, one difference is that the fastboot buffer is memory that's
> _used_ the CONFIG_SYS_BOOTM_LEN is just an artificial limit to
> prevent attempting to boot an image that's "too big" and the limit
> is fairly arbitrary.

There's really no difference with FASTBOOT_BUF_SIZE. It's a limit to
prevent getting an image that's too big, the limit is fairly
arbitrary, and if it's smaller it's not going to use all of it.

> Could it just be removed altogether?

Not really, unfortunately.

> You would "allow" users to run a command that might result in a
> hang/crash

And that's a pretty big deal? Especially since, if you're using a
distro, the kernel size might very well go past the tipping point
without you noticing at all?

> but right now you need to recompile your bootloader based on this
> arbitrary fixed number.
>
> The bootm code already mallocs len * 4, then just artificially
> limits it (or changes the error message) based on this
> CONFIG_SYS_BOOTM_LEN.

Look, I don't really want to argue about this. I gave you a way
forward that would accomodate every one and would allow people with
different expectations to change it to their own arbitrary limit
easily. If you don't want to do it, fine, but this patch is not a
solution either.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200407/22f0c74e/attachment.sig>

[PATCH 2/2] sunxi: defconfig for FriendlyArm nanopi-duo2

[Jagan Teki]

On Mon, Apr 6, 2020 at 9:21 PM Karl Palsson <karlp@tweak.net.au> wrote:
>
> Nothing standout, but provide a defconfig that matches the dts available
> for this board. Effectively identical to the nanopi_neo_air.
>
> Signed-off-by: Karl Palsson <karlp@tweak.net.au>
> ---

Applied to u-boot-sunx/master