Bug#928643: u-boot-sunxi: Allow u-boot-install-sunxi on GPT

2023-12-03 Thread harry88 
On 2019-05-08 07:34 UTC, Domenico Andreoli wrote:
> Salsa MR #6 adds support for GPT partition tables with up to 4 entries
> to u-boot-install-sunxi64.


Hi Domenico and Vagrant,

I was interested in this idea so I found the patch on salsa:

--- a/debian/bin/u-boot-install-sunxi64
+++ b/debian/bin/u-boot-install-sunxi64
@@ -69,11 +69,22 @@ if [ -z "$FORCE" ]; then
exit 1
 fi

-# But, on sunxi64, spl will trample upon GPT.
+# But, on sunxi64, spl will trample upon GPT (except when the number of 
entries is <= 4)
 printf "EFI PART" >gpt-sign
 if cmp -s -i 0:512 -n 8 gpt-sign "$DEV"; then
-   echo >&2 "$0: device/image ($DEV) uses GPT partition table, unusable on 
sunxi64"
-   exit 1
+GPT_OK=false
+for GPT_ENTRIES in `seq 4`; do
+# Need printf from coreutils so to correctly handle zero bytes
+/usr/bin/printf '%b' "\0$GPT_ENTRIES\0\0\0" >gpt-entries
+if cmp -s -i 0:592 -n 4 gpt-entries "$DEV"; then
+GPT_OK=true
+break
+fi
+done
+if ! $GPT_OK; then
+echo >&2 "$0: device/image ($DEV) uses GPT partition table with 
more than 4 entries, unusable on sunxi64"
+exit 1
+fi
 fi
 fi


I think that as long as the partition entry size is the standard 128 bytes
it's OK to have up to 56 entries, because the total size of MBR + GPT header +
GPT entries still doesn't exceed 8K. u-boot-install-sunxi does already work
with such a GPT if the user specifies the -f option.

But it would be good if the script could support a standard-sized GPT, and a
possible way is suggested by this note in doc/board/allwinner/sunxi.rst:

  The traditional SD card location the Allwinner BootROM loads from is 8KB
  (sector 16). This works fine with the old MBR partitioning scheme, which most
  SD cards come formatted with. However this is in the middle of a potential
  GPT partition table, which will become invalid in this step. Newer SoCs
  (starting with the H3 from late 2014) also support booting from 128KB, which
  is beyond even a GPT and thus a safer location.

So perhaps there could be a new command-line option that made dd write to 128K
instead of 8K, and the error message upon detecting a GPT could suggest using
that option. I've suggested a simple patch below. (It assumes that the GPT
doesn't extend beyond 128K.)

Best wishes,
Harold.

--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -53,14 +53,22 @@ if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
esac
 fi

+wroff="8K"
+while [ -n "$1" ]; do
 case "$1" in
+   -a|--alt-offset)
+   wroff="128K"
+   shift;;
 -f|--force)
FORCE=y
shift;;
 -*)
echo >&2 "$0: unknown option '$1'"
exit 1;;
+   *)
+   break;;
 esac
+done

 DEV="$1"
 if [ -z "$DEV" ] || ! shift || [ -n "$*" ]; then
@@ -87,9 +95,10 @@ if [ -z "$FORCE" ]; then
exit 1
 fi

-# But, on sunxi64, spl will trample upon GPT.
-if printf 'EFI PART' | cmp -s -i 0:512 -n 8 - "$DEV"; then
-   echo >&2 "$0: device/image ($DEV) uses GPT partition table, unusable on 
sunxi64"
+# But writing at offset 8K will trample upon GPT.
+if [ "$wroff" = "8K" ] && printf 'EFI PART' | cmp -s -i 0:512 -n 8 - 
"$DEV"; then
+   echo >&2 "$0: device/image ($DEV) uses GUID partition table"
+   echo >&2 "$0: Use -a to install at alternative offset"
exit 1
 fi
 fi
@@ -100,5 +109,5 @@ if [ ! -f "$imfile" ]; then
 exit 1
 fi

-echo "Writing U-Boot image ${imfile} to ${DEV}"
-dd conv=fsync,notrunc if="$imfile" of="$DEV" bs=8K seek=1
+echo "Writing U-Boot image ${imfile} to ${DEV} at offset ${wroff}"
+dd conv=fsync,notrunc if="$imfile" of="$DEV" bs="$wroff" seek=1
diff --git a/debian/manpages/u-boot-install-sunxi.8 
b/debian/manpages/u-boot-install-sunxi.8
index 744679ec78..350d280530 100644
--- a/debian/manpages/u-boot-install-sunxi.8
+++ b/debian/manpages/u-boot-install-sunxi.8
@@ -31,10 +31,13 @@ deduced from the current running system, but if the
 environment variable is set, its contents are used instead.
 .SH OPTIONS
 .TP
+-a | --alt-offset
+Install at offset 128K on the device rather than the default 8K.  This
+is useful if the device has a standard-sized GUID partition table (GPT)
+and your board supports booting from this alternative offset.
 -f | --force
 Skip partition table sanity checks.  Usually, a MBR partition table is
 required (so u-boot has something to work with), but in rare setups you
 may put the data on another disk.  Likewise, GPT partition tables are
-incompatible with the layout used on sunxi devices (spl is written at
-offset 16384 while GPT occupies bytes [512..33280) ) but this option lets
+incompatible with the default U-Boot location of 8K, but this option lets
 you trample upon them anyway.

Bug#979688: Simplifying the list of image files for arm64 sunxi boards

2023-11-28 Thread harry88 
On 28/11/2023 18:56, Vagrant Cascadian wrote:
> [...]
> I had managed to successfully build a bootable image doing it "the old
> way" that worked on both pinebook (allwinner A64) and pinebook pro
> (rockchip rk3399) at "alternate offsets" that required no changes to the
> u-boot binaries... but that was with older versions. [...]

Hi Vagrant,

OK, that's interesting... do you recall at what offsets you placed the
different sunxi parts? This is not meant to hold up closing the bug, it's
just for my enlightenment, because my reading of the code is that on
sunxi the SPL and U-Boot proper have to be adjacent.

Thanks a lot,
Harold.

Bug#979688: Simplifying the list of image files for arm64 sunxi boards

