Hi Vagrant,

Thanks very much for finding the time to look at this.


>Mixed feelings. It is getting pretty late in the release cycle, and the
>current code basically works and diverges less from code that has been
>there for a long time...

It does work, but in eleven cases (i.e. on the arm64 boards) I think it
diverges from the upstream practice for installing U-Boot on sunxi,
which I believe has always been to simply write
u-boot-sunxi-with-spl.bin at offset 8K.

Instead it writes two files at offsets 8K and 40K respectively. This
achieves an equivalent result, because in all eleven cases the first
file is identical to the first 32K of u-boot-sunxi-with-spl.bin, and the
second file is effectively the same as the 32K-onwards segment of
u-boot-sunxi-with-spl.bin (differing only by a timestamp).

The coming trouble is that the next release of U-Boot (in April) will
support boards such as the Orange Pi Zero 2 where the SPL is bigger than
32K (see upstream commit c0b417b2f1, "sunxi: support loading with SPL >
32KB"). The build process will concatenate the SPL and the FIT image to
produce u-boot-sunxi-with-spl.bin as usual, so installing that at 8K
should still work, but the method used by the Debian script will fail in
that case.


>[...]
>One small downside is this won't support installing the old-style
>u-boot.itb, as that required installing the SPL and .itb file separately
>at different offsets. I actually use this functionality pretty often to
>downgrade to an older version of u-boot when something goes wrong with a
>newer version.

Can you give an example of a board which needs that? I think the build
process for sunxi boards always produces a u-boot-sunxi-with-spl.bin, so
if we ever need to downgrade it, can't we just downgrade to the previous
u-boot-sunxi-with-spl.bin? If we want to use a U-Boot from an older
u-boot-sunxi package that only has the separated files, as in buster for
example, then the required script for handling those files is provided
in that same package.


>[...]
>https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/
>
>I suspect (though haven't confirmed) that installing the image directly
>to the SPL load address might clobber the rockchip images... woudn't
>want to block it for that reason alone, as it is not yet a widly used
>use-case.

I remember that talk; it would be great to have a universal boot SDcard
or at least more universal than what there is now. But just to clarify,
in this bug report I'm only proposing simplifying the way the
u-boot-sunxi package handles arm64 boards. If my patch was applied, it
wouldn't result in anything different ending up on the SDcard (apart
from a timestamp), it would just simplify the way it's done.


>I think it might be best at this point to only merge the added platforms
>and the other bugfix you reported in Bug#982278.

I'll file separate bugs for the other minor suggestions I mentioned
earlier.


>Thanks for your work on all this!

I'm happy to contribute; after all, Debian maintainers haven't got time
to do everything yourselves..

Thanks a lot,
Harold.

Reply via email to