2023-11-27 Thread harry88 
On 27/11/2023 20:12, Vagrant Cascadian (@vagrant) wrote on salsa:
>Thanks! Looks good to me, could you add (Closes: #XXX) on the first line of 
>the commit?

Hi Vagrant,

Thanks for agreeing to the merge request. I've added the Closes: note.

I just wanted to note while the bug is still open, that I was originally
aiming to simplify the list of files for each arm64 sunxi board in targets.mk,
and from my point of view u-boot-sunxi-with-spl.bin is the only one still 
needed.

I know that you said earlier (on 25/07/2023 17:39 in the bug report):

> I am also a bit inclined to adding u-boot-sunxi-with-spl.bin rather than
> replacing all the other parts, as there are some use-cases (e.g. an
> image capable of booting both sunxi and rockchip systems at different
> offsets) where the individual parts are still needed.

but I'm not sure that's right, because I believe sunxi-spl.bin and
u-boot-sunxi-with-spl.fit.itb always need to be concatenated to work,
because the SPL is hard-coded to look for U-Boot proper immediately after
itself, as determined by spl_mmc_get_uboot_raw_sector() in
arch/arm/mach-sunxi/board.c. So I think any "One image to rule them all"
that arranged the parts differently would need a custom build, not the
files currently in the Debian u-boot binary packages.

That said, I'm happy to see u-boot-sunxi-with-spl.bin included, so thank you
very much for doing that and all the other things that came up in this
sprawling bug report.

Best wishes,
Harold.

Bug#979688: Including u-boot-sunxi-with-spl.bin in the u-boot-sunxi binary package

2023-11-27 Thread harry88 
Control: tags -1 patch

On 25/07/2023 17:39, Vagrant Cascadian wrote:
> [...]
> Admittedly, I lost track of where this issue stands, as some of it was
> merged but obviously not all of it. It could perhaps benefit from
> refreshed patches and possibly a merge request via salsa.debian.org.
> [...]

Hi Vagrant,

I've now made a merge request as you suggested:

https://salsa.debian.org/debian/u-boot/-/merge_requests/33

It's the same as the patch in my previous comment on this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979688#50

Best wishes,
Harold.

Bug#1056289: Clarification of error message in u-boot-install-sunxi

2023-11-19 Thread harry88 
Package: u-boot-sunxi
Version: 2023.07+dfsg-1
Severity: normal
Tags: patch

Hi Vagrant,

When u-boot-install-sunxi does not recognise the system model name, it
prints the following error message:

  ERROR: Unknown system: (...)
  Specify target: TARGET=/usr/lib/u-boot/UBOOT

I think it might not be clear to everyone what "UBOOT" means here, so
I suggest "/" instead. The patch is below.

(This is the last of the minor changes suggested in bug#979688 that I
meant to file separate bug reports for.)

Thanks very much,
Harold.


diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
index b3af2c0b80..f3732ce326 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -50,7 +50,7 @@ if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
"Xunlong Orange Pi Zero") 
TARGET="/usr/lib/u-boot/orangepi_zero" ;;
*)
echo >&2 "ERROR: Unknown system: ${dtmodelname}"
-   echo >&2 "Specify target: TARGET=/usr/lib/u-boot/UBOOT"
+   echo >&2 "Specify target: 
TARGET=/usr/lib/u-boot//"
exit 1
;;
esac

Bug#1050315: Please include sun8i-drm-hdmi module in installer

2023-08-22 Thread harry88 
Package: fb-modules-6.4.0-3-arm64-di
Version: 6.4.11-1
Severity: normal
Tags: patch

Dear Debian Kernel Team,

Please could you include the sun8i-drm-hdmi module in the
fb-modules udeb for arm64?

It would allow the installer to run on a local HDMI display on
some 64-bit Allwinner boards such as the Orange Pi One Plus.
(Currently installation has to be done over the serial port.)

I've suggested a patch below.

Thank you very much,
Harold.

--- debian/installer/modules/arm64/fb-modules
+++ debian/installer/modules/arm64/fb-modules.new
@@ -20,6 +20,9 @@
 # For panel/backlight on Pinebook Pro
 pwm-rockchip

+# For HDMI on some sunxi platforms (e.g. Orange Pi 1+)
+sun8i-drm-hdmi
+
 # For HDMI on some rockchip platforms (e.g. rock64-rk3328)
 nvmem-rockchip-efuse
 phy-rockchip-inno-hdmi

Bug#979688: Including u-boot-sunxi-with-spl.bin in the u-boot-sunxi binary package (see bug#979688)

2023-08-07 Thread harry88 
On 25/07/2023 17:39, Vagrant Cascadian wrote:
> On 2023-07-25, Dave Jones wrote:
>> Heinrich Schuchardt and I were just having a look at this area for the
>> ubuntu packaging, specifically whether to include
>> u-boot-sunxi-with-spl.bin in the u-boot-sunxi build [...]
>>
> [...]
> I am also a bit inclined to adding u-boot-sunxi-with-spl.bin [...]


Hi Dave and Vagrant,

Thanks for taking an interest in this. I would like to see
u-boot-sunxi-with-spl.bin included for all boards in the u-boot-sunxi
binary package, for several reasons:

- it's the documented way to install U-Boot on all sunxi platforms (in
upstream's doc/board/allwinner/sunxi.rst and Debian's
debian/u-boot-sunxi.README.Debian)

- working with that single file is simpler than working with two files

- it works whatever the size of the SPL, whereas the current approach
assumes the SPL fits in 32K, which has not been guaranteed since commit
c0b417b2 (the SPL for H616 platforms needs about 36K)

- it's already there for all the 32-bit sunxi boards, so including it
for 64-bit boards too would be more consistent

- the currently used u-boot-sunxi-with-spl.fit.itb seems not to be a
documented file, but rather just an intermediate file produced when
binman is run (and for what it's worth, it doesn't conform to the FIT
specification in doc/usage/fit/source_file_format.rst because it lacks a
timestamp)

If u-boot-sunxi-with-spl.bin did end up being included for all boards,
then the u-boot-install-sunxi script could simply write that one file,
so its "splfiles" and "itbfiles" lists would no longer be needed. I've
suggested a patch below.

Best wishes,
Harold.


diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
index b3af2c0b80..4a041652e9 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -1,9 +1,6 @@
 #!/bin/sh
 set -e

-splfiles="sunxi-spl.bin u-boot-sunxi-with-spl.bin"
-itbfiles="u-boot.itb u-boot-sunxi-with-spl.fit.itb"
-
 dtmodel="/sys/firmware/devicetree/base/model"
 if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
dtmodelname=$(cat $dtmodel)
@@ -97,35 +94,11 @@ if [ -z "$FORCE" ]; then
 fi
 fi

-spl=
-for i in $splfiles ; do
-i=${TARGET}/$i
-if [ -f "$i" ]; then
-spl=$i
-fi
-done
-
-if [ -z "$spl" ]; then
-echo >&2 "$0: no known .spl file in ${TARGET}"
+imfile="${TARGET}/u-boot-sunxi-with-spl.bin"
+if [ ! -f "$imfile" ]; then
+echo >&2 "$0: no image file at ${imfile}"
 exit 1
 fi

-if [ -n "$itbfiles" ]; then
-itb=
-for i in $itbfiles ; do
-i=${TARGET}/$i
-if [ -f "$i" ]; then
-itb=$i
-fi
-done
-fi
-
-echo "Writing u-boot SPL image"
-dd conv=notrunc if=${spl} of="$DEV" bs=8k seek=1
-
-if [ -n "$itb" ]; then
-echo "Writing u-boot FIT image"
-dd conv=notrunc if=${itb} of="$DEV" bs=8k seek=5
-fi
-
-sync "$DEV"
+echo "Writing U-Boot image ${imfile} to ${DEV}"
+dd conv=fsync,notrunc if="$imfile" of="$DEV" bs=8K seek=1
diff --git a/debian/targets.mk b/debian/targets.mk
index 8ef27133d7..ffc5da62bb 100644
--- a/debian/targets.mk
+++ b/debian/targets.mk
@@ -146,40 +146,40 @@ ifeq (${DEB_HOST_ARCH},arm64)
   a64-olinuxino_assigns := 
BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin
   a64-olinuxino_targets := arch/arm/dts/sun50i-a64-olinuxino.dtb \
 spl/sunxi-spl.bin u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb \
-u-boot.bin uboot.elf
+u-boot.bin uboot.elf u-boot-sunxi-with-spl.bin

   # Philip Rinn 
   u-boot-sunxi_platforms += a64-olinuxino-emmc
   a64-olinuxino-emmc_assigns := 
BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin
   a64-olinuxino-emmc_targets := arch/arm/dts/sun50i-a64-olinuxino-emmc.dtb \
 spl/sunxi-spl.bin u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb \
-u-boot.bin uboot.elf
+u-boot.bin uboot.elf u-boot-sunxi-with-spl.bin

   # Domenico Andreoli 
   u-boot-sunxi_platforms += nanopi_neo2
   nanopi_neo2_assigns := BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin
   nanopi_neo2_targets := arch/arm/dts/sun50i-h5-nanopi-neo2.dtb \
 spl/sunxi-spl.bin u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb \
-u-boot.bin uboot.elf
+u-boot.bin uboot.elf u-boot-sunxi-with-spl.bin

   # Steev Klimaszewski 
   u-boot-sunxi_platforms += nanopi_neo_plus2
   nanopi_neo_plus2_assigns := 
BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin
   nanopi_neo_plus2_targets := arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dtb \
 spl/sunxi-spl.bin u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb \
-u-boot.bin uboot.elf
+u-boot.bin uboot.elf u-boot-sunxi-with-spl.bin

   # harr...@gmx.ph
   u-boot-sunxi_platforms += orangepi_one_plus
   orangepi_one_plus_assigns := 
BL31=/usr/lib/arm-trusted-firmware/sun50i_h6_no_pmic/bl31.bin
   orangepi_one_plus_targets := arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb \
 spl/sunxi-spl.bin u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb \
-u-boot.bin uboot.elf
+u-boot.bin uboot.elf

Bug#1041827: Check for mkimage in u-boot-install-sunxi no longer needed

2023-07-23 Thread harry88 

Package: u-boot-sunxi
Version: 2023.07+dfsg-1
Severity: normal
Tags: patch

Hi Vagrant,

Following commit 4f2f06b8 ("Drop support for using a FIT generator..."),
the u-boot-install-sunxi script no longer uses mkimage, so the check for
it can be safely removed, as in the suggested patch below.

(This is one of the small improvements I mentioned previously in
bug#979688 and meant to file separately.)

Thanks very much for looking after U-Boot for Debian all this time.

Best wishes,
Harold.


diff --git a/debian/bin/u-boot-install-sunxi
b/debian/bin/u-boot-install-sunxi
index a10fda96ed..b3af2c0b80 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -65,11 +65,6 @@ case "$1" in
exit 1;;
 esac

-if [ -z "$(which mkimage)" ]; then
-   echo >&2 "$0: mkimage: command not found. Please install u-boot-tools."
-   exit 1
-fi
-
 DEV="$1"
 if [ -z "$DEV" ] || ! shift || [ -n "$*" ]; then
 echo >&2 "Usage: $0 /dev/your-sd-or-mmc-or-image"

Bug#1039033: Please use no_pmic variant of TF-A on Orange Pi One Plus

2023-07-03 Thread harry88 

On 29/06/2023 00:54, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the u-boot-sunxi package:

#1039033: Please use no_pmic variant of TF-A on Orange Pi One Plus

It has been closed by Debian FTP Masters  (reply to 
Vagrant Cascadian ).


Hi Vagrant,

Thanks very much for doing that. Ethernet now works fine on this board.

Would you be able to help with #980493? If that patch could be applied
we would have an installer image for this board.

Thanks again,
Harold.

Bug#1039033: Please use no_pmic variant of TF-A on Orange Pi One Plus

2023-06-24 Thread harry88 

Package: u-boot-sunxi
Version: 2023.07~rc4+dfsg-1
Severity: normal
Tags: patch

Hi Vagrant,

Following on from #1032395, please could you change the build of TF-A
used by the Orange Pi One Plus from sun50i_h6 to sun50i_h6_no_pmic? That
should fix Ethernet on this board. I've attached a suggested patch.

Thanks very much,
Harold.
diff --git a/debian/targets.mk b/debian/targets.mk
index 1c7b5b2f9d..8ef27133d7 100644
--- a/debian/targets.mk
+++ b/debian/targets.mk
@@ -171,7 +171,7 @@ ifeq (${DEB_HOST_ARCH},arm64)
 
   # harr...@gmx.ph
   u-boot-sunxi_platforms += orangepi_one_plus
-  orangepi_one_plus_assigns := BL31=/usr/lib/arm-trusted-firmware/sun50i_h6/bl31.bin
+  orangepi_one_plus_assigns := BL31=/usr/lib/arm-trusted-firmware/sun50i_h6_no_pmic/bl31.bin
   orangepi_one_plus_targets := arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb \
 spl/sunxi-spl.bin u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb \
 u-boot.bin uboot.elf

Bug#1032395: fixed in arm-trusted-firmware 2.9.0+dfsg-1

2023-06-24 Thread harry88 

On 19/06/2023 04:51, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the arm-trusted-firmware package:

#1032395: Please make setting up regulators optional on sun50i_h6 platform
[...]


Hi Vagrant,

Thanks very much for doing that.

Please note that the comment in the rules file still mentions the old
name "sun50i_h6_leave_regulators".

Best wishes,
Harold.

Bug#1032395: Please make setting up regulators optional on sun50i_h6 platform

2023-03-05 Thread harry88 

Package: arm-trusted-firmware
Version: 2.8.0+dfsg-1
Severity: normal
Tags: patch

Hi Vagrant,

Commit fb23b104 to TF-A introduced setting up power regulators on the
H6. Unfortunately this broke Ethernet on some H6 boards such as the
Orange Pi One Plus and the Orange Pi 3, because the Ethernet PHY
requires certain regulators to be brought up together, not the way TF-A
does it.

For that reason, commit 67412e4d introduced a build option
SUNXI_SETUP_REGULATORS to be set to 0 for those boards. In that case
TF-A leaves the regulators alone and the kernel sets them up later. It's
documented in docs/plat/allwinner.rst.

Please could we introduce a subplatform of sun50i_h6 with the regulator
setup disabled, to allow Ethernet to work on those boards? I've included
a suggested patch below.

Thanks very much,
Harold.

diff --git a/debian/rules b/debian/rules
index 10bafab74..66ecf8bab 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,6 +25,13 @@ platforms_nodebug := sun50i_a64 imx8mq
 imx8mn_subplatforms := imx8mn imx8mn_uart4
 imx8mn_uart4_assigns := IMX_BOOT_UART_BASE=0x30a6

+# TF-A's regulator setup breaks Ethernet on some H6 boards,
+# so make it optional by having two subplatforms:
+#   * sun50i_h6: default configuration
+#   * sun50i_h6_leave_regulators: skip regulator setup
+sun50i_h6_subplatforms := sun50i_h6 sun50i_h6_leave_regulators
+sun50i_h6_leave_regulators_assigns := SUNXI_SETUP_REGULATORS=0
+
 # Always set CROSS_COMPILE, which also works for native builds.
 define build_platform
$(eval platform := $(1))

Bug#979688: Simplifying the list of image files for arm64 sunxi boards

2021-02-09 Thread harry88 
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.

Bug#982278: u-boot-install-sunxi risks overwriting files in current directory

2021-02-07 Thread harry88 
Package: u-boot-sunxi
Version: 2021.01~rc4+dfsg-1
Severity: important
Tags: patch

Hi Vagrant,

Salsa commit 4f2f06b8 for the u-boot package introduced a bug in the
u-boot-install-sunxi script that could inadvertently overwrite the
user's own files.  By removing the "mktemp -d" and the "cd", it means
the "mbr-sign" and "gpt-sign" files now get created in the current
directory, which would be unfortunate if there happened to be any user
files with those names.

A patch to fix the problem is below.  It has previously appeared in
bug#979688 as part of a larger patch intended to continue the
simplifying work begun with commit 4f2f06b8.

Best wishes,
Harold.

diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
index 4f80e01099..6840a62696 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -63,15 +63,13 @@ fi
 if [ -z "$FORCE" ]; then
 # A very simple sanity check.  GPT mandates a "protective MBR" so this 
works
 # even with GPT partitioning.
-printf '%b' '\0125\0252' >mbr-sign
-if ! cmp -s -i 0:510 -n 2 mbr-sign "$DEV"; then
+if ! printf '\125\252' | cmp -s -i 0:510 -n 2 - "$DEV"; then
echo >&2 "$0: device/image ($DEV) has no MBR partition table"
exit 1
 fi

 # But, on sunxi64, spl will trample upon GPT.
-printf "EFI PART" >gpt-sign
-if cmp -s -i 0:512 -n 8 gpt-sign "$DEV"; then
+if printf 'EFI PART' | cmp -s -i 0:512 -n 8 - "$DEV"; then
echo >&2 "$0: device/image ($DEV) uses GPT partition table, unusable on 
sunxi64"
exit 1
 fi

Bug#969518: Add missing ESPRESSObin variants

2021-02-06 Thread harry88 
On Fri, 4 Sep 2020 06:38:25 +0200, Andre Heider wrote:
>[...]
>+Machine: Globalscale Marvell ESPRESSOBin Board (eMMC)
>+DTB-Id: marvell/armada-3720-espressobin-emmc.dts
>[...]
>+Machine: Globalscale Marvell ESPRESSOBin Board V7
>+DTB-Id: marvell/armada-3720-espressobin-v7.dts
>[...]
>+Machine: Globalscale Marvell ESPRESSOBin Board V7 (eMMC)
>+DTB-Id: marvell/armada-3720-espressobin-v7-emmc.dts
>[...]

Shouldn't those be *.dtb rather than *.dts?  I think with the above settings
flash-kernel is likely to give a "Couldn't find DTB..." error on those boards.

Best wishes,
Harold.

Bug#979688: Simplifying the list of image files for arm64 sunxi boards

2021-01-31 Thread harry88 
Hi Vagrant,

I noticed that with commit 92f637eda9 we're starting to use the
u-boot-install-sunxi script for armhf boards as well as arm64, so I've
refreshed my patch to it, below.

I thought I might as well add the remaining 24 armhf boards to it while
I was at it, so it now has 26 armhf and 11 arm64 boards, matching what's
in debian/targets, sorted by U-Boot board name.

I think it would be nice if this simplification could be included in
bullseye.  What do you think?

Best wishes,
Harold.


diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
index 4f80e01099..4b862fd3ff 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -1,29 +1,50 @@
 #!/bin/sh
 set -e

-splfiles="sunxi-spl.bin u-boot-sunxi-with-spl.bin"
-itbfiles="u-boot.itb u-boot-sunxi-with-spl.fit.itb"
-
 dtmodel="/sys/firmware/devicetree/base/model"
 if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
dtmodelname=$(cat $dtmodel)
case "$dtmodelname" in
-   Pinebook) TARGET="/usr/lib/u-boot/pinebook" ;;
-   "Pine64 PinePhone (1.2)") TARGET='/usr/lib/u-boot/pinephone' ;;
-   Pine64+) TARGET="/usr/lib/u-boot/pine64_plus" ;;
-   "Pine64 LTS") TARGET="/usr/lib/u-boot/pine64-lts" ;;
-   "Olimex A20-OLinuXino-LIME2") 
TARGET="/usr/lib/u-boot/A20-OLinuXino-Lime2"; itbfiles= ;;
-   "Olimex A64-Olinuxino") TARGET="/usr/lib/u-boot/a64-olinuxino/" 
;;
+   "Olimex A10-OLinuXino-LIME") 
TARGET="/usr/lib/u-boot/A10-OLinuXino-Lime" ;;
+   "Olimex A10s-Olinuxino Micro") 
TARGET="/usr/lib/u-boot/A10s-OLinuXino-M" ;;
+   "Olimex A20-OLinuXino-LIME") 
TARGET="/usr/lib/u-boot/A20-OLinuXino-Lime" ;;
+   "Olimex A20-OLinuXino-LIME2") 
TARGET="/usr/lib/u-boot/A20-OLinuXino-Lime2" ;;
+   "Olimex A20-OLinuXino-LIME2-eMMC") 
TARGET="/usr/lib/u-boot/A20-OLinuXino-Lime2-eMMC" ;;
+   "Olimex A20-Olinuxino Micro") 
TARGET="/usr/lib/u-boot/A20-OLinuXino_MICRO" ;;
+   "Olimex A20-Olimex-SOM-EVB") 
TARGET="/usr/lib/u-boot/A20-Olimex-SOM-EVB" ;;
+   "LeMaker Banana Pi") TARGET="/usr/lib/u-boot/Bananapi" ;;
+   "Banana Pi BPI-M2-Ultra") 
TARGET="/usr/lib/u-boot/Bananapi_M2_Ultra" ;;
+   "LeMaker Banana Pro") TARGET="/usr/lib/u-boot/Bananapro" ;;
+   "NextThing C.H.I.P.") TARGET="/usr/lib/u-boot/CHIP" ;;
+   "Cubietech Cubieboard") TARGET="/usr/lib/u-boot/Cubieboard" ;;
+   "Cubietech Cubieboard2") TARGET="/usr/lib/u-boot/Cubieboard2" ;;
+   "Cubietech Cubieboard4") TARGET="/usr/lib/u-boot/Cubieboard4" ;;
+   "Cubietech Cubietruck") TARGET="/usr/lib/u-boot/Cubietruck" ;;
+   "Cubietech Cubietruck Plus") 
TARGET="/usr/lib/u-boot/Cubietruck_plus" ;;
+   "Lamobo R1") TARGET="/usr/lib/u-boot/Lamobo_R1" ;;
+   "LinkSprite pcDuino") 
TARGET="/usr/lib/u-boot/Linksprite_pcDuino" ;;
+   "LinkSprite pcDuino3") 
TARGET="/usr/lib/u-boot/Linksprite_pcDuino3" ;;
+   "PineRiver Mini X-Plus") TARGET="/usr/lib/u-boot/Mini-X" ;;
+   "Banana Pi BPI-M3") TARGET="/usr/lib/u-boot/Sinovoip_BPI_M3" ;;
"Olimex A64-Olinuxino-eMMC") 
TARGET="/usr/lib/u-boot/a64-olinuxino-emmc" ;;
-   "Olimex A64 Teres-I") TARGET="/usr/lib/u-boot/teres_i/" ;;
-   "OrangePi Zero Plus2") 
TARGET="/usr/lib/u-boot/orangepi_zero_plus2/" ;;
-   "OrangePi One Plus") 
TARGET="/usr/lib/u-boot/orangepi_one_plus/" ;;
-   "FriendlyARM NanoPi NEO") TARGET="/usr/lib/u-boot/nanopi_neo" ; 
itbfiles= ;;
-   "FriendlyARM NanoPi NEO 2") 
TARGET="/usr/lib/u-boot/nanopi_neo2/" ;;
-   "FriendlyARM NanoPi NEO Plus2") 
TARGET="/usr/lib/u-boot/nanopi_neo_plus2/" ;;
+   "Olimex A64-Olinuxino") TARGET="/usr/lib/u-boot/a64-olinuxino" 
;;
+   "Banana Pi M2 Berry") 
TARGET="/usr/lib/u-boot/bananapi_m2_berry" ;;
+   "FriendlyARM NanoPi NEO") TARGET="/usr/lib/u-boot/nanopi_neo" ;;
+   "FriendlyARM NanoPi NEO 2") 
TARGET="/usr/lib/u-boot/nanopi_neo2" ;;
+   "FriendlyARM NanoPi NEO Air") 
TARGET="/usr/lib/u-boot/nanopi_neo_air" ;;
+   "FriendlyARM NanoPi NEO Plus2") 
TARGET="/usr/lib/u-boot/nanopi_neo_plus2" ;;
+   "OrangePi One Plus") TARGET="/usr/lib/u-boot/orangepi_one_plus" 
;;
+   "Xunlong Orange Pi Plus / Plus 2") 
TARGET="/usr/lib/u-boot/orangepi_plus" ;;
+   "Xunlong Orange Pi Zero") 
TARGET="/usr/lib/u-boot/orangepi_zero" ;;
+   "OrangePi Zero Plus2") 
TARGET="/usr/lib/u-boot/orangepi_zero_plus2" ;;
+   "Pine64 LTS") TARGET="/usr/lib/u-boot/pine64-lts" ;;
+   "Pine64+") TARGET="/usr/lib/u-boot/pine64_plus" ;;
+   "Pinebook") TARGET="/usr/lib/u-boot/pinebook" ;;
+   "Pine64 PinePhone (1.2)")

Bug#981346: partman-base: partman still overwrites u-boot on some systems

2021-01-29 Thread harry88 
Package: partman-base
Version: 214
Severity: important
Tags: d-i patch

Dear Debian Install System Team,

This is a follow-on from bug #770666 in which some systems had their firmware
overwritten by partman.  The patch there provided a function to detect the
affected systems by looking for their manufacturer names in /proc/cpuinfo,
so that partman would know not to overwrite in those cases.

Unfortunately, affected arm64 systems don't contain a suitable string in
/proc/cpuinfo, so their firmware still ends up getting overwritten.

My suggestion is to use /proc/device-tree/compatible instead of /proc/cpuinfo.
By searching the list there for an entry beginning with "allwinner," or
"fsl,imx6" or "ti,am33xx", we will hopefully match the same systems as the
current search for "Allwinner", "Freescale" or "AM33XX" would have found.

I've included a suggested patch below.

Thank you for considering it,
Harold.


diff --git a/parted_server.c b/parted_server.c
index 41784b70..4e7a0ead 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -1334,30 +1334,51 @@ command_dump()
 oprintf("OK\n");
 }

-/* Check whether we are running on a sunxi-based, freescale-based, or
-   AM33XX (beaglebone black) system. */
+/* Decide whether this system stores firmware on disk by looking up
+ * machine type in device tree. If Allwinner (bug #751704) or
+ * i.MX6 or AM33xx (bug #770666), assume yes, otherwise no.
+ */
-int
+bool
 is_system_with_firmware_on_disk()
 {
-int cpuinfo_handle;
-int result = 0;
+int dt_handle;
+int close_ret;
+char *cur;
 char buf[4096];
 int length;

-if ((cpuinfo_handle = open("/proc/cpuinfo", O_RDONLY)) != -1) {
-length = read(cpuinfo_handle, buf, sizeof(buf)-1);
-if (length > 0) {
-buf[length]='\0';
-if (strstr(buf, "Allwinner") != NULL)
-result = 1;
-else if (strstr(buf, "Freescale") != NULL)
-result = 1;
-else if (strstr(buf, "AM33XX") != NULL)
-result = 1;
-}
-close(cpuinfo_handle);
-}
-return result;
+dt_handle = open("/proc/device-tree/compatible", O_RDONLY);
+if (dt_handle == -1) {
+log("Error opening device-tree property: %s", strerror(errno));
+log("Assuming non-ARM system, with no firmware on disk");
+return false;
+}
+
+length = read(dt_handle, buf, sizeof(buf)-1);
+if (length == -1)
+log("Error reading device-tree property: %s", strerror(errno));
+
+close_ret = close(dt_handle);
+if (close_ret == -1)
+log("Error closing device-tree property: %s", strerror(errno));
+
+if (length == -1 || close_ret == -1) {
+log("Assuming no firmware on disk");
+return false;
+}
+
+buf[length] = '\0';
+for (cur = buf; cur < buf+length; cur += strlen(cur)+1) {
+if (0 == strncmp(cur, "allwinner,", 10)
+|| 0 == strncmp(cur, "fsl,imx6", 8)
+|| 0 == strncmp(cur, "ti,am33xx", 9)) {
+log("Machine type '%s'; stores firmware on disk", cur);
+return true;
+}
+}
+
+log("Machine type checked; assuming no firmware on disk");
+return false;
 }

 void
@@ -1368,15 +1389,15 @@ command_commit()
 critical_error("The device %s is not opened.", device_name);
 log("command_commit()");

-/* The boot device on sunxi-based systems needs special handling.
+/* The boot device on some systems needs special handling.
  * By default partman calls ped_disk_clobber when writing the
- * partition table, but on sunxi-based systems this would overwrite
+ * partition table, but on some systems this would overwrite
  * the firmware area, resulting in an unbootable system (see
  * bug #751704).
  */
 if (is_system_with_firmware_on_disk() && !strncmp(disk->dev->path, 
"/dev/mmcblk", 11)) {
 disk->needs_clobber = 0;
-log("Sunxi/Freescale/AM33XX detected. Disabling 
ped_disk_clobber " \
+log("Disabling ped_disk_clobber " \
 "for the boot device %s to protect the firmware " \
 "area.", disk->dev->path);
 }

Bug#980114: closed by Debian FTP Masters (fixed in linux 5.10.9-1)

2021-01-29 Thread harry88 
> Sent: Thursday, January 21, 2021 at 2:15 PM
> From: "Debian Bug Tracking System" 
> [...]
> This is an automatic notification regarding your Bug report
> which was filed against the src:linux package:
> #980114: Please enable CONFIG_MFD_AXP20X_I2C on arm64
> [...]
>  [ Bastian Blank ]
>  [...]
>  * [arm64] Enable MFD_AXP20X_I2C. (closes: #980114)

That made all the difference, thanks. Now the kernel can talk to the PMIC and 
so Ethernet etc. works..

Much appreciated,
Harold.

Bug#981328: flash-kernel: Please add support for Orange Pi One Plus

2021-01-29 Thread harry88 
Package: flash-kernel
Version: 3.103
Severity: normal
Tags: d-i patch

Dear Maintainers,

Please would you add the Orange Pi One Plus to the flash-kernel database?
It would allow kernel upgrades to work seamlessly on this board.

I've provided a patch below.

Thank you very much,
Harold.

--- db/all.db   2021-01-29 00:06:13.463905200 +
+++ db/all.db.new   2021-01-29 00:10:22.503445685 +
@@ -1235,6 +1235,13 @@
 U-Boot-Script-Name: bootscr.sunxi
 Required-Packages: u-boot-tools

+Machine: OrangePi One Plus
+Kernel-Flavors: arm64
+DTB-Id: allwinner/sun50i-h6-orangepi-one-plus.dtb
+Boot-Script-Path: /boot/boot.scr
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
 Machine: PHICOMM N1
 Kernel-Flavors: arm64
 DTB-Id: amlogic/meson-gxl-s905d-phicomm-n1.dtb




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.0-2-arm64 (SMP w/4 CPU threads)
Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_PH:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  devio  1.2-1.2+b1
ii  initramfs-tools0.139
ii  linux-base 4.6
ii  mtd-utils  1:2.1.2-2
ii  ucf3.0043

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2021.01+dfsg-2

flash-kernel suggests no packages.

-- debconf information excluded

Bug#979688: Simplifying the list of image files for arm64 sunxi boards

2021-01-19 Thread harry88 
Tags: patch

Hi Vagrant, thanks for looking at this.


On Fri, 15 Jan 2021, Vagrant Cascadian wrote:
> This is fairly new in u-boot, but yes, it's probably possible in most 
> cases with recent u-boot versions.

Great.  I've tried making that change to debian/targets in version 
2021.01+dfsg-1 (patch is below) and rebuilding, and I've verified that 
for all eleven arm64 sunxi platforms:

- u-boot-sunxi-with-spl.bin is equal to spl/sunxi-spl.bin concatenated 
with u-boot-sunxi-with-spl.fit.fit
- spl/sunxi-spl.bin is 32K in size
- u-boot-sunxi-with-spl.fit.fit differs from u-boot-sunxi-with-spl.fit.itb 
only in a timestamp

Therefore, for each of these platforms, writing u-boot-sunxi-with-spl.bin 
to the card at offset 8K should work just as well as writing the SPL at 
8K and the FIT image at 40K, which the current u-boot-install-sunxi 
script does.  I've confirmed that it works on the Orange Pi One Plus.


> > That would mean we could further simplify the u-boot-install-sunxi script.
> 
> This part is already done in the 2021.01~rc version experimental.

I saw that version, thanks, but I was proposing to further simplify the 
script by making it write just one file to the card rather than two. 
I've double-checked and I'm sure my patch to that script doesn't 
duplicate any changes already made.  The full list of changes in the 
patch is:

- Improve 'Specify target' error message
- Remove check for mkimage which is no longer used
- Avoid creating tempfiles in current directory
- Write one combined file to card rather than two components
- Sync on the write operation rather than separately


> > Out of interest, what's the reason for including uboot.elf? 
> 
> I tried removing it at some point, but some platforms require it 
> (e.g. p2371-2180 in u-boot-tegra).

OK.  What do you think of the idea of installing it only where needed? 
Perhaps it could be listed explicitly in debian/targets for those 
platforms that require it.

Thanks very much,
Harold.

--- debian/targets  2021-01-19 06:18:39.675829807 +
+++ debian/targets.simplified   2021-01-19 06:18:54.167504580 +
@@ -229,37 +229,37 @@
 arm64  rpi rpi_arm64   u-boot.bin
 
 # Rodrigo Exterckötter Tjäder 
-arm64  sunxi   a64-olinuxino   
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-olinuxino.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   a64-olinuxino   
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Philip Rinn 
-arm64  sunxi   a64-olinuxino-emmc  
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-olinuxino-emmc.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   a64-olinuxino-emmc  
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Domenico Andreoli 
-arm64  sunxi   nanopi_neo2 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-h5-nanopi-neo2.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   nanopi_neo2 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Steev Klimaszewski 
-arm64  sunxi   nanopi_neo_plus2
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   nanopi_neo_plus2
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Frederic Danis 
-arm64  sunxi   orangepi_zero_plus2 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   orangepi_zero_plus2 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # harr...@gmx.ph
-arm64  sunxi   orangepi_one_plus   
/usr/lib/arm-trusted-firmware/sun50i_h6/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   orangepi_one_plus   
/usr/lib/arm-trusted-firmware/sun50i_h6/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Vagrant Cascadian 
-arm64  sunxi   pine64_plus 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pine64-plus.dtb 
arch/arm/dts/sun50i-a64-pine64.dtb u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   pine64_plus 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Sunil Mohan Adapa 
-arm64  sunxi   pine64-lts  
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pine64-lts.dtb 
arch/arm/dts/sun50i-a64-pine64.dtb

Bug#980493: Please add support for Orange Pi One Plus

2021-01-19 Thread harry88 
Source: debian-installer
Severity: wishlist
Tags: patch

Dear installer maintainers,

Please could you generate installer images for the Orange Pi One Plus?
The U-Boot support is already there in unstable, so I think it would
just be a matter of adding orangepi_one_plus to the list in
build/config/arm64/*.cfg, as in the patch below.

Thank you very much,
Harold.

diff --git a/build/config/arm64/netboot-gtk.cfg 
b/build/config/arm64/netboot-gtk.cfg
index 243202414..5bd6fdbbf 100644
--- a/build/config/arm64/netboot-gtk.cfg
+++ b/build/config/arm64/netboot-gtk.cfg
@@ -36,7 +36,7 @@ netboot_images_concatenateable: $(TEMP_KERNEL) $(TEMP_INITRD) 
$(TEMP_DTBS)
cp -r $(TEMP_DTBS) $(TEMP)/netboot_images_concatenateable/dtbs/
cp boot/README.device-tree 
$(TEMP)/netboot_images_concatenateable/dtbs/README
mkdir -p 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)
-   for target in a64-olinuxino nanopi_neo2 orangepi_zero_plus2 pine64_plus 
pinebook teres_i ; do \
+   for target in a64-olinuxino nanopi_neo2 orangepi_one_plus 
orangepi_zero_plus2 pine64_plus pinebook teres_i ; do \
echo "Providing u-boot binaries for $$target ..." ; \
gen-hd-image -v -s "$(IMAGE_SIZE)" -p 32768 -b firmware -o 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/firmware.$${target}.img
 ; \
TARGET=/usr/lib/u-boot/$${target} u-boot-install-sunxi 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/firmware.$${target}.img
 ; \
diff --git a/build/config/arm64/netboot.cfg b/build/config/arm64/netboot.cfg
index 5348b862e..54a30d938 100644
--- a/build/config/arm64/netboot.cfg
+++ b/build/config/arm64/netboot.cfg
@@ -21,7 +21,7 @@ netboot_images_concatenateable: $(TEMP_KERNEL) $(TEMP_INITRD) 
$(TEMP_DTBS)
cp -r $(TEMP_DTBS) $(TEMP)/netboot_images_concatenateable/dtbs/
cp boot/README.device-tree 
$(TEMP)/netboot_images_concatenateable/dtbs/README
mkdir -p 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)
-   for target in a64-olinuxino nanopi_neo2 orangepi_zero_plus2 pine64_plus 
pinebook teres_i ; do \
+   for target in a64-olinuxino nanopi_neo2 orangepi_one_plus 
orangepi_zero_plus2 pine64_plus pinebook teres_i ; do \
echo "Providing u-boot binaries for $$target ..." ; \
gen-hd-image -v -s "$(IMAGE_SIZE)" -p 32768 -b firmware -o 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/firmware.$${target}.img
 ; \
TARGET=/usr/lib/u-boot/$${target} u-boot-install-sunxi 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/firmware.$${target}.img
 ; \
diff --git a/build/config/arm64/u-boot.cfg b/build/config/arm64/u-boot.cfg
index 68d6978b0..34f7c8685 100644
--- a/build/config/arm64/u-boot.cfg
+++ b/build/config/arm64/u-boot.cfg
@@ -6,7 +6,7 @@ EXTRANAME = $(MEDIUM)/
 .PHONY: u-boot-binaries
 u-boot-binaries:
mkdir -p $(SOME_DEST)/$(EXTRANAME)/
-   for target in a64-olinuxino nanopi_neo2 orangepi_zero_plus2 pine64_plus 
pinebook teres_i ; do \
+   for target in a64-olinuxino nanopi_neo2 orangepi_one_plus 
orangepi_zero_plus2 pine64_plus pinebook teres_i ; do \
echo "Providing u-boot binaries for $$target ..." ; \
gen-hd-image -v -b firmware -o 
$(SOME_DEST)/$(EXTRANAME)/$${target}.img ; \
TARGET=/usr/lib/u-boot/$${target} u-boot-install-sunxi 
$(SOME_DEST)/$(EXTRANAME)/$${target}.img ; \

Bug#980114: Please enable CONFIG_MFD_AXP20X_I2C on arm64

2021-01-14 Thread harry88 
Source: linux
Severity: wishlist

Hello,

Please could you enable this module:

CONFIG_MFD_AXP20X_I2C=m   ("X-Powers AXP series PMICs with I2C")

on arm64?  Some Allwinner-based boards have this kind of PMIC and some 
components such as USB and Ethernet do not work without this module.  For 
example, kernel 5.9.11-1 on the Orange Pi One Plus gives:

[4.735203] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PC regulator
[4.742423] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 70
[4.749345] sun50i-h6-pinctrl 300b000.pinctrl: pin-70 (300b000.pinctrl:70) 
status -517
[4.757306] sun4i-usb-phy 5100400.phy: Couldn't request ID GPIO

and:

[4.766284] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PD regulator
[4.773495] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 96
[4.780420] sun50i-h6-pinctrl 300b000.pinctrl: pin-96 (502.ethernet) 
status -517
[4.789596] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 96 
(PD0) from group PD0  on device 300b000.pinctrl
[4.801736] dwmac-sun8i 502.ethernet: Error applying setting, reverse 
things back

Thank you very much,
Harold.

Bug#979688: Simplifying the list of image files for arm64 sunxi boards

2021-01-09 Thread harry88 
Package: u-boot-sunxi
Version: 2021.01~rc4+dfsg-2
Severity: wishlist

Hi Vagrant,

For 32-bit Allwinner boards, the u-boot-sunxi package provides the image
u-boot-sunxi-with-spl.bin (as well as the standard uboot.elf), but for
64-bit boards it provides instead several components such as sunxi-spl.bin,
u-boot.bin and u-boot-nodtb.bin.  This is because originally ARM Trusted
Firmware wasn't available in Debian (according to commit 59a1bb4f) and so
a full bootable image had to be made later on the target system using the
u-boot-install-sunxi64 script.

Now that we have arm-trusted-firmware which can be incorporated into U-Boot
images at build time, I think we could simply use u-boot-sunxi-with-spl.bin
for the 64-bit boards as well as the 32-bit ones.  So for example the
Orange Pi One Plus entry in debian/targets could be simplified from:

arm64   sunxi   orangepi_one_plus   
/usr/lib/arm-trusted-firmware/sun50i_h6/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb 
u-boot-sunxi-with-spl.fit.itb

to:

arm64   sunxi   orangepi_one_plus   
/usr/lib/arm-trusted-firmware/sun50i_h6/bl31.bin u-boot-sunxi-with-spl.bin

and similarly so could all the other arm64 sunxi entries.

That would mean we could further simplify the u-boot-install-sunxi script.
Below is a suggested patch to the latest version (commit 81c17086) which
includes some other suggested small improvements such as eliminating
temporary files.

Out of interest, what's the reason for including uboot.elf?  It was
originally added for all boards in commit d22b2e11, removed in c769484b
then reinstated in 128e7344, but I'm not sure where it gets used.

Thanks a lot for considering these suggestions.

Best wishes,
Harold.

--- debian/bin/u-boot-install-sunxi 2021-01-10 05:10:34.586009078 +
+++ debian/bin/u-boot-install-sunxi.simplified  2021-01-10 05:08:20.817459903 
+
@@ -18,7 +18,7 @@
"FriendlyARM NanoPi NEO Plus2") 
TARGET="/usr/lib/u-boot/nanopi_neo_plus2/" ;;
*)
echo >&2 "ERROR: Unknown system: ${dtmodelname}"
-   echo >&2 "Specify target: TARGET=/usr/lib/u-boot/UBOOT"
+   echo >&2 "Specify target: 
TARGET=/usr/lib/u-boot/"
exit 1
;;
esac
@@ -33,11 +33,6 @@
exit 1;;
 esac

-if [ -z "$(which mkimage)" ]; then
-   echo >&2 "$0: mkimage: command not found. Please install u-boot-tools."
-   exit 1
-fi
-
 DEV="$1"
 if [ -z "$DEV" ] || ! shift || [ -n "$*" ]; then
 echo >&2 "Usage: $0 /dev/your-sd-or-mmc-or-image"
@@ -58,36 +53,24 @@
 if [ -z "$FORCE" ]; then
 # A very simple sanity check.  GPT mandates a "protective MBR" so this 
works
 # even with GPT partitioning.
-printf '%b' '\0125\0252' >mbr-sign
-if ! cmp -s -i 0:510 -n 2 mbr-sign "$DEV"; then
+if ! printf '\125\252' | cmp -s -i 0:510 -n 2 - "$DEV"; then
echo >&2 "$0: device/image ($DEV) has no MBR partition table"
exit 1
 fi

 # But, on sunxi64, spl will trample upon GPT.
-printf "EFI PART" >gpt-sign
-if cmp -s -i 0:512 -n 8 gpt-sign "$DEV"; then
+if printf 'EFI PART' | cmp -s -i 0:512 -n 8 - "$DEV"; then
echo >&2 "$0: device/image ($DEV) uses GPT partition table, unusable on 
sunxi64"
exit 1
 fi
 fi

-itbfiles="u-boot.itb u-boot-sunxi-with-spl.fit.itb"
-itb=
-for i in $itbfiles ; do
-   i=${TARGET}/$i
-   if [ -f "$i" ]; then
-   itb=$i
-   fi
-done
+imfile="u-boot-sunxi-with-spl.bin"

-if [ -z "$itb" ]; then
-   echo >&2 "$0: no known .itb file in ${TARGET}"
+if [ ! -f "${TARGET}/${imfile}" ]; then
+   echo >&2 "$0: no ${imfile} image file in ${TARGET}"
exit 1
 fi

-echo "Writing sunxi-spl"
-dd conv=notrunc if=${TARGET}/sunxi-spl.bin of="$DEV" bs=8k seek=1
-echo "Writing u-boot FIT image"
-dd conv=notrunc if=${itb} of="$DEV" bs=8k seek=5
-sync "$DEV"
+echo "Writing U-Boot image to ${DEV}"
+dd conv=fsync,notrunc if="${TARGET}/${imfile}" of="$DEV" bs=8k seek=1

Bug#979216: Please add support for the Orange Pi One Plus

2021-01-09 Thread harry88 
Tested and working, thanks a lot!

I installed on an SDcard with u-boot-install-sunxi and U-Boot came up fine on 
the serial port.

Thanks again,
Harold.

Bug#979216: Please add support for the Orange Pi One Plus

2021-01-04 Thread harry88 
Hi Vagrant,

Sure, I'm happy to be a tester.  I've subscribed to the package tracker and 
I'll try it once it's built for the One Plus.

Thanks a lot,
Harold.

Bug#979216: Please add support for the Orange Pi One Plus

2021-01-04 Thread harry88 
Source: u-boot
Severity: wishlist

Hi Vagrant,

Following on from #979179, please could you add support for the Orange Pi One 
Plus to U-Boot?

I think the new entry in debian/targets would be:

arm64   sunxi   orangepi_one_plus   
/usr/lib/arm-trusted-firmware/sun50i_h6/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb u-boot.itb

Thanks very much,
Harold.


-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.8.0-0.bpo.2-armmp (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_PH:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#979179: (Please enable Allwinner H6 target)

2021-01-04 Thread harry88 
Thanks for the quick work Vagrant.

Harold.

Bug#979179: Please enable Allwinner H6 target

2021-01-03 Thread harry88 
Source: arm-trusted-firmware
Severity: wishlist

Hi Vagrant,

Thank you for all the work you do supporting ARM boards in Debian.

There are a few boards based on the Allwinner H6 and it would be nice
to support those.  Please could you add:

sun50i_h6 bl31.bin

to the list in debian/targets ?

Thanks again,
Harold.


-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.8.0-0.bpo.2-armmp (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_PH:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#971892: linux: Please enable modules for HDMI audio

2020-10-30 Thread harry88 
Thanks for the information Diederik, I hadn't noticed they had already been 
enabled for some time for arm64.

SND_SUN4I_I2S was requested in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921019

and DRM_DW_HDMI_I2S_AUDIO came in with ARCH_MESON which was requested in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852132

but both of those changes only concerned arm64.

So my request to the kernel maintainers now is for these two modules to be 
enabled for armhf as well.

Best wishes,
Harold.

Bug#971892: linux: Please enable modules for HDMI audio

2020-10-09 Thread harry88 
Source: linux
Severity: normal

Hello,

Please could you enable these modules:

CONFIG_SND_SUN4I_I2S=m   ("Allwinner A10 I2S Support")
CONFIG_DRM_DW_HDMI_I2S_AUDIO=m   ("Synopsys Designware I2S Audio interface")

in the next kernel?  They would allow HDMI audio to work on various 
Allwinner-based ARM boards.

Thank you very much,
Harold.


-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.8.0-0.bpo.2-armmp (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_PH:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled