Re: (java) Builds not reproducible on armhf

[Vagrant Cascadian]

On 2024-05-20, Mechtilde Stehmann wrote:
> I want to clean up my Java packages.
>
> There are several with FTBR. I found that the day of the *.poms s a date 
> from 1970.
>
> for example they are the packages
>
> vinnie

Looking at the history for vinnie:

  https://tests.reproducible-builds.org/debian/history/armhf/vinnie.html

It is only very recently that this started happening (2024-05-04)
without source changes in vinnie itself, so I would suspect some change
in the toolchain used to produce the .pom files?

commons-email is similar, although starting 2024-04-04:

  https://tests.reproducible-builds.org/debian/history/armhf/commons-email.html

ez-vcard is similar too, starting 2024-04-20:

  
https://tests.reproducible-builds.org/debian/rb-pkg/trixie/armhf/diffoscope-results/ez-vcard.html

Although some of those builds also have differences in some xz
contents... might just be related to the timestamp differences.


Wild hunch is one build is run on a 64-bit kernel (without a linux32
personality) and one build on a 32-bit kernel... that is one of the main
differences between these armhf test builds and builds on other
architectures, where this does not seem to happen...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Just tried arm64 netinstall on a bananai-m5

[Vagrant Cascadian]

On 2023-08-15, gene heskett wrote:
> used dd to write the arm64-bookworm-12.1 netinstall image to a 64G SDXC 
> ONN. brand card, makes no attempt to boot plugged into a bananapi-m5. 
> bring card back to reader, can't mount it, wrong filesystem for both 
> partitions. Give up, write Armbian-jammie-full-desktop iso to card, 
> mounts ok, boots bananapi-m5 normally.
>
> What did I do wrong?

Hard to say based on so little information...

My wild guess is the Armbian-jammie-full-desktop iso includes boot
firmware.

Do you have a URL to the exact image you used?

Do you have any output from the serial console when trying to boot the
Debian image? Armbian?

The only way what you did might work is if you have boot firmware
present on some other media (e.g. SPI, eMMC, etc.) that implements EFI,
such as edk2/tianocore or u-boot.

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Status of dpkg-shlibdeps tracking ARM object linkage ABI mismatches

[Vagrant Cascadian]

On 2023-06-21, Emanuele Rocca wrote:
> On 2023-06-16 11:19, Emanuele Rocca wrote:
> (1) I couldn't find any armel object with the hard-float flag set.
>
> (2) There are a few armhf packages shipping files with the soft-float flag.
>
> All of them, with the exception of the u-boot packages, are written in
> Pascal. It seems that fpc just emits the wrong flags. As an example,
> here is the readelf output for the armhf version of cqrlog. Note that
> Tag_ABI_VFP_args is not set either.
...
> Full list of armhf packages shipping ELF objects with the soft-float
> flag set:
...
> u-boot-rockchip
> u-boot-rpi
> u-boot-sunxi
> u-boot-tegra

For u-boot, the boot process for some boards may include components that
are running baremetal and are not strictly armhf-capable, so that is not
hugely surprising...

Maybe there are some performance gains to be hard, but as long as u-boot
can load a kernel and successfully boot into userspace on these
platforms, I would not be too worried about weather hard-float is
enabled for these targets.

live well,
  vagrant


signature.asc
Description: PGP signature

Re: RFC: android-style boot image support for flash-kernel

[Vagrant Cascadian]

On 2023-04-30, Roger Shimizu wrote:
> I'm trying to support an ARM based RB3 / DB845c [1] dev-board with
> android-style boot image to flash-kernel.
...
> My question is:
> - Currently flash-kernel is mainly u-boot based, is it proper to add
> "mkbootimg" based devices?

My main worry here is investing too much in flash-kernel, rather than
replacing it... both require possibly significant effort, and I wonder
if that effort would not be better spent writing a more modular
replacement for flash-kernel? That said, I have not mustered the energy
to do this myself...

To some degree, I have been the de-facto maintainer for flash-kernel,
but I am hesitant to make significant changes to it... it is not easy
code to read...


> - Does mkbootimg need to support udeb in order to support D-I for this
> dev-board in the future?

I *think* that the udeb (indirectly?) calls flash-kernel inside the
chroot... so I am not sure that would be necessary. There's no
"u-boot-tools" udeb, and many boards use mkimage from "u-boot-tools".


> gzip -c9 /boot/vmlinuz-6.1.0-8-arm64 > vmlinuz.gz
> cat vmlinuz.gz /usr/lib/linux-image-6.1.0-8-arm64/qcom/sdm845-db845c.dtb > 
> Image
> mkbootimg \
> --kernel Image \
> --ramdisk /boot/initrd.img-6.1.0-8-arm64 \
> --output boot.img \
> --pagesize "4096" \
> --base "0x8000" \
> --kernel_offset "0x8000" \
> --ramdisk_offset "0x100" \
> --tags_offset "0x100" \
> --cmdline "root=PARTLABEL=rootfs console=tty0
> console=ttyMSM0,115200n8 clk_ignore_unused pd_ignore_unused"

That seems "simple" enough, given you're using a Debian packaged kernel
and all. Not so different from the mkimage-style support for u-boot.

It is a frustrating that there are so many ways to boot arm systems...
but that is the reality out there actually implemented in hardware...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: What happened to "u-boot" package for Debian testing distribution on Cubox-i

[Vagrant Cascadian]

On 2023-02-23, Rick Thomas wrote:
> I just noticed that there are no versions of the package "u-boot" available 
> on my SolidRun CuBox-i.
> However there is a version of "u-boot-imx" available which contains the 
> actual binary
> code for this machine.
> Interestingly, I have other arm-based boxes and none of them have this 
> problem.

u-boot (2023.01~rc4+dfsg-2) unstable; urgency=medium
...
  * debian/control: Drop u-boot meta-package for armhf and mips.
...
 -- Vagrant Cascadian   Thu, 05 Jan 2023 19:38:24 -0800

I had meant to deprecate it back in ... maybe 2016 or 2018 and finally
remembered to do it this release cycle!

The actual binaries you are using come from u-boot-imx since u-boot
2014.x versions...


live well,
  vagrant

Re: Support for Orange Pi 4 LTS

[Vagrant Cascadian]

On 2023-02-10, Diederik de Haas wrote:

Nice summary!

> On Friday, 10 February 2023 16:57:07 CET Andrew M.A. Cater wrote:
>> On Fri, Feb 10, 2023 at 09:06:10AM +0100, Christian Marillat wrote:
>> > Is Orange Pi 4 LTS (arm64) supported in Debian.
...
>> OrangePi themselves have a version of Debian Bullseye server and Debian
>> Bullseye xfce desktop available.
>
> If you have a working bootloader which (successfully) starts 'some' kernel 
> and 
> combine that with a userland created by f.e. debootstrap and you have a 
> working Debian-like system.
>
> The problem with most BSPs is this: The device/chipset vendor proved with it 
> that the device/SBC works and can run Linux. And then they throw it over the 
> wall and 'say' "have fun with it" (our job is done).
>
> I'm going to assume that "supported *in* Debian" (emphasis mine) means 
> whether 
> it's supported by all-and-only Debian packages.
>
> For that you need 2 things:
> 1) device/SBC is supported by *upstream* u-boot

If it lacks u-boot but has a workable UEFI implementation, you do not
generally need u-boot.


> 2) device/SBC is supported by the *upstream* kernel
>
> And that is where most SBCs are lacking, unless the SBC manufacturor or (more 
> commonly) the community around it, works to upstream all the needed bits.

> So it all comes down to upstreaming all the needed parts.
>
> Wrt kernel support: if there is a .dts file for your board in Linus' tree, 
> that's usually a *very* encouraging sign. That doesn't automatically mean 
> everything is fully supported, but at least some attempt to get it merged 
> upstream has been successful.
> *If* that's the case, then you need to figure out which kernel modules are 
> needed for your device and whether they are enabled in Debian's kernel.
> Debian's kernel config is distinct from what is enabled in some (upstream's) 
> *defconfig* file.
> So you'd need to build a kernel to verify that it works with those 
> (additional) kernel modules and if that's the case you can either file a bug 
> against the kernel requesting those module to get enabled and/or you can 
> submit a MR to the kernel-team's salsa repo.

... and ideally also track down which kernel .udeb packages to add those
modules to as well, so that it can be supported in
debian-installer... and if all goes well, adding bootable images for
debian-installer.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: neon: armhf baseline for next release ?

[Vagrant Cascadian]

On 2023-02-10, Mathieu Malaterre wrote:
> On Thu, Feb 9, 2023 at 8:43 PM Andreas Tille  wrote:
> [...]
>> according to the build logs[1] armhf fails to build (as only
>> architecture) with
> [...]
>> LLVM ERROR: Symbol not found: __sync_fetch_and_add_4
>
> I see that abel.d.o porterbox is offline. There is currently no other
> porterbox for a DD to actually check armhf code on neon-less machine.
>
> Would it be possible to raise the armhf baseline to have some minimal
> neon instructions ?

I am pretty sure the answer in the short term is "no", as that would
effectively be a new architecture... longer term, "maybe someday ... but
not terribly likely"?

Mostly because 32-bit arm is arguably a legacy platform; there is little
to no new debian-capable hardware coming out, and so adding support for
an entire new port seems unlikely, or at the very least, a very niche
target. Either it supports armhf as it is, or more likely it supports
arm64.

For an individual package that wants to make use of neon, the correct
thing to do is to make the neon support detected at run-time rather than
rely on it at build-time and enabling or disabling codepaths, features,
etc. as appropriate.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Can we get a signature for armhf SD-card images?

[Vagrant Cascadian]

On 2023-01-31, Larry Doolittle wrote:
> Friends -
>
> I looked and wasn't able to find a digital signature for
> the SHA256SUMS file in
>   
> http://ftp.debian.org/debian/dists/bullseye/main/installer-armhf/current/images/
> or
>   
> http://ftp.debian.org/debian/dists/bookworm/main/installer-armhf/current/images/

Take a look at:

  https://ftp.debian.org/debian/dists/bullseye/Release

The Release file is signed(either inline as InRelease or detatched as
Release.gpg), and has checksums for the relevent SHA256SUMS files that
you are looking for...


> Am I blind?

It is admittedly a bit indirect and non-obvious, having to download a
Release file, check the signature on that, then download the relevent
SHA256SUMS files and check their checksums with the (verified) Release
file... but there is at least a chain of verifyability...


> Can the process be adjusted to generate such a signature file?

It would be nice to have fewer steps to verify, because any complicated
verification process quickly downgrades to no verification process...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Bug#1029543: hw-detect: clarify use cases about searching for firmware packages on external media

[Vagrant Cascadian]

On 2023-01-26, Cyril Brulebois wrote:
> Vagrant Cascadian  (2023-01-25):
>> Though a larger image would take a bit longer and burn a few extra
>> write cycles for those who did not need to actually use the space.
>
> I have no idea how much people care how much time is spent copying things
> around, but I suppose that at least for those repeatedly copying things
> around (e.g. for debugging purposes), more writes could mean accelerated
> wear-and-tear?

Nor I, really... so yes, just some extra writes that might be needless
in most cases.


>> I do not know that we are all that size-constrained; it is hard to come
>> by USB sticks or SD cards that are less that 4GB these days. So even
>> bumping the image size to 500MB or even 1GB does not seem unreasonable
>> to me... I would rather err on the side of slightly larger than
>> currently needed; maybe there are use-cases I am not considering?
>
> Yeah, I've seen you notice that you were aiming to allow for a little more
> room, when you bumped sizes, rather than increasing them minimally. I'm
> just wondering whether it makes sense (how often is that really useful?).

It is mostly useful with new kernel versions where the module
names/dependencies/indirect-dependencies have changed between kernel
versions, and I haven't yet figured out which kernel modules go in which
.udeb files.  Similar for new boards, just trying to figure out which
modules are needed at all.

The main approach I use is appending all modules (or more selective
modules) from /lib/modules/VERSION/ in a cpio archive that is appended
to the debian-installer initrd.gz... then compare the lsmod results from
a booted d-i... it is not the simplest process with many iteration
cycles; any reduction in required steps is a huge benefit for that!

It does seem similar to the use-case of loading extra firmware in the
installer... appending selective firmwares or all the firmwares to the
initrd as a way to make sure it is loadable early in debian-installer.


Another use-case for more-free-space-by-default are things like
raspberry pi boot firmware, which need to be loaded from the 1st FAT
partition on the microSD. Do not recall off the top of my head how large
rpi boot firmware is. I have manually copied it onto debian-installer SD
card images in the past, possibly doing a partition/filesystem resize
dance...


>> Another option is to concatenate the firmware part directly to the
>> initrd image manually, though it is a bit of a cumbersome
>> process... soemthing like:
>> 
>>   gunzip partition.img
>>   mount -o loop partition.img /mnt
>>   cat kernelfirmware.cpio.gz >> /mnt/initrd.gz
>>   umount /mnt
>>   zcat firmware.BOARD.gz partition.img > complete.img
>
> That looks much easier than anything we could come up with if we were
> trying to concatenate 3 parts (the third one would need to be created
> depending on the first one — fat or ext2). Requiring mount could be
> considered a tad dangerous, but big red warnings and all that…

Ok, good!


>> Though I realize that is quite a few extra steps for an already slightly
>> complicated manual two-part SD card image process... but it could
>> probably be scripted; it is not absurdly complicated. (presuming you
>> have the kernel-firmware.cpio.gz creation sorted out)
>
> I'm working on it right now, trying to also reduce code duplication in
> debian-cd for easier long-term maintenance. I should have some proof of
> concept by tomorrow, but we need to find a better location that under
> unrelease/, so it won't be deployed right away.

Yeah, figured that was in-process :)


>> Another option would be to use a growable filesystem, and then grow it
>> to whatever size needed? Are FAT filesystems reasonably growable?
>
> Just to be sure, are we talking about something like the following?
>  - cat both parts as usual to get complete_image.img (via README);
>  - fallocate to make it bigger for those who want more stuff;
>  - fdisk to extend the partition to the new end of disk (making sure
>not to change the beginning, firmwares are picky as you know; not
>lose the signature, etc);
>  - fatresize or resize2fs to extend the filesystem;
>  - mount, copy, umount;
>  - hope that none of this changed tricky parts that would break the
>board-specific firmare/bootloader/config/etc.

Yeah, that is basically what I was thinking.

The biggest pain point is some boot firmware likes to be on particular
raw offsets. Some offsets are incompatible with GPT (allwinner)... some
load data from offsets that edge into 4MB (ti?) or even 16MB
(rockchip!)... I think most partitioning tools default to creating with
a 2MB offset for the first partition. Some models of raspberry pi
require the boot firmare to be on the 1st fat partition.

Re: Bug#1029543: hw-detect: clarify use cases about searching for firmware packages on external media

[Vagrant Cascadian]

On 2023-01-25, Cyril Brulebois wrote:
> Cyril Brulebois  (2023-01-24):
...
> # SD card images (might also be applicable to the upcoming ChromeOS images)
>
> Looking at how those images are built, it seems we have a predefined,
> per-arch image size (150M or 200M), and gen-hd-image that's called in two
> modes: firmware or partition. The former takes care of the board-specific
> part (e.g. firmware.a64-olinuxino.img.gz) while the latter takes care of
> the board-independent part (partition.img.gz). Both can be concatenated
> with the following command as documented in the README:
>   
> https://deb.debian.org/debian/dists/bullseye/main/installer-arm64/current/images/netboot/SD-card-images/README.concatenateable_images
>
> zcat firmware..img.gz partition.img.gz > complete_image.img
>
> And that works, generating an image with a single fat16, fat32, or ext2
> partition with contents merged together, because of the pre-defined image
> size.
>
> We could think about bumping the image size, but given the size of the
> firmware directory (as in containing the firmware-* packages and metadata,
> not the board-specific firmware files), this would seem like a waste of
> space for all those not needing firmware files (probably requiring twice
> the current size to make sure everything fits)…

Well, empty space does compress quite well, at least!

Though a larger image would take a bit longer and burn a few extra write
cycles for those who did not need to actually use the space.

I do not know that we are all that size-constrained; it is hard to come
by USB sticks or SD cards that are less that 4GB these days. So even
bumping the image size to 500MB or even 1GB does not seem unreasonable
to me... I would rather err on the side of slightly larger than
currently needed; maybe there are use-cases I am not considering?

Another option is to concatenate the firmware part directly to the
initrd image manually, though it is a bit of a cumbersome
process... soemthing like:

  gunzip partition.img
  mount -o loop partition.img /mnt
  cat kernelfirmware.cpio.gz >> /mnt/initrd.gz
  umount /mnt
  zcat firmware.BOARD.gz partition.img > complete.img

Though I realize that is quite a few extra steps for an already slightly
complicated manual two-part SD card image process... but it could
probably be scripted; it is not absurdly complicated. (presuming you
have the kernel-firmware.cpio.gz creation sorted out)

This technically only requires changing the size of the partition.img to
make more room for the kernel firmware image, but otherwise would be
identical to the current process for those who did not need to add the
firmware.

Another option would be to use a growable filesystem, and then grow it
to whatever size needed? Are FAT filesystems reasonably growable?

Thanks for all your work on this!

live well,
  vagrant


signature.asc
Description: PGP signature

Re: debian installer on rock64

[Vagrant Cascadian]

On 2023-01-13, Vagrant Cascadian wrote:
> On 2023-01-13, Diego Roversi wrote:
>> I got this error:
>>
>> [1.806958] List of all partitions:
>> [1.807299] No filesystem could mount root, tried:
>> [1.807304]
>> [1.807892] Kernel panic - not syncing: VFS: Unable to mount root fs on 
>> unknown-block(0,0)
>> [1.808637] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0-1-arm64 #1  
>> Debian 6.1.4-1
>> [1.809357] Hardware name: Pine64 Rock64 (DT)
>>
>>   It looks like the kernel don't see the mmc (or the initrd.gz from
>>   ram).
>
> Yeah, from the log it looks like the initrd was never loaded. Wild guess
> would be the partition is too small to hold the initrd, presuming you
> used the GTK installer... 

I did test images from
https://d-i.debian.org/daily-images/arm64/20230113-02:28/netboot/SD-card-images/
seem to work fine for me.

  zcat firmware.rock64-rk3328.img.gz partition.img.gz | dd of=/dev/SOMEDEVICE 
bs=4096k

live well,
  vagrant


signature.asc
Description: PGP signature

Re: debian installer on rock64

[Vagrant Cascadian]

On 2023-01-13, Diego Roversi wrote:
>   today I've tested bookworm debian-installer from 
> https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/ on a 
> rock64 but it didn't boot. 

Did you use the GTK images or the "regular" images?

>
> I got this error:
>
> [1.806958] List of all partitions:
> [1.807299] No filesystem could mount root, tried:
> [1.807304]
> [1.807892] Kernel panic - not syncing: VFS: Unable to mount root fs on 
> unknown-block(0,0)
> [1.808637] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0-1-arm64 #1  
> Debian 6.1.4-1
> [1.809357] Hardware name: Pine64 Rock64 (DT)
>
>   It looks like the kernel don't see the mmc (or the initrd.gz from
>   ram).

Yeah, from the log it looks like the initrd was never loaded. Wild guess
would be the partition is too small to hold the initrd, presuming you
used the GTK installer... the regular installer appears to load an
initrd ok for me. (although I kind of cheated, installing u-boot
independently and dumping the partition onto a device)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Bug#1016963: Help with testing u-boot!

[Vagrant Cascadian]

On 2022-12-28, Rick Thomas wrote:
> A Cubox-i running Debian bullseye (11.6).  According to  versions> It has "u-boot-tools" (version 2021.01+dfsg-5) installed,
> but none of the u-boot- packages installed.
>
> If I reboot it and watch the serial console, I see it showing "U-boot
> 2021.01-dfsg-5" so that version must have gotten into the firmware
> somehow without telling Linux about it... 

Installing the packge does not install u-boot to the boot media, it is a
manual process, as it can be board-specific.


> Other info that might be helpful that shows with the reboot is
> CPU: Freescale i.MX6Q rev 1.3
> Board: MX6 Cubox-i

For Cubox-i install u-boot-imx and see
/usr/share/doc/u-boot-imx/README.Debian for instructions on how to
actually install the boot firmware onto microSD.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Help with testing u-boot!

[Vagrant Cascadian]

On 2022-12-29, Diederik de Haas wrote:
> On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote:
>> debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
>> and experimental (2023.01-rc*)
>>
>> # arm64
>> ...
>> rock64-rk3328
>
> I don't recall ever having issues with u-boot on my Rock64's, so for me 
> 2022.04 - 2022.10 surely work. I'll try the experimental version soon.

I have been testing that one, but thanks for the extra testing!


> I generate my own images for Rock64 and that uses 'dd ... seek=' of 
> idbloader.img and u-boot.itb from the u-boot-rockchip package.
> I have been doing that since 2021-03, so it's very likely that I haven't seen 
> an issue since then.

u-boot-rockchip also includes a u-boot-install-rockchip script which
might simplify the process for you. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Help with testing u-boot!

[Vagrant Cascadian]

On 2022-12-29, gene heskett wrote:
> On 12/28/22 19:17, Diederik de Haas wrote:
>> On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote:
>>> debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
>>> and experimental (2023.01-rc*)
...
> But a bpi m5 makes no attempt to boot it green led remains dim
> forever.

Presuming you mean bananapi-m5, it is not enabled yet in the Debian
packages of u-boot...

> I can mount it in my reader, a iso-9660 and its not a u-boot, its
> grub. So which of the arm64 iso's is u-booter?

None of the debian-installer iso images contain u-boot. They only work
with systems with EFI firmware installed (which, somewhat confusingly,
u-boot could provide in some cases).

U-boot is board-specific, so a single image will almost never support
booting more than a very small number of systems.

Supported debian-installer platforms that have at some point in history
been tested to work are:

  https://d-i.debian.org/daily-images/arm64/daily/u-boot/

There are SD card images you can build, see the
README.concatenatable_images at:

  https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/

You can typically using the firmware.none.img and manually add
u-boot. Which offsets to write to are board-specific, though there are
often common patterns for various board families (e.g. sunxi SoCs mostly
have the same offsets, rockchip SoC mostly use same offsets)...


The bananapi-m5 appears to be amlogic based, and there are a few other
amlogic based boards enabled in Debian's u-boot-amlogic package, but
unfortunately they require quite a few extra hoops to jump through that
make it difficult for Debian to ship images that you can just write to
boot media.

There are hints at fixing part of the problem at
u-boot.git/doc/board/amlogic/libretech-cc.rst:

  Note that Amlogic provides aml_encrypt_gxl as a 32-bit x86 binary with no
  source code. Should you prefer to avoid that, there are open source reverse
  engineered versions available:
  
  1. gxlimg <https://github.com/repk/gxlimg>, which comes with a handy
 Makefile that automates the whole process.
  2. meson-tools <https://github.com/afaerber/meson-tools>
  
  However, these community-developed alternatives are not endorsed by or
  supported by Amlogic.


live well,
  vagrant


signature.asc
Description: PGP signature

Help with testing u-boot!

[Vagrant Cascadian]

On 2022-12-22, Vagrant Cascadian wrote:
> On 2022-08-20, Vagrant Cascadian wrote:
>> On 2022-08-10, Vagrant Cascadian wrote:
>>> This bug is just to delay migration to testing while more platforms get
>>> tested. If you have a relevent board, please consider testing and
>>> reporting the status:
>>>
>>>   https://wiki.debian.org/U-boot/Status

I have not received many test results for current or even remotely
recent u-boot platforms in Debian, and u-boot has been blocked from
migration to testing partly because of this.

As the bookworm freeze approaches, this is getting to be... worrysome!

If you have access to any of these boards, please consider testing
u-boot versions as packaged in debian for versions from debian stable
(2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
(2023.01-rc*) and updating the wiki page if successful and/or replying
to 1016...@bugs.debian.org with a positive confirmation...

...and if not successful, filing bugs against the relevent u-boot-*
packages and marking them as blocking 1016963.

# arm64
khadas-vim
khadas-vim2
libretech-cc
nanopi-k2
odroid-c2
odroid-n2
mvebu_espressobin-88f3720
dragonboard410c
dragonboard820c
firefly-rk3399
nanopc-t4-rk3399
nanopi-neo4-rk3399
pinebook-pro-rk3399
puma-rk3399
roc-pc-rk3399
rock-pi-4-rk3399
rock-pi-e-rk3328
rock64-rk3328
rockpro64-rk3399
rpi_3
rpi_4
rpi_arm64
a64-olinuxino
a64-olinuxino-emmc
nanopi_neo2
nanopi_neo_plus2
orangepi_one_plus
orangepi_zero_plus2
pine64-lts
pine64_plus
pinebook
pinephone
pinetab
sopine_baseboard
teres_i
p2371-2180

# armel
dockstar
dreamplug
guruplug
sheevaplug
rpi
rpi_0_w

# armhf
arndale
odroid
odroid-xu3
colibri_imx6
dh_imx6
mx53loco
mx6cuboxi
mx6qsabrelite
nitrogen6q
novena
novena-rawsd
udoo
usbarmory
wandboard
am335x_boneblack
am335x_evm
am57xx_evm
dra7xx_evm
igep00x0
nokia_rx51
omap3_beagle
omap4_panda
firefly-rk3288
rpi_2
rpi_3_32b
rpi_4_32b
stm32mp157c-dk2
A10-OLinuXino-Lime
A10s-OLinuXino-M
A20-OLinuXino-Lime
A20-OLinuXino-Lime2
A20-OLinuXino-Lime2-eMMC
A20-OLinuXino_MICRO
A20-OLinuXino_MICRO-eMMC
A20-Olimex-SOM-EVB
Bananapi
Bananapi_M2_Ultra
Bananapro
CHIP
Cubieboard
Cubieboard2
Cubieboard4
Cubietruck
Cubietruck_plus
Lamobo_R1
Linksprite_pcDuino
Linksprite_pcDuino3
Mini-X
Sinovoip_BPI_M3
bananapi_m2_berry
nanopi_neo
nanopi_neo_air
orangepi_plus
orangepi_zero
jetson-tk1


Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

On the existance of arm* porters

[` Vagrant Cascadian]

On 2022-08-25, Graham Inggs wrote:
> On Wed, 16 Feb 2022 at 13:36, John Paul Adrian Glaubitz
>  wrote:

>> it seems superficially plausible that the march=native
>> invocations are just instances of the compiler being probed.
>
> I have also had a look and cannot see that '-march=native' is used in
> the actual builds on any of the architectures.
>
> It would be very much appreciated if the arm porters could take a look
> at this issue, as it still plagues the scikit-learn autopkgtests on
> armhf [2], and currently prevents quite a number of packages from
> being part of testing.  It appears that armel [1] has the same error,
> so hopefully one fix could resolve both.

I pretty much think of myself, at best, as half an armhf/arm64 porter,
but this is a little bit outside of the scope of what I offered to look
after in the porter roll calls...

Apparently I am the only porter for armhf and arm64? I had assumed there
would be someone else to fill the gaps in my skillset, but I guess
not.

Help?

live well,
  vagrant


signature.asc
Description: PGP signature

Re: failure trying to install bullseye on Cubox-i

[Vagrant Cascadian]

On 2022-07-17, Rick Thomas wrote:
> I'm experimenting with installing Bullseye on a Cubox-i4Pro I keep around for 
> testing purposes.
>
> I followed the instructions at:
> 
> http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/current/images/netboot/SD-card-images/README.concatenateable_images


> Then I dd'ed the resulting complete image onto an 8GB microSD card,
> which I then inserted into the microSD slot in the Cubox-I.  When I
> applied power, I got the attached log on the serial console.

Those sound like reasonable steps...

What's confusing is your screen logs shows a u-boot from bookworm/sid:

  U-Boot SPL 2022.04+dfsg-2+b1 (May 14 2022 - 21:25:25 +)

So either the images you downloaded were not the images you thought you
downloaded... or you saved the wrong screenlog file... or the bullseye
images contain u-boot from the wrong release... or somehow you're
loading u-boot from some other media, such as eMMC?

I actually need to reinstall a cuboxi4pro maybe by the end of the week,
so I will test it myself then.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: armhf kernels on arm64 hardware

[Vagrant Cascadian]

On 2022-07-15, woo...@wookware.org wrote:
> The question from Debian's POV is how many other people want to use
> non-native arm kernels (and for what?). How many platforms is it
> relevant to? And if there is a downside, how many does that effect,
> and how/how much.

For Reproducible Builds testing of armhf packages I run several machines
(some physical, some virtual) with arm64 kernel and armhf userland, and
it basically works.

It is a little tricky to set up multi-arch to be able to get the
linux-image-arm64 kernel from arm64 without pulling in all the
recommends on various :arm64 packages, but once it is set up, it works
fine...

I have no idea how difficult it would be to add multi-arch support to
debian-installer, but it is not too hard to build an image using
"mmdebstrap" that supports a linux-image-arm64:arm64 kernel on an armhf
userland.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: cubox-i does not boot after upgrade to bullseye

[Vagrant Cascadian]

On 2021-12-29, Uwe Kleine-König wrote:
> On 12/28/21 13:46, Rainer Dorsch wrote:
>> Am Dienstag, 28. Dezember 2021, 11:47:37 CET schrieb Uwe Kleine-König:
>>> I can recommend barebox here instead of U-Boot. i.MX is the probably
>>> best supported platform for it and I would expect the cubox-i to be
>>> directly supported.
>>>
>>> Barebox can mount various filesystems and if there is a bootspec entry
>>> in your rootfs (e.g. flash-kernel can write such an entry) you can just do:
>>>
>>> boot /mnt/mmc0.0
>>>
>>> to let barebox pick the kernel, initrd and dtb from the filesystem on
>>> mmc0.0 and pass root=UUID=$therightone.
>> 
>> Thanks for the advice. Is barebox already packaged for Debian and I just 
>> don't
>> find it or do I need to install it from non-Debian sources?

I briefly tried barebox and must say I liked it; if it's supported by a
platform you use I can definitely recommend trying barebox!  The shell
felt more like a bourne shell (e.g. bash) than u-boot and maybe a bit
more comfortable for someone not already familiar with u-boot...


> It's not yet packaged, there is only an ITP, which waits for some effort 
> to convert barebox to SPDX. https://bugs.debian.org/900958

That looks to be *mostly* done, from a quick glance.

Looking forward to seeing it in Debian!


live well,
  vagrant

Re: Solved: cubox-i does not boot after upgrade to bullseye

[Vagrant Cascadian]

On 2021-12-29, Rainer Dorsch wrote:
> Am Mittwoch, 29. Dezember 2021, 19:33:20 CET schrieb Vagrant Cascadian:
>> If you've used "saveenv" to save the u-boot environment variables, even
>> if you upgrade u-boot, the environment will remain frozen in the state
>> when you ran "saveenv".
>> 
>> I strongly discourage using "saveenv" as this makes upgrading u-boot
>> more difficult as you end up with inconsistent values between the u-boot
>> version you're running and the environment you've saved.  This will
>> often work fine, although as you've discovered, sometimes updates to the
>> environment fixes bugs.
>> 
>> You have to erase or overwrite the environment area on the microSD to
>> get new defaults; not sure off the top of my head where exactly this is
>> for the cubox-i.
>> 
>> If there is no saved environment, u-boot uses built-in defaults from the
>> version of u-boot you're running.
>
> Wouldn't 
>
> => env default -a
>
> enforce a reset to a default environment 
>
> https://www.vermasachin.com/posts/3-u-boot-environment-variables/

Only for the running u-boot, it will load from the environment at next
boot... and if you use saveenv, it will save exactly that
environment... and possibly some other quirks such as missing or changed
auto-detected environment variables at boot which can cause
inconsistancies if you then run saveenv.

To really reset it for the cubox-i, you need to overwrite at least the
beginning of address 0xFE000 on your boot media:

  $ grep ENV configs/mx6cuboxi_defconfig
  CONFIG_ENV_SIZE=0x2000
  CONFIG_ENV_OFFSET=0xFE000

The mx6cuboxi defconfig should also be findable in
/usr/share/doc/u-boot-imx/configs/ if you have u-boot-imx:armhf
installed.


live well,
  vagrant

Re: cubox-i does not boot after upgrade to bullseye

[Vagrant Cascadian]

On 2021-12-29, Rainer Dorsch wrote:
> Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian:
>> If you can  insert the microSD into another Debian  machine, you can get
>> the UUID  by looking in  /dev/disk/by-uuid/ to find the  matching device
>> or:
>> 
>>   lsblk --fs /dev/DEVICE
>> 
>> It might be possible to discover from u-boot as well, but I forget off
>> the top of my head.
>
> There is
>
> => part uuid mmc 1:2
> 8ad3fb70-02
> => part uuid mmc 1:3
> 8ad3fb70-03
> => 
>
> but  "root=UUID=8ad3fb70-03" is not working for mounting the rootfs.
>
> In the bullseye installation, there is also a variable defined finduuid
>
> finduuid=part uuid mmc 0:1 uuid
>
> which is even called by bootcmd, but I am not sure if that is doing anything 
> useful.

That *may* be a partition UUID, rather than a filesystem
UUID... initramfs-tools 0.121 and newer supports using
root=PARTUUID=...

You can see the available partition uuids on linux in
/dev/disk/by-partuuid/


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Solved: cubox-i does not boot after upgrade to bullseye

[Vagrant Cascadian]

On 2021-12-29, Rainer Dorsch wrote:
> The root cause of the new kernel not booting was that the memory addresses 
> for 
> kernel and initrd.img in the u-boot environment have probably changed during 
> this or a previous Debian release.
>
> A new installed bullseye system uses
>
> kernel_addr_r=0x1200
> ramdisk_addr_r=0x1300
> fdt_addr_r=0x1800
>
> On the upgraded system
> kernel_addr_r=0x1080
> ramdisk_addr_r=0x1180
> fdt_addr_r=0x1800
>
> was used. Changing these variable to the new values fixed the issue. Many 
> thanks for all the advice I got.

Glad you figured it out!


From your original report:

  U-Boot SPL 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43)   
  
  U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43)   
  

Looks like you never upgraded u-boot. The u-boot packages do not upgrade
u-boot on your boot media; you have to manually install u-boot when you
want to upgrade it.

There's a discussion about the challenges of automatically installing or
upgrading u-boot:

  https://bugs.debian.org/812611

The short of it is, some boards are trickier than others and it is
difficult to detect which environments are reasonable safe to do so
automatically.


> I assume this is because the u-boot environment variables are not changed 
> during an upgrade of u-boot or to a new Debian release.

Yes, neither u-boot components nor the saved environment are
(re)installed on upgrade.


> Judging from the upgrade typescripts, the system was originally installed 
> with 
> Jessie (Debian 8).
>
> The u-boot environment variables of the newly installed system are very 
> different from the ones in the upgraded system.
>
> Is there an easy way to copy all the u-boot environment variables from the 
> old 
> system to the new system?

If you've used "saveenv" to save the u-boot environment variables, even
if you upgrade u-boot, the environment will remain frozen in the state
when you ran "saveenv".

I strongly discourage using "saveenv" as this makes upgrading u-boot
more difficult as you end up with inconsistent values between the u-boot
version you're running and the environment you've saved.  This will
often work fine, although as you've discovered, sometimes updates to the
environment fixes bugs.

You have to erase or overwrite the environment area on the microSD to
get new defaults; not sure off the top of my head where exactly this is
for the cubox-i.

If there is no saved environment, u-boot uses built-in defaults from the
version of u-boot you're running.


> Does SPL get upgraded with the u-boot upgrade?

Also a manual upgrade process.


> I summarized my learnings in the Debian Wiki:
> https://wiki.debian.org/InstallingDebianOn/SolidRun/CuBox-i#Boot_Process
> and checked it on a second cubox-i device.

Most of what you've written is not specific to cubox-i, but kind of how
to navigate u-boot in general.

I would not recommend the use of saveenv for the reasons described
above.

The mmc device enumeration may not be the same across u-boot and linux;
e.g. mmc 0 in u-boot will not necessarily be /dev/mmcblk0 in
linux. Sometimes it even varies by boot.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: First W95 FAT32 (LBA) Partition in bullseye Installation of cubox-i

[Vagrant Cascadian]

On 2021-12-28, Rainer Dorsch wrote:
> just for curiosity, on a new bullseye installation of a cubox-i, there is a  
> W95 FAT32 (LBA) partition created as first partition. It contains a boot 
> setup:
>
> root@bc-text:~# mount /dev/mmcblk1p1 /mnt/
> root@bc-text:~# ls -l /mnt/
> total 27026
> -rwxr-xr-x 1 root root 1575 Dec 13 16:23 boot.scr
> drwxr-xr-x 2 root root75264 Dec 13 16:23 dtbs
> -rwxr-xr-x 1 root root 22636034 Dec 13 16:23 initrd.gz
> -rwxr-xr-x 1 root root  4960768 Dec 13 16:23 vmlinuz
> root@bc-text:~#
>
> I am just wondering, why that is there. Is it an installation process 
> leftover 
> or a kind or a rescue kernel? If rescue kernel is there a bootcmd available?

This looks like a partition of the debian-installer image you presumably
used to install the system.

You could use it to start debian-installer if you manually load the
boot.scr from there.


live well,
  vagrant

Re: cubox-i does not boot after upgrade to bullseye

[Vagrant Cascadian]

On 2021-12-27, Rainer Dorsch wrote:
> Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian:
>> Very likely; it is not promised to remain constant even between boots
>> with the same kernel, unfortunately!
>> 
>> You really want to use root=UUID=abcde-12345... or partition labels, or
>> anything that isn't going to have surprise changes...
>
> Hmm...I think the problem is something different. 
>
> I inserted the SDcard in a different Linux-System and I extracted the UUID:
>
> root@h370:~# lsblk --fs /dev/sdc2
> NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% 
> MOUNTPOINT
> sdc2 ext4   1.0 233113e0-67d1-409f-b2c0-57bd496213de
> root@h370:~#
>
>
> I manually loaded now the kernel in uboot (does the manual sequence look 
> reasonable?):
...
> CuBox-i U-Boot > load mmc 0:1 0x1080  vmlinuz-5.10.0-10-armmp
> 4960768 bytes read in 380 ms (12.4 MiB/s)
> CuBox-i U-Boot > load mmc 0:1 0x1800  dtbs/5.10.0-10-armmp/imx6q-cubox-
> i.dtb
> 37880 bytes read in 254 ms (145.5 KiB/s)
> CuBox-i U-Boot > load mmc 0:1 0x1180  initrd.img-5.10.0-10-armmp
> 24040022 bytes read in 1551 ms (14.8 MiB/s)

I would use $kernel_addr_r, $fdt_addr_r and $ramdisk_addr_r instead of
hard-coded values.


> CuBox-i U-Boot > setenv bootargs " ${bootargs} enable_wait_mode=off  
> root=UUID=233113e0-67d1-409f-b2c0-57bd496213de  rootfstype=ext4  ro rootwait  
> console=ttymxc0,115200  console=tty1 break"
> CuBox-i U-Boot > printenv bootargs
> bootargs=  enable_wait_mode=off  
> root=UUID=233113e0-67d1-409f-b2c0-57bd496213de  
> rootfstype=ext4  ro rootwait  console=ttymxc0,115200  console=tty1 break

All you should really need are:

  root=UUID=... console=ttymxc0,115200 console=tty1


> CuBox-i U-Boot > bootz 0x1080 0x1180: 0x1800

You might want instead:

  bootz $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r

The $filesize is (or at least used to be) important, and should be set
to the size of the last file loaded with "load" or similar commands.


> Kernel image @ 0x1080 [ 0x00 - 0x4bb200 ]
> ## Flattened Device Tree blob at 1800
>Booting using the fdt blob at 0x1800
> EHCI failed to shut down host controller.
>Using Device Tree in place at 1800, end 1800c3f7

It looks like it did not load the initramfs, possibly due to not using
$filesize above ... though I would expect an error, because the raw
initrd doesn't contain headers to detect the size, but maybe passing the
empty value after the colon silences that error?


I have several cubox-i systems all running bullseye, so it certainly is
possible! I think they're all using eSATA for both /boot and rootfs,
though I checked that one does detect /dev/mmcblk1 and relevent
partitions for the microSD.

It *might* be possible that there are some missing modules in the
initrd/initramfs to use mmcblk devices, but based on the above it looks
more likely that you're not passing the initrd/initramfs at boot.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: cubox-i does not boot after upgrade to bullseye

[Vagrant Cascadian]

On 2021-12-27, Rainer Dorsch wrote:
> I upgraded a cubox-i from buster to bullseye. The upgrade went through 
> without 
> any issues. But after the upgrade the system does not boot anymore. The 
> output 
> of the serial console is below. The boot process hangs at
>
> [3.816424] Waiting for root device /dev/mmcblk1p2...
>
> Did the device enumeration change?

Very likely; it is not promised to remain constant even between boots
with the same kernel, unfortunately!

You really want to use root=UUID=abcde-12345... or partition labels, or
anything that isn't going to have surprise changes...


> How would I find out the new device name and how would I change the boot 
> parameters (which apparently specifies /dev/mmcblk1p2 according to the output 
> below)?

If you can  insert the microSD into another Debian  machine, you can get
the UUID  by looking in  /dev/disk/by-uuid/ to find the  matching device
or:

  lsblk --fs /dev/DEVICE

It might be possible to discover from u-boot as well, but I forget off
the top of my head.


Once you have the UUID, try passing root=UUID=$uuid in bootparams
instead of root=/dev/mmcblk...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Porter roll call for Debian Bookworm

[Vagrant Cascadian]

On 2021-10-02, Graham Inggs wrote:
>  * Which architectures are you committing to be an active porter for?

armhf, arm64


>  * Please describe recent relevant porter contributions.

Maintaining u-boot (bootloader used on many arm64 and armhf plaforms),
arm-trusted-firmware (arm64 firmware), and occasional debian-installer,
linux and initramfs-tools contributions for specific hardware.


>   I am an active porter for the following architectures and I intend to
>   continue for the development cycle of Debian Bookworm
>   (est. release mid-2023):
>

For armhf and arm64, I:

>   - test (most|all) packages on this architecture

I maintain the armhf build machines for tests.reproducible-builds.org
which currently runs package builds for the whole archive in sid,
experimental, bookworm and bullseye chroots. The build machines are a
mix of arm64 and armhf capable machines.


>   - run a Debian testing or unstable system on port that I use regularly

I run mobian on arm64, which is currently bookworm based, working
towards complete inclusion in debian. I may start using an arm64 laptop
(pinebook pro) regularly, probably running bookworm.


>   - triage arch-specific bugs
>   - fix arch-related bugs
>   - triage d-i bugs
>   - test d-i regularly
>   - fix d-i bugs/issues

Not systematically or regularly, but occasionally as the need arises.


I am a DD.


live well,
  vagrant


signature.asc
Description: PGP signature

systemd reproducibility on armhf

[Vagrant Cascadian]

I finally did a reprotest build of systemd on armhf to try and figure
out why it doesn't build reproducibly... but it built reproducibly...

My test did not test building with a 64-bit kernel (it was using a
32-bit kernel in both cases), whereas the tests.reproducible-builds.org
infrastructure systematically tests one build with 64-bit kernel and one
with a 32-bit kernel...

The build done with a 32-bit kernel includes a reference to
"arm_fadvise64_64", whereas the build with a 64-bit kernel does
not:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/armhf/diffoscope-results/systemd.html

Does fadvise (posix_fadvise?) on 64-bit not need any special handling,
whereas on 32-bit needs a wrapper function of some kind?

Not sure exactly where this behavior comes from(quite possibly in a
dependent library and not systemd itself), but the build features should
be determined from the userland (armhf) that it is built in, and not
from which kernel is running.


Sorry I don't have more conclusive results, but at least this suggests a
direction to look into.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Debian is supported on many arm platforms

[Vagrant Cascadian]

On 2021-09-23, LinAdmin wrote:
> On 10.09.21 21:40, Vagrant Cascadian wrote:
>> On 2021-09-10, LinAdmin wrote:
>>> The unnamed decision makers of Debian some unknown time ago
>>> decided that Pi and *Pine* stuff won't be supported by Debian.

>> This is the second time you've stated this, without really adding
>> meaningful content to the conversation, and people have presented
>> evidence to the contrary... 
...
>> Somewhat of an aside, I feel inclined at this point to bring up the
>> Debian Community Guidelines:
>>
>>   https://people.debian.org/~enrico/dcg/
>>
>> I find it has some valuable thoughts that help improve my contributions
>> to Debian.
...

> So after my posting of 09-20-21 you kept silence ;)

I didn't see anything I could meaningfully add about that particular bug
report... https://bugs.debian.org/981586


> Still wondering why precisely you brought up Debian
> Community Guidelines?

The near-verbatim repetition of an inaccurate claim seemed worth
mentioning; many people *have* in fact worked on improving support for
the rpi and pine64 and other arm* systems in Debian.

What specifically came to mind was:

  Improving the content
  * Ensure you are adding useful information

  https://people.debian.org/~enrico/dcg/ch02s02.html


There were also a few other threads in that discussion going on that I
hoped could go a lot better if people would take a little time to review
the Debian Community Guidelines and work it into the discussions on
debian-arm.


> And btw, not only me feels that "Unfortunately, the Linux desktop
>community is very toxic.  Wars between fans of desktop environments
>(DEs), distributions, package managers, package formats, etc., threats,
>personal attacks, etc. are very common in public chat rooms and
>forums."

It is an unfortunate state of affairs, indeed. Let's try to make sure
debian-arm strives for the best signal-to-noise ratios rather than the
worst. :)


live well, 
  vagrant


signature.asc
Description: PGP signature

Debian (installer) on Pinebook Pro

[Vagrant Cascadian]

On 2021-09-11, Oregano wrote:
> September 11, 2021 11:30 AM, "Peter Ehlert"  wrote:
>> On 9/11/21 1:11 AM, Keith Bainbridge wrote:
>>> Andrei -- happy Debian user of a PINE A64+ and (still) considering
>>> the Pinebook Pro for my next laptop
...
> Debian installer on an SD card ran OK, but wasn't able to
> successfully connect to the network, or install to the EMMC, or
> both. It was probably user error due to not connecting extra power to
> the docking station to get a good ethernet cable connection...

I have had the odd issue, quite repeatable (and confirmed by at least
one other person), where the ethernet on the usb-c docking station (and
various other functions) only work with the usb-c connector is in one
particular orientation; because USB-C isn't *supposed* to require a
particular orientation there's no obvious marking which side is which,
so I have to find it pretty much by trial and error... someday I'll get
clever and mark it when I find the working orientation.

Fairly late in the bullseye release cycle several things got fixed for
the Pinebook Pro; might be worth trying again if you haven't tried
recently!


live well,
  vagrant


signature.asc
Description: PGP signature

Debian Pinebook Pro

[Vagrant Cascadian]

On 2021-09-11, Peter Ehlert wrote:
> On 9/11/21 1:11 AM, Keith Bainbridge wrote:
>> On Tue, 7 Sep 2021 10:01:49 +0300
>> Andrei POPESCU  wrote:
 Andrei -- happy Debian user of a PINE A64+ and (still) considering
 the Pinebook Pro for my next laptop
...
> superior build quality, I really like it, but it is not my daily driver
>
> lurking here for tips on how to get Debian running on it.

I gave a talk (that had some glitches...) at DebConf21 which has bits
and pieces of what I did to make a live image that boots on both the
pinebook and pinebook-pro:

https://debconf21.debconf.org/talks/88-two-pinebooks-walk-into-a-bar/

with video available at:

  https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/

And slides:

  https://salsa.debian.org/vagrant/two-pinebooks-walk-into-a-bar

At some point I'd like to firm up the process for making live images for
arm64... but at the moment it's still a bit ad-hoc, though I've managed
a proof of concept! :)

The next feature I need to work into it would be to add UEFI support,
then it could boot any system with UEFI as well as 1-3 systems with
compatible u-boot offsets...


live well,
  vagrant


signature.asc
Description: PGP signature

Debian is supported on many arm platforms

[Vagrant Cascadian]

On 2021-09-10, LinAdmin wrote:
> The unnamed decision makers of Debian some unknown time ago
> decided that Pi and *Pine* stuff won't be supported by Debian.

This is the second time you've stated this, without really adding
meaningful content to the conversation, and people have presented
evidence to the contrary... 

If you don't want to help, that's fine, but please at least refrain from
making repetative, vague statements of questionable accuracy.

Debian Developers and many other contributors to Debian are in fact
supporting these and many other platforms on Debian... They have done so
by submitting patches, bug reports, fixes, etc. It would be difficult to
create a comprehensive list of all of them. Check the changelogs for the
linux kernel, u-boot, debian-installer, raspi-firmware... there are lots
of people making decisions to support these platforms in those and even
other packages.

Specifically...

There are at least five pine64.org platforms listed at:

  https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/

I believe the same set of images is supported in the Debian bullseye
release. At some point they worked (I personally tested each of them
before adding support), if they don't currently work, please file bug
reports and ideally patches if you can.


While the Raspberry Pi can't fully be supported in Debian "main" due to
the Debian Social Contract and the lack of compatible licenses:

  https://www.debian.org/social_contract

There is support for the non-free firmware in "non-free" since 2019:

  https://tracker.debian.org/pkg/raspi-firmware

More recently, you can get a UEFI implementation for pi3 and pi4:

  https://github.com/pftf

With a UEFI implementation, you can boot the standard debian-installer
.iso images for arm64 platforms:

  https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/
  or
  https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/

And there are "unofficial" images made to be written directly to boot
media produced by Debian Developers available at:

  https://raspi.debian.net



Somewhat of an aside, I feel inclined at this point to bring up the
Debian Community Guidelines:

  https://people.debian.org/~enrico/dcg/

I find it has some valuable thoughts that help improve my contributions
to Debian.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Debian on Pine64 H64B?

[Vagrant Cascadian]

On 2021-09-09, Pete Batard wrote:
> Okay, maybe I didn't express myself properly here, because we're 
> basically on the same page. I am not saying that where possible, Debian 
> should not care about providing what you suggest. I'm only saying that, 
> *WHEN* that is not possible, as is the case on x86 PC and on Pi, Debian 
> should be flexible enough to understand that taking a hard stance so as 
> to penalize users, and declaring "Thou shall not boot this platform with 
> Debian"

I think I missed that decree...  I daresay, this argument has been
running around in circles, based on some false assertions...

For the majority of the lifespan of arm64 in Debian, the *only* boot
method supported by debian-installer was UEFI. A "Bring your own
firmware" sort of policy. Only very recently support for a handful of
platforms to boot using u-boot was added...

And while *technically* non-free isn't a part of Debian, the firmware
required to boot raspberry pi platforms has been in non-free for some
years now. The great compromise in the Debian social contract allows for
exactly this sort of scenario:

  https://www.debian.org/social_contract

  5. Works that do not meet our free software standards

  We acknowledge that some of our users require the use of works that do
  not conform to the Debian Free Software Guidelines. We have created
  "contrib" and "non-free" areas in our archive for these works.

So, the whole idea that supporting booting Debian on the raspberry pi is
not allowed seems absurd to me.

Yes, there are non-free parts required to boot it. Debian cannot ship
those parts in Debian main. Some people choose to spend their time
making those parts easier for others to install, some choose to keep
their distanceand not get entangled in it. We have room for both
approaches.

I'm really greateful people went through the work to get UEFI support
for the Raspberry Pi working; it gives yet another option for people who
want to try that platform on Debian using the standard Debian arm64
installation media. It's a widely used platform and if some people want
to install Debian on it, great!

I am also really happy Debian can support platforms (e.g. pinebook) that
can boot with boot firmware entirely only using software from Debian
"main", without needing "non-free" or "contrib".


In Debian, those who do the work generally define what is and isn't
supported in Debian, with guiding documents like the social contract and
debian policy setting some boundaries and standards.

So, pick something you want to improve, and work on it, and share it
with the rest of us! :)


live well,
  vagrant


signature.asc
Description: PGP signature

Debian on Raspberry Pi and Pine* and probably ARM support in general (was Re: Debian on Pine64 H64B?)

[Vagrant Cascadian]

On 2021-09-04, LinAdmin wrote:
> The unnamed decision makers of Debian some unknown time ago
> decided that Pi and Pine stuff won't be supported by Debian.

I personally have added support in Debian for:

  Raspberry Pi 1
  Raspberry Pi 2b
  Raspberry Pi 3b+
  Pine64+
  Pinebook
  Pinebook Pro
  RockPro64
  Rock64

And other platforms... others have added support for other Raspberry PI
and Pine64 platforms, as well as numerous other platforms...

I used the Pinebook as my primary computer for over a year, using
absolutely zero software from outside of Debian...


Debian isn't a consumer product, it is a community project. It is
largely a volunteer effort, suppored by the community, so... if you want
something supported, please help to add the support.

It pretty much comes down to submitting patches, bug reports, merge
requests, etc. to enabled the appropriate kernel options, bootloader
support, and debian-installer support.

Debian doesn't generally support patches that wouldn't be acceptible in
upstream projects, or support non-free binary blobs out of the box, so
maybe the support isn't as good on a per-platform basis as some other
targeted distros willing to use vendor forks or patches for various
components.


The support isn't always perfect; maybe all features don't always work;
I don't and can't personally test all combinations of features on all
platforms, nor have the time to enable all features on all combinations
of platforms. Thankfully, there are others in the community who test and
improve what they can.

Debian could always use more people helping with testing and perhaps
more importantly, upstreaming of support to make sure it works for their
use-cases...

I know not everybody can dive in and fix all kinds of issues, but there
is a pretty broad spectrum of ways to help out... sometimes things are
even supported but undocumented. Documenting workarounds and filing bug
reports appropriately is one angle that could potentially help.


> I switched to Ubuntu LTS which made me (and many others) happy.

Curious what exactly is different with Ubuntu that makes it work for
you...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: How to install Bullseye on Cubox-i4Pro on USB or eSATA disk?

[Vagrant Cascadian]

On 2021-07-07, Rick Thomas wrote:
> I recently tried installing the two-part image for MX6_Cubox-i from
> [1] on my Cubox-i4Pro.

I'm pretty sure while debugging #982270 (ethernet on imx6 systems), I
managed to get a successfull install to eSATA, though not *positive*
(maybe I just got as far as testing ethernet).

> It worked fine when I installed to an SD card -- I used a 32 GB card
> for the installer and installed to that same card.  But that's kinda
> limited.  The box has USB and eSATA ports that I'd like to be able to
> use, if only because they should be faster than the SD card.

Yeah, I'm running bullseye on a cubox-i4pro from eSATA.

How are you powering your eSATA? I use a eSATA+USB-power adapter to plug
in the SSD, and I'm not sure if it is still required, but I have a
boot.scr on a bootable partiton on microSD which basically does:

  sleep 1
  usb start
  sleep 3

which powers up the USB and then the eSATA has power via the USB, and
allows u-boot to load the kernel+initrd+dtb directly off of a /boot
partition on the eSATA SSD.

You can find this type of cable:

  https://duckduckgo.com/?t=ffab=eSATA+Data+%2B+USB+Powered+Cable=web  

This looks pretty much just like the one I have:

  
https://ae01.alicdn.com/kf/HTB1.fxzNVc1XFXXq6xXFXXX5/2-5-Inch-Hard-Disk-Drive-SATA-22-Pin-to-eSATA-Data-USB-Powered-Cable-NEW.jpg

I don't have a link for the exact one I have.

For a more power-hungry disk, you might need an externally powered eSATA
cable adapter instead... almost no experience with that.


> Ideally, the configuration I would like to have is system (root and
> /home) reside on a 32GB USB flash stick, if necessary with /boot on an
> SD card, but ideally with /boot on the USB stick as well.

That sounds less ideal than eSATA, but whatever floats your boat. :)


> I tried doing an "expert" install with manual disk partitioning --
> putting /boot on the SD card and root and /home on the USB stick --
> but when it rebooted it just hung, even after power-cycling.

What do you mean by "hung"? U-boot never displays on the serial console?
U-boot hangs at some point?  U-boot loads the kernel+initrd+dtb and it's
stuck at "Starting kernel..."? The kernel loads and prints messages but
the initramfs never finds the rootfs?

A boot log would be very useful here. :)


> Same thing happened when I did a "guided" partitioning install with
> all partitions (/boot, root, and /home) on the USB stick.

I haven't worked with USB rootfs much on the cubox-i precisely because
eSATA is a better interface, but depending on where exactly it hung,
maybe you're missing modules in the initramfs...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: on OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working.

[Vagrant Cascadian]

On 2021-03-14, Rick Thomas wrote:
> I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster to 
> Bullseye and now haveged crashes.
>
> $ sudo service haveged status
> * haveged.service - Entropy Daemon based on the HAVEGE algorithm
>  Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor 
> preset: enabled)
>  Active: failed (Result: signal) since Sat 2021-03-13 05:06:23 PST; 19h 
> ago
>Docs: man:haveged(8)
>  http://www.issihosts.com/haveged/
> Process: 1610 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 
> $DAEMON_ARGS (code=killed, signal=SYS)
>Main PID: 1610 (code=killed, signal=SYS)
> CPU: 247ms
>
> Mar 13 05:06:23 client systemd[1]: haveged.service: Scheduled restart job, 
> restart counter is at 5.
> Mar 13 05:06:23 client systemd[1]: Stopped Entropy Daemon based on the HAVEGE 
> algorithm.
> Mar 13 05:06:23 client systemd[1]: haveged.service: Start request repeated 
> too quickly.
> Mar 13 05:06:23 client systemd[1]: haveged.service: Failed with result 
> 'signal'.
> Mar 13 05:06:23 client systemd[1]: Failed to start Entropy Daemon based on 
> the HAVEGE algorithm.

Wild guess here, but maybe try the workaround from:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866306#59

e.g. pass --data=16 (or maybe some other value) to haveged.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Installing Debian Bullseye on Cubox-i4 with eSATA drive... No ethernet detected

[Vagrant Cascadian]

On 2021-02-06, Rick Thomas wrote:
> On Fri, Jan 29, 2021, at 7:18 PM, Rick Thomas wrote:
>> Hi!
>> 
>> On Fri, Jan 29, 2021, at 1:03 AM, Holger Wansing wrote:
>> > On https://www.debian.org/devel/debian-installer/
>> > you should look under the daily snapshots.
>> > For armhf that would be
>> > https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
>> 
>> I downloaded the two-part image from [1] dated 2021-01-30 and tried to 
>> install it on my Cubox-i4.
>> 
>> It booted fine but when it got to the "Detect network hardware" phase, 
>> it failed and said:
>> 
>> No Ethernet card was detected. If you know the name of the driver 
>> needed by your Ethernet card, you can select it from the list. 
>> Driver needed by your Ethernet card:  
>> and gave a long list of available ethernet drivers.
>> 
>> I couldn't find anything that looked like an Atheros 8035 driver, which 
>> seems to be the one in use when I boot with a working system.
>> 
>> Any suggestions?
>> Thanks!
>> Rick
>> 
>> [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
>>  dated 2021-01-30
>
> I tried it again, this time with the components dated 2021-02-06 (today).
> I was hoping that the problem was transient and might have been fixed in the 
> intervening week, but I still got the same result: "No Ethernet card was 
> detected."
>
> Do I need to file a bug report?  If so, to which package?  If I do, is there 
> any chance it will be fixed before Bullseye is released into the wild?
> Is there a known workaround that I can apply?

Pretty sure it is a kernel bug, since I can make it go away on a similar
system by downgrading to linux 5.9.x. Please CC me on the report and
I'll try to contribute what I can!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Rock Pi 4 A boot loader?

[Vagrant Cascadian]

On 2021-02-02, Michael Fladischer wrote:
> I inherited a Rock Pi 4A v1.4 from a co-worker who ran Armbian on it.
> There are two storage devices present: One eMMC 16GiB module an one M.2 
> NVME 128GiB module, which I haven't used yet.
>
> I wrote the combined image from [0] to the eMMC and powered it on with 
> the USB-TTL cable connected. The installer worked perfectly fine, 
> installing everything to the eMMC module. I made it use mmcblk2p1 as 
> ext4 mounted on /boot and mmcblk2p2 as btrfs on /.
>
> Then the installer mentioned that there is no boot-loader to be 
> installed and I let it reboot the board. As expected, it found no 
> working boot configuration.

It is a confusing message in Debian installer, as it has less to do with
a bootloader, and more to do with the way the bootloader loads a kernel
and other related boot files... in this case it means there is no
support in the flash-kernel package for this board.

There is a merge request for flash-kernel to fix this; I was intending
to merge in a few minutes:

  https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/25


> I managed to hand-craft the extlinux/extlinux.conf file onto the 
> /boot-partition and now the board successfully booted vanilla 
> Debian/unstable.
>
> Now my questions:
>   - What is the necessary to support the installation of a boot-loader 
> in the installer? Is it the missing entry in the u-boot db?
>   - Is using extlinux/extlinux.conf the preferred way to boot a Rock Pi 
> 4? I noticed that this is the way the installer starts.

I find u-boot-menu to generate an extlinux.conf a preferable way, but I
don't think there is currently support in debian-installer to use
u-boot-menu instead of flash-kernel; it only works with flash-kernel
currently. It would be really nice to make that an option during the
install process, though maybe a bit late in the bullseye release
process...


> The system is up at the moment but I noticed that it takes several 
> attempts to get it fully booted. Roughly 80% of the time it will hang 7 
> seconds after the kernel has started. The printk messages are not really 
> helpful as it stops at a different line each time. Is there anyone else 
> running Debian on a Rock Pi4 and has experienced a similar behaviour?

Does the Rock PI4 initialize USB during the boot process? There were
issues with USB on pinebook-pro-rk3399 and rockpro64-rk3399. It could be
a similar issue:

  https://bugs.debian.org/980434
  https://bugs.debian.org/973323


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Installing Debian Bullseye on Cubox-i4 with eSATA drive... No ethernet detected

[Vagrant Cascadian]

On 2021-01-29, Rick Thomas wrote:
> Hi!
>
> On Fri, Jan 29, 2021, at 1:03 AM, Holger Wansing wrote:
>> On https://www.debian.org/devel/debian-installer/
>> you should look under the daily snapshots.
>> For armhf that would be
>> https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
>
> I downloaded the two-part image from [1] dated 2021-01-30 and tried to 
> install it on my Cubox-i4.
>
> It booted fine but when it got to the "Detect network hardware" phase, it 
> failed and said:
>
> No Ethernet card was detected. If you know the name of the driver 
> needed by your Ethernet card, you can select it from the list. 
> Driver needed by your Ethernet card:  
> and gave a long list of available ethernet drivers.

I'm having a similar issue on a hummingboard-i2ex (which is kind of like
a single-board-computer variant of the Cubox-i) on an already installed
system running linux 5.10.x, while 5.9.x works fine on that system, so
seems to be a regression in the kernel.


> I couldn't find anything that looked like an Atheros 8035 driver, which seems 
> to be the one in use when I boot with a working system.

Pretty sure it is not atheros, but handled by:

  drivers/net/ethernet/freescale/fec_main.c

Not sure what exact module or built-in that ends up in.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Installing Debian Buster on Cubox-i4 with eSATA drive.

[Vagrant Cascadian]

On 2021-01-27, Rick Thomas wrote:
> I'm trying to install Debian Buster [1] on my Cubox-i4P with an eSATA
> drive. Everything seems to be fine, but when it comes time to reboot,
> it boots into the installer again, rather than the installed system.
>
> Here's what I did, and what I observed:
>
> *) I downloaded the two parts of the SDcard install image from [1] and 
> followed the instructions in the README to create a 4GB (I didn't have 
> anything smaller) SDcard installer.
> *) I connected the eSATA disk and plugged the SDcard into the Cubox and 
> powered it up.
> *) It booted off the SD-card into the installer as expected.
...
> *) But when the reboot happened, I found myself back in the installer.
> *) I tried removing the SDcard and rebooting, but it failed to boot -- after 
> power-on nothing happened.

> What I hoped would happen with the eSATA drive was that the installer
> would write the boot firmware (u-boot, etc) to the SDcard, and
> configure it to get /boot, root, /home, swap off the eSATA.

U-boot can only be loaded from microSD on that platform, as far as I'm
aware.

You can use the bootloader from the installer image, just delete the
boot.scr and/or extlinux.conf from the partition on the installer image,
or make another partition on the microSD card, and mark it bootable, but
don't put anything on it. Then u-boot should fall back to loading the
kernel+initrd+device-tree off of the eSATA.

If you interrupt the boot process and get to a u-boot prompt, you should
be able to see the order of devices u-boot tries to boot from with:

  printenv boot_targets


Now that bullseye is in the early phases of freeze, please consider
testing bullseye, too, if you can! :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Installation images for arm64

[Vagrant Cascadian]

On 2021-01-06, Reco wrote:
> On Tue, Oct 27, 2020 at 10:20:28PM +0300, Reco wrote:
>> On Tue, Oct 27, 2020 at 10:21:01AM -0700, Vagrant Cascadian wrote:
>> > Please file bugs and/or merge requests on u-boot and
>> > arm-trusted-firmware if you want to get those parts enabled for Odroid
>> > N2 and g12a.
>
> Thank you for paying attention to my bugreport, I see that they are
> fixed by now.
> But I'm kind of at loss on what to do next.
>
> I've installed u-boot-amlogic=2021.01~rc4+dfsg-2 and
> arm-trusted-firmware=2.4+dfsg-1 from the experimental, but I don't see
> any of the firmware mentioned by [1].
>
> Should I sign /usr/lib/u-boot/odroid-n2/u-boot.bin with fiptool somehow?
> How do I apply /usr/lib/arm-trusted-firmware/g12a/bl31.bin to it?
...
> [1] 
> https://salsa.debian.org/debian/u-boot/-/blob/master/doc/board/amlogic/odroid-n2.rst

I've only done this on Odroid-C2, so take this with a grain of salt, but
the instructions look similar... so reading odroid-n2.rst:

Skip the "U-boot compilation" step, and in the "Image Creation" step,
copy u-boot.bin from /usr/lib/u-boot/BOARD/u-boot.bin and bl31.bin from
/usr/lib/arm-trusted-firmware/PLATFORM/bl31.bin, instead of using the
vendor provided parts for those. All the other parts you'll need from
the vendor u-boot.

It is a little unclear weather there's a significance to the difference
between bl31.img and bl31.bin ... you might first try using the vendor
"bl31" instead, and then see if bl31.bin works; if the vendor bl31 works
and the one from arm-trusted-firmware do not, we might need to adjust
the arm-trusted-firmware package somehow...

Good luck!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Porter roll call for Debian Bullseye

[Vagrant Cascadian]

On 2020-11-20, Graham Inggs wrote:
> A friendly reminder about the porter roll call for bullseye.
>
> On Mon, 2 Nov 2020 at 22:23, Graham Inggs  wrote:
>> We are doing a roll call for porters of all release architectures.  If
>> you are an active porter behind one of the release architectures [1]
>> for the entire lifetime of Debian Bullseye (est. end of 2024), please
>> respond with a signed email containing the following before Friday,
>> November 27:
>
> Please note we don't automatically assume that porters for previous
> releases will continue to do so.
> If you were a porter for a previous release, we'd like you to sign up
> again for bullseye.

I know I'm a bit late to the party now...

I do run both arm64 and armhf on numerous machines, mostly as part of
the reproducible builds zoo. We mostly stick to stable for the main OS,
but do run unstable and testing in chroots. I also sometimes run testing
or individual packages from unstable on various other armhf and arm64
machines I use and make efforts to report and ideally fix bugs when
encountered.

I maintain u-boot and arm-trusted-firmware, used primarily on armhf and
arm64. I do occasional debian-installer work and linux related work for
both arm64 and armhf.

I can most likely continue doing the above for the forseeable future.

Not likely to fix deeply complicated toolchain issues.


If all that qualifies for a porter hat, ok, if not, also ok. :)


live well,
  vagrant


signature.asc
Description: PGP signature

pinebook wifi (rtl8273cs) (Was: Debian installer auf Pinebook)

[Vagrant Cascadian]

On 2020-11-01, Vagrant Cascadian wrote:
> On 2020-10-31, Christian Kastner wrote:
>> Apparently the WIFI is a RTL8723cs device and support landed in 5.9,
>> coincidentally the kernel in bullseye
...
> I don't see anything regarding RTL8723cs support specifically in 5.9
...
> Maybe there's a proposed patchset somewhere or an out-of-tree driver?

Nothing was ever proposed:

  https://patchwork.kernel.org/project/linux-wireless/list/?state=*=rtl8723cs

This looks promising, though:

  https://github.com/Icenowy/rtl8723cs


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Debian installer auf Pinebook (Was: X11 modul for pinebook?)

[Vagrant Cascadian]

On 2020-10-31, Christian Kastner wrote:
> Apparently the WIFI is a RTL8723cs device and support landed in 5.9,
> coincidentally the kernel in bullseye, so I gave its SD card images a
> try. However, they launch to a black screen, so I assume that this still
> goes out to serial?

I don't see anything regarding RTL8723cs support specifically in 5.9 (or
in linux master or next), other than a mention of a compatible in the
pinebook device tree. That compatible is not referenced by any drivers,
so probably not actually used.

It is also mentioned in the bluetooth documentation, but again, not
referenced by any drivers.

Maybe there's a proposed patchset somewhere or an out-of-tree driver?


Also don't see any firmware specific to rtl8723cs ... but *maybe* it
could in theory use firmware from one of the other numerous rtl8723*
variants...


Looks like I'll be sticking to usb ethernet and wifi adapters for the
near future, which works well enough...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Debian installer auf Pinebook (Was: X11 modul for pinebook?)

[Vagrant Cascadian]

On 2020-10-31, Vagrant Cascadian wrote:
> On 2020-10-31, Vagrant Cascadian wrote:
>> And just tested on a pinebook:
>>
>>   
>> https://d-i.debian.org/daily-images/arm64/20201031-02:16/netboot/gtk/SD-card-images/
>>
>>   zcat firmware.pinebook.img.gz partition.img.gz | sudo dd of=/dev/DEVICE 
>> bs=4096k
>>
>> But it isn't working for me either...
> ...
>> On a running pinebook with working video acceleration sufficient to run
>> wayland/sway, lsmod outputs:
>>
>>   Module  Size  Used by
> ...
>>   lima   73728  0
> ...
>>   drm   552960  11 
>> gpu_sched,sun8i_mixer,drm_kms_helper,panel_simple,lima,sun4i_frontend,sun4i_tcon,sun4i_drm,analogix_anx6345,analogix_dp
>
> So far I've tracked down that "lima" is missing from the installer
> images, and it's dependency "gpu_sched". There might be more needed, but
> those definitely are a starting point.

Well, lima wasn't actually necessary.

Turned out to need i2c_mv64xx for the console video on the LCD.

Also needed to add pinctrl_axp209 to get the usb keyboard to work.

Should be in the next kernel upload:

  
https://salsa.debian.org/kernel-team/linux/-/commit/6b3763e98d3d5d6856d131d6a1ad246b57981fd8
  
https://salsa.debian.org/kernel-team/linux/-/commit/9c5c235ae023ff521bcbad740f8ba1efb9d0b9cc


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Debian installer auf Pinebook (Was: X11 modul for pinebook?)

[Vagrant Cascadian]

On 2020-10-31, Vagrant Cascadian wrote:
> I tried to add the new modules to the kernel .udebs a while back:
>
>   
> https://salsa.debian.org/kernel-team/linux/commit/e6e296b335a7081a1a88c41dae4539f3115da44e
>
> And just tested on a pinebook:
>
>   
> https://d-i.debian.org/daily-images/arm64/20201031-02:16/netboot/gtk/SD-card-images/
>
>   zcat firmware.pinebook.img.gz partition.img.gz | sudo dd of=/dev/DEVICE 
> bs=4096k
>
> But it isn't working for me either...
...
> On a running pinebook with working video acceleration sufficient to run
> wayland/sway, lsmod outputs:
>
>   Module  Size  Used by
...
>   lima   73728  0
...
>   drm   552960  11 
> gpu_sched,sun8i_mixer,drm_kms_helper,panel_simple,lima,sun4i_frontend,sun4i_tcon,sun4i_drm,analogix_anx6345,analogix_dp

So far I've tracked down that "lima" is missing from the installer
images, and it's dependency "gpu_sched". There might be more needed, but
those definitely are a starting point.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Debian installer auf Pinebook (Was: X11 modul for pinebook?)

[Vagrant Cascadian]

On 2020-10-31, Christian Kastner wrote:
> On 4/22/20 7:15 PM, Vagrant Cascadian wrote:
>> The debian-installer concatenateable images from buster *should* work
>> with *serial console*:
>> 
>>   
>> https://deb.debian.org/debian/dists/buster/main/installer-arm64/current/images/netboot/SD-card-images/README.concatenateable_images
>> 
>> Getting the installer running on LCD is still a work-in-progress, but
>> you *might* be able to get the text console running by editing the boot
>> arguments on the boot media and passing console=tty0 and adding the
>> appropriate modules to the initrd by appending an additional cpio
>> archive to it... finding out exactly which modules... is a
>> project. Though you could append all of the modules for the matching
>> kernel version.
>> 
>> But no, there's no image that will "just work" without some fiddling.
>
> I found this older thread and wanted to check if there have been any
> updates on this that I might have missed?
>
> I gave the images from buster a try and the installation process ran
> fine on LCD until the network interface wasn't found.

The modules needed since buster has changed, since some accelerated
graphics support was added.

I tried to add the new modules to the kernel .udebs a while back:

  
https://salsa.debian.org/kernel-team/linux/commit/e6e296b335a7081a1a88c41dae4539f3115da44e

And just tested on a pinebook:

  
https://d-i.debian.org/daily-images/arm64/20201031-02:16/netboot/gtk/SD-card-images/

  zcat firmware.pinebook.img.gz partition.img.gz | sudo dd of=/dev/DEVICE 
bs=4096k

But it isn't working for me either...


I extracted the initrd used in the installer image, and it contains:

  find -name '*.ko' | grep -E 'anx|pwm|panel|sun4i|sun8i|axp'
  ./kernel/drivers/phy/allwinner/phy-sun4i-usb.ko
  ./kernel/drivers/pwm/pwm-cros-ec.ko
  ./kernel/drivers/pwm/pwm-sun4i.ko
  ./kernel/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.ko
  ./kernel/drivers/video/backlight/pwm_bl.ko
  ./kernel/drivers/mfd/axp20x-rsb.ko
  ./kernel/drivers/mfd/axp20x.ko
  ./kernel/drivers/gpu/drm/sun4i/sun4i-frontend.ko
  ./kernel/drivers/gpu/drm/sun4i/sun8i-mixer.ko
  ./kernel/drivers/gpu/drm/sun4i/sun8i_tcon_top.ko
  ./kernel/drivers/gpu/drm/sun4i/sun4i-drm.ko
  ./kernel/drivers/gpu/drm/sun4i/sun4i-tcon.ko
  ./kernel/drivers/gpu/drm/panel/panel-simple.ko
  ./kernel/drivers/gpu/drm/bridge/analogix/analogix-anx6345.ko
  ./kernel/drivers/regulator/pwm-regulator.ko
  ./kernel/drivers/regulator/axp20x-regulator.ko


The patch for initramfs-tools works for me:

  
https://salsa.debian.org/kernel-team/initramfs-tools/commit/482897b9a6001c69b16c651d4bc5b3a49a28d40f


On a running pinebook with working video acceleration sufficient to run
wayland/sway, lsmod outputs:

  Module  Size  Used by
  nls_iso8859_1  16384  1
  nls_cp437  20480  1
  vfat   28672  1
  fat90112  1 vfat
  isofs  53248  0
  nls_utf8   16384  0
  udf   126976  0
  crc_itu_t  16384  1 udf
  cdrom  65536  2 udf,isofs
  rfkill 36864  1
  ecb16384  0
  des_generic16384  0
  libdes 24576  1 des_generic
  cbc16384  0
  ghash_ce   24576  0
  gf128mul   16384  1 ghash_ce
  sha2_ce20480  0
  sha256_arm64   28672  1 sha2_ce
  axp20x_adc 20480  0
  axp20x_battery 16384  0
  axp20x_ac_power16384  0
  sha1_ce20480  0
  industrialio   77824  3 axp20x_battery,axp20x_ac_power,axp20x_adc
  axp20x_pek 16384  0
  cdc_ether  20480  0
  snd_soc_simple_card24576  0
  usbnet 45056  1 cdc_ether
  snd_soc_simple_card_utils24576  1 snd_soc_simple_card
  sun50i_codec_analog28672  1
  sun8i_adda_pr_regmap16384  1 sun50i_codec_analog
  sunxi_cedrus   40960  0
  r8152  90112  0
  v4l2_mem2mem   32768  1 sunxi_cedrus
  lima   73728  0
  uvcvideo  110592  0
  sun4i_i2s  24576  2
  sun8i_codec28672  1
  videobuf2_dma_contig24576  1 sunxi_cedrus
  snd_soc_simple_amplifier16384  1
  videobuf2_vmalloc  20480  1 uvcvideo
  videobuf2_memops   20480  2 videobuf2_vmalloc,videobuf2_dma_contig
  videobuf2_v4l2 28672  3 sunxi_cedrus,uvcvideo,v4l2_mem2mem
  mii20480  2 usbnet,r8152
  gpu_sched  40960  1 lima
  aes_ce_blk 36864  0
  videobuf2_common   53248  4 
sunxi_cedrus,videobuf2_v4l2,uvcvideo,v4l2_mem2mem
  snd_soc_core  221184  6 
sun4i_i2s,sun50i_codec_analog,sun8i_codec,snd_soc_simple_amplifier,snd_soc_simple_card_utils,snd_soc_simple_card
  crypto_simd24576  1 aes_ce_blk
  c

Re: Installation images for arm64

[Vagrant Cascadian]

On 2020-10-27, Reco wrote:
> On Tue, Oct 27, 2020 at 08:59:38AM -0700, Vagrant Cascadian wrote:
>> On 2020-10-27, Reco wrote:
>> > On Tue, Oct 27, 2020 at 08:02:18AM -0700, Vagrant Cascadian wrote:
>> >> It looks like u-boot 2020.10 has an odroid-n2 target and
>> >> arm-trusted-firmware 2.3 has an amlogic/g12a target, so it would likely
>> >> be possible to enable those in the Debian packages if someone were able
>> >> to test them semi-regularly.
>> >
>> > I happen to have an Odroid N2. What exactly such testing would require?
>> 
>> For the debian-side of things:
>> 
>>   https://wiki.debian.org/U-boot
>
> That's doable. Count me in, if it's all that takes.

More-or-less. :)


>> And a quick guess to install would be to adapt the instructions for
>> installing to use the packaged u-boot and arm-trusted-firmware (bl31):
>> 
>>   
>> https://salsa.debian.org/debian/u-boot/-/blob/master/doc/board/amlogic/odroid-n2.rst
>> 
>> But it will probably still require some of the components from
>> hardkernel's process.
>
> And that one is problematic. I don't see a big problem in building
> software from the source if that's required, but I prefer trusted Debian
> toolchain for doing it, not some assorted Linaro blobs.

In order to boot the Odroid-N2 it requires using some binary blobs from
the vendor and aml_encrypt_g12a. There was work on replacing some parts
for the earlier amlogic SoCs:

  https://github.com/afaerber/meson-tools/

But it got caught up in GPL/OpenSSL mess ... which I guess the situation
has changed in Debian now...


Please file bugs and/or merge requests on u-boot and
arm-trusted-firmware if you want to get those parts enabled for Odroid
N2 and g12a.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Installation images for arm64

[Vagrant Cascadian]

On 2020-10-27, Reco wrote:
> On Tue, Oct 27, 2020 at 08:02:18AM -0700, Vagrant Cascadian wrote:
>> It looks like u-boot 2020.10 has an odroid-n2 target and
>> arm-trusted-firmware 2.3 has an amlogic/g12a target, so it would likely
>> be possible to enable those in the Debian packages if someone were able
>> to test them semi-regularly.
>
> I happen to have an Odroid N2. What exactly such testing would require?

For the debian-side of things:

  https://wiki.debian.org/U-boot

And a quick guess to install would be to adapt the instructions for
installing to use the packaged u-boot and arm-trusted-firmware (bl31):

  
https://salsa.debian.org/debian/u-boot/-/blob/master/doc/board/amlogic/odroid-n2.rst

But it will probably still require some of the components from
hardkernel's process.


live well,
  vagrant


signature.asc
Description: PGP signature

Installation images for arm64 (was Re: Bullseye installer, daily image broken for cubox-i)

[Vagrant Cascadian]

On 2020-10-27, Alan Corey wrote:
> Concatenateable images seem like a good idea but it looks like there
> are none for any hardware I have (Pinebook Pro, Odroid N2, Rock64,
> Raspberry Pi 3B).

For arm64, there's at least support for Pinebook Pro and Rock64 and
numerous other systems:

  
https://d-i.debian.org/daily-images/arm64/20201027-02:17/netboot/SD-card-images/

I or others have tested that they boot at some point during the
development process, though it has been a while since I tested any.


The Odroid N2 and RaspberryPI systems requires non-free components, so
it can't have out-of-the-box support in debian-installer.

But it shouldn't *too* be hard to add the parts for RaspberryPI:

  zcat firmware.none.img.gz partition.img.gz > complete_image.img
  dd if=complete_image.img of=/dev/SOMEDEVICE
  mount /dev/SOMEDEVICEp1 /mnt
  cp /path/to/rpi/firmware /mnt
  cp /usr/lib/u-boot/rpiVARIANT/u-boot.bin /mnt/
  ...

Or configure config.txt or whatever to load the components directly.


For the Odroid N2, you need to create the complete_image.img and then
install the bootloader onto it using odroid's bootloader scripts.

  https://github.com/hardkernel/u-boot/

I've done this for Odroid C2, which is likely a similar process,
although I'm able to use those scripts with the u-boot and
arm-trusted-firmware shipped with debian for the Odroid C2.

It looks like u-boot 2020.10 has an odroid-n2 target and
arm-trusted-firmware 2.3 has an amlogic/g12a target, so it would likely
be possible to enable those in the Debian packages if someone were able
to test them semi-regularly.


> Having a serial console might let you see more of what's going on.
> How to do that varies with the machine.

Indeed, having access to a serial console is pretty crucial to work on
most arm boards. The CuBox-i series make that easy as there is a
microUSB port that exposes a serial interface built-in.


live well,
  vagrant

> On 10/26/20, Vagrant Cascadian  wrote:
>> On 2020-10-26, Rainer Dorsch wrote:
>>> I wanted to do a test on the mainline support of bullseye for the
>>> Cubox-i.
>>>
>>> I downloaded the bullseye installer from
>>>
>>> https://d-i.debian.org/daily-images/armhf/daily/hd-media/SD-card-images/
>>>
>>> put it on an SD card
>> ...
>>> But all I saw was a quick u-boot message then the screen stayed dark
>>> (screen
>>> reported "no HDMI signal").
>>>
>>> Strange is that I see the same issue with the lastest install images of
>>> buster
>>> :-/
>>>
>>> The Fedora32 installer boots and the installer comes up.
>>>
>>> Any ideas what is going wrong? Hmm.just wondering now, is it required
>>> to
>>> install Debian via ttyUSBx or should the text based installer work on
>>> HDMI?
>>
>> It may need new modules added for the framebuffer video output; at one
>> point many years ago I had gotten a wandboard quad (also imx6, like the
>> cubox-i) to boot debian-installer on the video console, but then support
>> was enabled for video acceleration in the kernel and I never tracked
>> down which kernel modules were needed to enable in the installer to get
>> the framebuffer video back again...
>>
>> It's no fun playing kernel module .udeb whack-a-mole :/
>>
>>
>> live well,
>>   vagrant


signature.asc
Description: PGP signature

Re: Bullseye installer, daily image broken for cubox-i

[Vagrant Cascadian]

On 2020-10-26, Rainer Dorsch wrote:
> I wanted to do a test on the mainline support of bullseye for the Cubox-i.
>
> I downloaded the bullseye installer from
>
> https://d-i.debian.org/daily-images/armhf/daily/hd-media/SD-card-images/
>
> put it on an SD card
...
> But all I saw was a quick u-boot message then the screen stayed dark (screen 
> reported "no HDMI signal").
>
> Strange is that I see the same issue with the lastest install images of 
> buster 
> :-/
>
> The Fedora32 installer boots and the installer comes up.
>
> Any ideas what is going wrong? Hmm.just wondering now, is it required to 
> install Debian via ttyUSBx or should the text based installer work on HDMI?

It may need new modules added for the framebuffer video output; at one
point many years ago I had gotten a wandboard quad (also imx6, like the
cubox-i) to boot debian-installer on the video console, but then support
was enabled for video acceleration in the kernel and I never tracked
down which kernel modules were needed to enable in the installer to get
the framebuffer video back again...

It's no fun playing kernel module .udeb whack-a-mole :/


live well,
  vagrant


signature.asc
Description: PGP signature

Re: u-boot vs installer images

[Vagrant Cascadian]

On 2020-10-12, Rainer Dorsch wrote:
> I just browsed through the bullseye installation guide. I saw there is a 
> section on 
>
> 3.6.2. Debian-provided U-Boot (system firmware) images
> https://www.debian.org/releases/testing/armhf/ch03s06.en.html
>
> and
>
> 5.1.5. Using pre-built SD-card images with the installer
> https://www.debian.org/releases/testing/armhf/ch05s01.en.html
>
> I am just wondering if I use a pre-built SD-card images with the installer do 
> I still need the U-Boot (system firmware) images (I do not recall that I used 
> them previously)?

The SD-card images include everything in the U-Boot system firmware
images, but additionally have the installer components.


> If not, what is the intended usecase for the U-Boot (system 
> firmware) images?

You might be able to use them to boot an EFI installer image on USB
media for a machine that only boots from SD card, as one example.

For some platforms, the offsets used on the raw media for u-boot might
be incompatible with the EFI installer image layout, so you may not be
able to have both on a single media; maybe with some work that could be
fixed in some cases.


3.6.2. Debian-provided U-Boot (system firmware) images:
  ...
  The raw U-Boot components are provided for advanced users; the
  generally recommended way is to use one of the ready-made SD card
  images.

So in general, use the ready-made SD card images.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Debian with Debian kernel on Pinebook Pro

[Vagrant Cascadian]

On 2020-08-29, Birger Schacht wrote:
> I am trying to get a Debian (bullseye) installation to work on the
> Pinebook Pro with the Debian kernel package. I managed to install Debian
> back in February, but back then this was with a custom kernel with a lot
> of patches [0]. As far as I know most if not all of the relevant patches
> where merged upstream. Yet I am failing to get a working display.

I don't think support for the display is upstream yet, and the same for
display on upstream u-boot, FWIW.


I have had luck pulling the patches from one of the manjaro 5.8
branches:

  https://gitlab.manjaro.org/tsys/linux-pinebook-pro

Applying those patches to a mainline kernel, which should work on
Debian's kernel without too much trouble(beyond learning quirks of the
linux packaging in Debian and the effort to actually build the
package). It is less than 30 patches, and probably could leave a few of
them out. Some are clearly hacks and aren't going to land in mainline
and many of the commit messages are noted as such.


There's one patch in upstream 5.9-rc* to enable battery status:

  c7c4d698cd2882c4d095aeed43bbad6fc990e998
  arm64: dts: rockchip: add fuel gauge to Pinebook Pro dts

I was thinking of backporting it Debian's 5.8 kernel to at least be able
to know how the battery is doing...


At the moment, for an unpatched kernel, it's still limited to serial
console and ssh.


It's on my TODO list to see what the minimum set of additional patches
would be, and I've been keeping an eye on upstream for relevent patches
and occasionally apply them to the current sid and/or experimental
kernels a version or two early when it seems reasonable...

It's coming along, though slowly.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Re: NextThing C.H.I.P. v1.0 - Debian Stretch Installer from USB

[Vagrant Cascadian]

On 2020-05-26, Pablo Rath wrote:
> On Tue, May 26, 2020 at 09:31:33AM +0200, Xavier Bestel wrote:
>> Le jeudi 21 mai 2020 à 12:25 +0200, Pablo Rath a écrit :
>> > On Mon, May 18, 2020 at 03:57:52PM +0200, Xavier Bestel wrote:
>> > Is there a reason to prefer Stretch over Buster?
>> 
>> I didn't even dream of Buster, but the more fresher the better !
>
> Then let us aim for Buster. 
>
> [...]
>
>> > 2.) If you want vanilla Debian I am willing to help you. 
>> > Most of what I know and did is summarized in this thread:
>> > https://lists.phcomp.co.uk/pipermail/arm-netbook/2017-August/014646.html
>
> I have made major progress yesterday and managed to install mainline
> U-Boot to CHIPs builtin NAND so all quirks concerning the boot process
> mentioned in this thread are no longer relevant. 

How did you flash it? 

Is there anything needed different from what's in the packaged in
u-boot-sunxi? Did you need any patches or configuration changes?

I've considered dropping it from u-boot-sunxi's debian package as it
seemed there wasn't much of a future for the platform and it only worked
with sunxi-fel, but sounds like I should instead take a look at it
again.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Debian installer auf Pinebook (Was: X11 modul for pinebook?)

[Vagrant Cascadian]

On 2020-04-22, Andreas Tille wrote:
> On Wed, 22 Apr 2020 Andrei POPESCU wrote:
>> See if maybe these pages in the wiki are helpful
>> 
>> https://wiki.debian.org/InstallingDebianOn/PINE64/Pinebook
>> https://wiki.debian.org/InstallingDebianOn/PINE64/PINEA64
>
> Thank you for these links.
>
>> See also this thread (still ongoing) on getting the graphical installer 
>> working on arm64.
>
> I admit I do not mind about the graphical installer - I always use the
> test based installer.

The "text based installer" may only work over serial console... slightly
more information below.


> My question is rather:  Can I simply `dd` the Debian arm64 install disk
> to a miniSD card, boot from this and install on the internal emmc of my
> pinebook.  This was *not* possible when I bought this device and I would
> love if somebody would confirm here before I mess up what is now
> "somehow working".

The debian-installer concatenateable images from buster *should* work
with *serial console*:

  
https://deb.debian.org/debian/dists/buster/main/installer-arm64/current/images/netboot/SD-card-images/README.concatenateable_images

Getting the installer running on LCD is still a work-in-progress, but
you *might* be able to get the text console running by editing the boot
arguments on the boot media and passing console=tty0 and adding the
appropriate modules to the initrd by appending an additional cpio
archive to it... finding out exactly which modules... is a
project. Though you could append all of the modules for the matching
kernel version.

But no, there's no image that will "just work" without some fiddling.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: X11 modul for pinebook?

[Vagrant Cascadian]

On 2020-04-20, Andreas Tille wrote:
> I have a pinebook of the first generation installed with Stretch.  I
> naively assumed that it would the right time to upgrade to Buster.
> Unfortunately X does not start any more:
>
> # grep EE /var/log/Xorg.[01].log
> /var/log/Xorg.0.log:[12.349] Current Operating System: Linux pinebook 
> 3.10.105-bsp-1.2-ayufan-118 #1 SMP PREEMPT Sun Oct 15 21:40:57 UTC 2017 
> aarch64
> /var/log/Xorg.0.log:(WW) warning, (EE) error, (NI) not implemented, (??) 
> unknown.
> /var/log/Xorg.0.log:[12.363] (EE) fbturbo: module ABI major version (23) 
> doesn't match the server's version (24)
> /var/log/Xorg.0.log:[12.364] (EE) Failed to load module "fbturbo" (module 
> requirement mismatch, 0)
...
> I thought it would help to build and install
>
> https://salsa.debian.org/raspi-team/xf86-video-fbturbo

The pinebook is pretty much my primary machine (using it right now to
type this), and X is working fine here... It's not fancy accelerated
graphics, but it does work. I mostly have been using newer kernels from
buster-backports/sid/experimental, but the buster generation of kernels
worked fine for me last I tried.

Maybe you have some customization in /etc/X11/xorg.conf* that's telling
it to use fbturbo instead of fbdev?

What version of u-boot are you running? Again, it's been a while since I
tested the version in buster, but I've been using all the versions
uploaded since. Mainline (and Debian packaged) u-boot properly
configures the framebuffer for quite some releases...

Good luck!

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Raspberry Pi

[Vagrant Cascadian]

On 2020-03-02, Alan Corey wrote:
> That poses an interesting question: can you install Debian debs on a
> Raspbian system and vice versa?  Never thought about it.  I've maybe
> used Ubuntu ones a couple times.  I suppose each case is unique and
> the worst casualty would be to the apt system and it's record-keeping.
> You don't want foreign repos in your sources.list but just snagging a
> deb from somewhere wouldn't be bad I think as long as the dependencies
> worked out.  But what about the install paths for files, the dirs
> might not exist?

Raspbian armhf is built for armv6, and Debian armhf is built for armv7,
so they're not strictly compatible. You might get away with it on rpi2,
rpi3 or rpi4, since they support armv7. But rpi1 and rpi0 only support
armv6. Mixing and matching incompatible ABIs could cause all sorts of
issues...

*If* the rpi1 had supported armv7, raspbian probably would have never
existed, or just be a small number of tweaked packages on an otherwise
plain debian armhf system.


live well,
  vagrant

Re: Bug#911560: [Kinda solved] Re: Network not working on Olimex LIME2 rev K ??

[Vagrant Cascadian]

On 2020-02-09, Dominique Dumont wrote:
> On Saturday, 8 February 2020 16:54:45 CET Jonas Smedegaard wrote:
>> Would be great if you could also test with patched u-boot in stable
>> Debian - so we can consider fixing this in a point release.
>
> I've tested together:
> - Debian's u-boot debian/2019.01+dfsg-7 with CONFIG_GMAC_TX_DELAY=3 tweak
> - Debian's stable partition (dated 2019-11)

Thanks for debugging the issue!

Please submit a patch to upstream fixing this in the appropriate files
in configs/*; I'd guess configs/A20-OLinuXino-Lime2-eMMC_defconfig
and/or configs/A20-OLinuXino-Lime2_defconfig.

Then I'll feel happier about backporting them to u-boot in stable and
eventually can drop the patch...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Network not working on Olimex LIME2 rev K ??

[Vagrant Cascadian]

On 2020-02-05, Dominique Dumont wrote:
> I'm trying to setup a new Olimex LIME2 rev K board with Debian stable 
> installer.
>
> The installation starts through serial console, but DHCP configuration does 
> not 
> work.
>
> In u-boot, ping command does not work:
> => ping 192.168.0.254
> Speed: 1000, full duplex
> *** ERROR: `ipaddr' not set
> ping failed; host 192.168.0.254 is not alive
>
> This message [1] from Olimex forum suggests to change a u-boot configuration 
> parameter to get network working on recent boards, but I don't know how to 
> update u-boot on the installer.
>
> Is there anything else to try ?
>
> All the best
>
> [1] https://www.olimex.com/forum/index.php?topic=6734.msg26298#msg26298

Maybe related to:

  A20-OLinuXino-Lime 2 Rev. K Ethernet problem - No connection possible in 
installer
  https://bugs.debian.org/911560

The summary of the summary, limit your link negotiation to 100MBit or
even 10MBit.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Armbian

[Vagrant Cascadian]

On 2020-02-03, Paul Wise wrote:
> On Sun, Feb 2, 2020 at 5:51 PM Phil Endecott wrote:
>
>> What do you know about Armbian?  What do you think?
>
> Only what I see on their site and derivatives census page:
>
> https://www.armbian.com/
> https://wiki.debian.org/Derivatives/Census/Armbian
>
> I think they are a useful source of workarounds for devices that are
> not yet supported in the mainline versions of bootloaders, the Linux
> kernel or in Debian itself.

Nicely put!


> Image-based installation methods are currently very hacky. After
> installing packages, you will have system-specific files created (like
> /etc/machine-id or OpenSSH private keys). The Debian live/cloud images
> have to workaround that by deleting the files after the install is
> created. Probably that set of deletions needs to be synced between
> Debian live/cloud and any future ARM images (not sure if they are
> synced yet). The correct way to do this would be for packages to have
> a "generically installed" state in dpkg/apt, which would prevent them
> from creating system-specific files. More info about this is in the
> linked discussions:
>
> https://wiki.debian.org/ReproducibleInstalls
> https://wiki.debian.org/SystemBuildTools#Discussions

I have been meaning to explore making live images for arm devices using
the concatenateable images method used by debian-installer. Though, that
method has limitations too, as some devices load files off of a
partition, some off of raw device offsets, some a combination of those
methods. Some require MBR partition tables, some require GPT... it's a
big world out there. The great thing about standards, is...


It's also possible to have bootloader on one media that is device
specific, which doesn't take much space, and on a larger media image a
common rootfs, maybe also with EFI bootable grub-efi on it or something.
The U-boot support for EFI is coming along quite well.


> The other problem with image-based installation methods is that there
> are a ridiculous number of devices, so you have to either limit your
> device support, produce a prohibitively large amount of
> device-specific images, or figure out how to create one image that
> works on all devices (which won't be possible due to bootloader
> diversity on ARM), or a compromise of a limited number of images that
> each work on a range of devices.

A great talk from last year's fosdem addressing this issue with some
success:

  https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Support for accelerated graphics and video decoding on PINE A64+ in bullseye

[Vagrant Cascadian]

Control: tags 946510 pending

On 2019-12-14, Andrei POPESCU wrote:
> On Vi, 06 dec 19, 19:57:07, Andrei POPESCU wrote:
>> On Vi, 06 dec 19, 15:05:32, Marcin Juszkiewicz wrote:
>> > Use Lima (Pine A64) or Panfrost (Rock64)?
>> 
>> Sure... how?
>> 
>> I changed my xorg.conf as per [1], but not apparent change. What (else) 
>> is missing?
>
> For the Allwinner A64 the sun8i-mixer module is missing, see #946510.

Thanks for looking into this!

Did some basic compile testing and pushed to the git kernel repository,
should land in the next linux 5.3.x and 5.4.x uploads.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: libxp-dev and libxp6 for aarch64 and forward?

[Vagrant Cascadian]

On 2019-08-17, Alan Corey wrote:
> They seem to be missing from Stretch but they're in Buster.  Maybe, by
> pkgs.org, and they only have the i386 and amd64 versions.  They don't
> show up using this sources.list

The last release that contained libxp was jessie (oldoldstable):

  https://tracker.debian.org/pkg/libxp
  

It was removed from Debian testing and unstable about four years ago,
the process starting back in 2012:

  https://bugs.debian.org/657253


> I'm on an aarch64 machine (Odroid N2).  Raspbian has them.

Maybe raspbian never cleaned them up, and they're just leftovers from
raspbian jessie.


live well,
  vagrant

Re: Add support for Pine64 RockPro64

[Vagrant Cascadian]

On 2019-07-29, Rohan Garg wrote:
> There is u-boot support specifically for rockpro64-rk3399 upstream
>> now. I'd be happy to enable it in the u-boot packaging if you or someone
>> else can promise to test it periodically:
>>
>>   https://wiki.debian.org/U-boot/
>>   https://wiki.debian.org/U-boot/Status
>>
>>
> On a similar note, could we possibly also enable the RockPi 4? I've been
> testing mainline u-boot/Linux for the past month and it works really well.

Sounds promising; typically file bugs and/or merge requests for u-boot,
linux and other relevent packages, as mentioned in the above wiki
page. Feel free to CC or ping me if you do.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Add support for Pine64 RockPro64

[Vagrant Cascadian]

On 2019-07-27, Michael Gratton wrote:
> Package: u-boot

Did you mean for this to go to the bug tracking system?


> I've just picked up a RockPro64 board[0] based on the Rockchip RK3399 
> and it would be great to be able to install standard Debian on it (as 
> opposed dd'ing some random image).

In order for it to work out of the box, it needs support in
arm-trusted-firmware, but there are currently licensing issues with a
binary blobs in the rk3399 target upstream:

  https://github.com/ARM-software/tf-issues/issues/651

I've also not been able to get it to build with toolchains more recent
than stretch:

  https://github.com/ARM-software/tf-issues/issues/650



> Uboot has support for for the chipset[1]

There is u-boot support specifically for rockpro64-rk3399 upstream
now. I'd be happy to enable it in the u-boot packaging if you or someone
else can promise to test it periodically:

  https://wiki.debian.org/U-boot/
  https://wiki.debian.org/U-boot/Status

It will require building arm-trusted-firmware independently, for reasons
metioned above.


> and linux 5.2 has 99% support 
> for the board, while 5.3 irons out the last issues.

The linux packaging in Debian may need some additional config options
enabled, as people have tested with other rk3399 boards, but most
features should already be enabled. File bugs for missing features, and
feel free to CC me.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: making debs for u-boot kernels

[Vagrant Cascadian]

On 2019-07-27, Reco wrote:
> On Thu, Jul 25, 2019 at 12:49:32PM -0400, Gene Heskett wrote:
>> I am furious (fat lot of good that does me) with the lack of tools, and 
>> information on how to use them to build an installable kernel.deb for a 
>> rpi-3b.  I know it can be done, I have witnessed apt do it several 
>> times, on at least two of the arm platforms, once on an arm64 running 
>> stretch and several times on armhf for releases from jessie to buster.
>
> Raspberry Pi does not use u-boot. Raspbian does not use u-boot. Their
> proprietary bootloader can be forced to run u-boot, but its not worth it
> - by using u-boot you're limiting yourself to armhf, and Raspberry Pi3
>   is an aarch64 board.

The u-boot-rpi packages in debian include variants appropriate to arm64,
armhf and armel, depending on which architecture u-boot-rpi package is
built for. e.g. if you install u-boot-rpi on arm64, you get the arm64
u-boot binaries.

Using u-boot does enable the use of u-boot-menu package, in case you
want to choose which kernel to boot.


FWIW, I think using u-boot + u-boot-menu is much simpler than having to
make uImage or u-boot FIT images or any of the other ideas expressed in
this thread... configure your config.txt to point to the u-boot binary,
install u-boot-PLATFORM, u-boot-menu, and mark your rootfs as a bootable
partition and it should "just work" with the standard kernel and initrd
and .dtb files provided by Debian.

If you need features not present in the Debian provided kernels I'm not
sure what complicated hoops you may need to jump through to get the
system to boot.


live well,
  vagrant

p.s. Disclaimer: I maintain u-boot in Debian, so maybe I'm biased.

Staying on topic for the list (was Re: loss of synaptic due to wayland)

[Vagrant Cascadian]

Several people have asked in the past including myself, and at least one
other person has asked on this and maybe other recent threads...

Could you please keep on topic for debian-arm?

Simply running debian on an arm system doesn't really give free license
to talk about anything and everything about that system, or other
arbitrary topics entirely unrelated to it. I recognize it's not a black
and white issue, but please make (more of) an effort to stay on topic.

This is expressly listed in:

  https://www.debian.org/MailingLists/#codeofconduct

In particular:

  "Make sure that you are using the proper list. In particular, don't
  send user-related questions to developer-related mailing lists."


Thanks for considering.


live well,
  vagrant

On 2019-07-08, Gene Heskett wrote:
> On Monday 08 July 2019 10:12:31 Luke Kenneth Casson Leighton wrote:
>
>> On Mon, Jul 8, 2019 at 2:01 PM Andrei POPESCU 
>  wrote:
>> > On Lu, 08 iul 19, 07:42:46, Gene Heskett wrote:
>> > > yes it was, and no solution was offered that I read about. And no,
>> > > aptitude is not a replacement. I've hit q for quit and had it tear
>> > > a working system down to doing a reinstall to recover, 3 times
>> > > now.
>> >
>> > I used to be a heavy aptitude user in the past, on unstable (i.e.
>> > almost daily package upgrades). It does have it quirks. It also
>> > shows very clearly what it is about to do before you press the final
>> > 'g'.
>>
>>  indeed, as does apt-get (which i much prefer).  ultimately, if you
>> are... how can i put this diplomatically... a GUI gives you the "nice
>> warm feeling" on presenting you with a nice warm cozy dialog box, "Are
>> You Sure You Wanna Do This".
>>
>>  apt and aptitude it is assumed that you are... well... hum no
>> other way to say it really. it is assumed that you are... um...
>> capable of reading?
>>
> I am not as fast as I was once tested at 350 a minute with 95% 
> comprehension 70+ years ago, one does not become one of the 1% or 2% 
> that survive a pulmonary embolism without some thinker damage.
>
>>  sorry if that sounds like it's terribly insulting, there's really not
>> a way to say it without implying so, because if you don't actually
>> read the warning - no matter that it's in words that are not
>> bold-faced and surrounded by a big dialog box - you basically get to
>> learn *why* the warning is there.
>
> Absolutely, the worst effect that I am rather painfully aware of is a 
> noticeably poorer short term memory. 
>>
>> > > It may be capable, but imnsho its also dangerous. Having it do
>> > > anything but quit instantly when you hit the quit key q, hit
>> > > because you're lost is unforgivable.
>
> I should have qualified that with "and it was doing nothing until I hit 
> the q." I didn't get the "are you sure" popup whose default is no, it 
> just started hammering on the drive.
>
>> > Thanks, but no thanks. Having it exit immediately in the middle of a
>> > complex upgrade just because I hit 'q' by mistake is not nice and
>> > might leave your system in a very bad state.
>> >
>> > Once an action has been started it might be possible to interrupt it
>> > with Ctrl+C. Please do so at your own risk.
>>
>>  synaptics i presume actively prevents and prohibits such termination.
>>
>>  recovery of a system that's been terminated in the middle of an
>> install can actually damage the dpkg database.  apt and aptitude exec
>> dpkg to install individual packages, and, as anyone knows who has
>> tried to manually install a .dpkg, you interrupt that process, as
>> andrei says, at your own risk.
>>
>>  of course, it is perfectly possible to f*** up with synaptics as
>> well: "killall -9 synaptics" whilst it's in the middle of an install
>> will achieve the exact same level of system-fg-up-ness.
>>
>>  if you really _really_ get into such a mess, the first action to take
>> is "apt-get -f install".  this sually recovers things back to a
>> known stable state, and you can re-run apt-get {whatever}
>>
>>  sometimes i've had to do a dpkg -i --force-all {insert package that
>> failed.deb}, particularly on systems where there's been file conflicts
>> (very old packages still installed, where new ones have the same
>> file).
>>
>>  ultimately, though, there is absolutely *NO* excuse for quotes
>> reinstalling quotes.  any debian system is ENTIRELY RECOVERABLE
>> without resorting to the stupidity of the windows mindset "if it's
>> broke duhhh reinstall".  in really *really* broken conditions (a
>> kernel upgrade interrupted, a grub replacement gone wrong), you can
>> run recovery live USB boot media, and repair the damage by chrooting
>> in to the root filesystem.
>>
>> in one hilarious incident involving "cpio" i managed to write ARM
>> files onto an x86 filesystem (in /lib, /usr/lib, /bin and /sbin) *and
>> still recovered the system* by live-booting a recovery USB stick,
>> manually downloading the relevant dpkgs, unpacking them and
>> hand-copying the accidentally-replaced 

Re: Debian Installer on Pine64+ (no serial console)

[Vagrant Cascadian]

On 2019-05-05, Andrei POPESCU wrote:
> On Sb, 04 mai 19, 12:29:30, Vagrant Cascadian wrote:
>> 
>> The really important A64 timer issue fix finally went in 4.19.28-1,
>> without which the clock would occasionally leap 90+ extra years into the
>> future and find yourself experiencing all sorts of stability problems:
>
> Hmm, apparently erratum 843419 is not sufficient.
> https://lore.kernel.org/patchwork/patch/1031565/
>
> Any chance to get this in fix in buster?

My bad, I looked into backporting the full workaround, only to find it
was already committed upstream in 4.19.31... The next 4.19.x upload will
contain the workaround, though, which should be soon.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Debian Installer on Pine64+ (no serial console)

[Vagrant Cascadian]

On 2019-05-04, Andrei POPESCU wrote:
> On Sb, 04 mai 19, 06:57:43, Andrei POPESCU wrote:
>> 
>> I'm ready to start a second try where I will be using manual 
>> partitioning (without GPT), hoping I will get a bootable system.
>
> This worked, see 
> https://wiki.debian.org/InstallingDebianOn/PINE64/PINEA64

Thanks for the wiki page!

It's definitely frustrating that sunxi64 installs the bootloader and
boot firmware at an offset incompatible with GPT partitioning... I've
heard there might hacks to set up a compatible GPT partition table, but
the defaults are definitely incompatible. :/

The device-tree included with u-boot is what's used by the
debian-installer images in conjunction with the EFI .iso, but I usually
find things more reliable to use the .dtb included with the
kernel. Occasionally the inverse is true; it really depends on your
u-boot version + kernel combination... which is unfortunate.

I've been meaning to create SD images for arm64 in debian-installer like
you do in the wiki page, but haven't had a chance to do so and it's
arguably a bit late in the release cycle for buster... but maybe not too
bad; much of the code from the armhf SD images could probably be
re-used.


I did backport some device-tree patches to 4.19.x to get framebuffer
video for pinebook, but never tested HDMI on the pine64. Glad to hear
it's working ok! I should test it myself sometime... I'm running two
early-generation pine64+ boards in the reproducible builds test
framework as headless machines, and have another I boot occasionally to
test.


The sound modules should be included in the next linux 5.x upload:

  
https://salsa.debian.org/kernel-team/linux/commit/0e9aed9c58417946afb74607dfa3da2ed20699a3


The really important A64 timer issue fix finally went in 4.19.28-1,
without which the clock would occasionally leap 90+ extra years into the
future and find yourself experiencing all sorts of stability problems:

  https://en.wikipedia.org/wiki/Year_2038_problem


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Fixing stretch debian-installer on armhf

[Vagrant Cascadian]

On 2019-03-09, Adam D. Barratt wrote:
> On Thu, 2019-03-07 at 22:01 +, Ben Hutchings wrote:
>> On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
>> [...]
>> > > * Rebuild the debian-installer images, pulling in updates from
>> > >   stretch-updates, leaving only armhf netboot targets broken. 
>> > 
>> > Expanding a bit: rebuilding src:debian-installer from the stretch
>> > branch, which has s-p-u enabled, would fetch the fixed kernel and a
>> > couple of its udebs, at build time; the resulting netboot images
>> > wouldn't know about s-p-u though at run time, and would try to load
>> > udebs from stretch.
>> 
>> [...]
>> 
>> Why is that a problem?  The only change made in 4.9.144-3.1 is in the
>> kernel image, and the module udebs don't have versioned dependencies.
>
> However, as an additional data point, the kernel currently sat in NEW
> and destined for stable has an ABI bump. If that's accepted, then I
> assume things will "just work" in the meantime as the old binary
> packages will hang around until they're decrufted, but it's worth
> bearing in mind.

A debian-installer build for stretch-proposed-updates was made, which
may not get merged into stretch before the next point release. For the
time being:

  
https://deb.debian.org/debian/dists/stretch-proposed-updates/main/installer-armhf/

I've successfully tested version "20170615+deb9u5+b3", as well as at
least one other person. It should continue to work until the next point
release, and I'll do at least some minimal testing of the next point
release on armhf before pushing it to stretch so this doesn't happen
again.

More details in:

  https://bugs.debian.org/924129


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Installation media for arm64

[Vagrant Cascadian]

On 2019-03-23, Christian Kastner wrote:
> I recently purchased a A64-OLinuXino and I believe it should be
> supported by the tooling in buster.
...
> For armhf, SD card images are provided [3], this seems incredibly
> useful. I couldn't find any for arm64, nor could I find a hd-media
> tarball. Are there any plans to provide these in future? I'd be
> willing to serve as a tester.

There are u-boot images for related platforms:

  https://d-i.debian.org/daily-images/arm64/daily/u-boot/

Might be a one-liner to add A64-OLinuXino for debian-installer.


Those can be used with the EFI boot media on USB:

  https://d-i.debian.org/daily-images/arm64/daily/netboot/mini.iso

It might be worth exploring setting up proper SDCard images too, since
having to have two different media is a bit annoying.


Though I know there's some reluctance to introduce non-EFI booting on
arm64, there are a handful of platforms which just work a lot better
using u-boot and the .dtb shipped with the booted kernel version. And
the allwinner ATF implementation media offset conflicts with GPT, which
our current EFI images use...


As usual, it's always a lot harder than anyone feels like it should
be. :/


live well,
  vagrant

Re: Fixing stretch debian-installer on armhf

[Vagrant Cascadian]

On 2019-03-07, Ben Hutchings wrote:
> On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
> [...]
>> > * Rebuild the debian-installer images, pulling in updates from
>> >   stretch-updates, leaving only armhf netboot targets broken. 
>> 
>> Expanding a bit: rebuilding src:debian-installer from the stretch
>> branch, which has s-p-u enabled, would fetch the fixed kernel and a
>> couple of its udebs, at build time; the resulting netboot images
>> wouldn't know about s-p-u though at run time, and would try to load
>> udebs from stretch.
> [...]
>
> Why is that a problem?  The only change made in 4.9.144-3.1 is in the
> kernel image, and the module udebs don't have versioned dependencies.

If that's indeed the case, then that does seem like the best
approach. Happy to test images to confirm.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: How do I find out where u-boot environment is stored?

[Vagrant Cascadian]

On 2019-03-06, Rick Thomas wrote:
> Anybody know how can I determine where u-boot is storing it’s environment?
> Is there an environment variable where that info is stored?
> (-: Any ironic self-reference in the previous question is entirely 
> un-intentional… ;-)

At least for recent u-boot packages in Debian:

  $ zgrep ^C.*ENV_IS_IN /usr/share/doc/u-boot-*/configs/config.*
  
/usr/share/doc/u-boot-sunxi/configs/config.a64-olinuxino.gz:CONFIG_ENV_IS_IN_FAT=y
  
/usr/share/doc/u-boot-sunxi/configs/config.pine64_plus.gz:CONFIG_ENV_IS_IN_FAT=y
  /usr/share/doc/u-boot-sunxi/configs/config.pinebook.gz:CONFIG_ENV_IS_IN_FAT=y

To get more detailed information, you may need to read the source for
the relevent board.


live well,
  vagrant


signature.asc
Description: PGP signature

Fixing stretch debian-installer on armhf

[Vagrant Cascadian]

Due to #922478, the debian-installer images for stretch are currently
not bootable on the armhf architecture.

While the linux kernel packages have been fixed in stretch-updates and
stretch-proposed-updates, the debian-installer images still were built
with the broken kernel.

Even rebuilding the debian-installer images, while pulling in a working
kernel that would boot, debian-installer would load .udeb modules from
stretch, not stretch-updates. This might be ok for hd-media targets or
targets that do not load module .udeb files from the network, but
netboot targets are not likely to work at all.

So some of the options at the moment appear to be:

* Wait for another point release, rebuild debian-installer, leaving
  debian-installer on armhf broken until then. How long till the next
  point release?

* Rebuild the debian-installer images, pulling in updates from
  stretch-updates, leaving only armhf netboot targets broken. 

* Another point release with the kernel update sooner than planned, and
  rebuild debian-installer images.

* Other options?


In the future, I plan on setting up at least one or two of armhf
machines running stable-proposed-updates to try to catch this sort of
thing before release...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Does ARMEL toolchain include NEON support?

[Vagrant Cascadian]

On 2019-02-27, Jeffrey Walton wrote:
> I'm investigating a failed build for ARMEL. I don't have access to the
> build machine so I have to study the logs or ask our package
> maintainer to run commands for us.
>
> The build log is at
> https://buildd.debian.org/status/package.php?p=libcrypto%2B%2B=experimental
> (package) and 
> https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B=armel=8.1.0-1=1551251751=0
> (ARMEL).
>
> We have tried to use -mfpu=neon and -mfloat-abi=softfp or
> -mfloat-abi=hard for the NEON specific files but both produce compile
> failures. "NEON specific files" are ones with the name *_simd.cpp,
> like aria_simd.cpp.
>
> I test the build locally with about 6 ARM dev-boards and have not
> encountered the problem. However, all of the dev-board are hard float
> machines.
>
> My question is, is it possible to use the NEON unit when building with
> ARMEL? If so, then how do we do it?

My understanding is that neither armhf nor armel assume the presence of
NEON; it's optional, and code must not be built forcing the use of NEON
on those architectures.

NEON support needs to be detected at runtime, and the code handle if
NEON is not present.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: fw_printenv says "Warning: Bad CRC, using default environment"

[Vagrant Cascadian]

On 2019-02-26, Rick Thomas wrote:
>> On Feb 26, 2019, at 10:49 AM, Vagrant Cascadian  wrote:
>> 
>> On 2019-02-26, Rick Thomas wrote:
>>> On my Cubox-i4Pro when I run fw_printenv (from the u-boot-tools
>>> package) it says “Warning: Bad CRC, using default environment”.
...
>> fw_printenv will only work if there's an environment saved; it doesn't
>> read from u-boot’s built-in defaults.
>
> So, if fw_printenv can’t see the environment that’s actually in use,
> what tool do you recommend for examining the u-boot environment from
> Linux?

I don't recommend using a tool from linux. Boot into u-boot and run
"printenv".


>> I generally recommend to avoid using "saveenv" and "fw_saveenv", since
>> most modern boards work with distro_bootcmd and there are various
>> options to configure the system at boot, such as boot scripts.
>
> I presume you mean “fw_setenv” (there doesn’t seem to any “fw_saveenv”
> command in the “u-boot-tools” package)?

Correct.

>> Having a saved environment means you're stuck with whatever environment
>> variables were present when you last ran "saveenv", which means any bugs
>> fixed in newer versions of u-boot will still be present, and worst case,
>> they might even be incompatible with the version of u-boot you're
>> running. It will also happily save auto-detected variables.
>> 
>> Additionally, "fw_saveenv" may require you to specify the entire
>> environment to save, rather than just values you want to change.
>
> So please help me understand this… If “saveenv” under u-boot is
> dangerous, and “fw_setenv” under Linux should not be used, what’s the
> purpose of having a persistent environment at all?  Is it just a
> historical relic that has outlived it’s usefulness; or am I missing
> something subtle (more likely)?

There are valid uses of it, and if you know exactly what you're doing,
that's fine.

In general, I think it's better to use other methods to adjust the
environment at run-time (e.g. boot scripts).


>>> A couple of more data points that may shed light on this:
>>> 
>>>> root@cube:~# cat /etc/fw_env.config 
>>>> # Configuration file for fw_(printenv/saveenv) utility.
>>>> # Up to two entries are valid, in this case the redundant
>>>> # environment sector is assumed present.
>>>> #
>>>> # XXX this configuration might miss a fifth parameter for the "Number of
>>>> # sectors"
>>>> 
>>>> # MTD device name   Device offset   Env. size   Flash sector size
>>>> /dev/mmcblk1p10x8 0x2000
>> 
>> This looks like a bug in your configuration; it should specify the raw
>> device rather than a partition.
>
> This is “fresh out of the box” configuration.  I haven’t changed a
> thing.  So, if this is wrong (which it clearly is) should I be
> reporting it as a bug in the “u-boot-tools” package?  Where did this
> file come from?  It doesn’t seem to be present in either of the
> “u-boot-tools” or “u-boot-imx” packages according to “dpkg-query -L”.

None of the u-boot packages install anything into /etc, so it's not a
bug in any of the u-boot packages. If something else installed it
without user intervention, it might be a bug in that package, but
whatever did it doesn't appear to be in any package in Debian:

  https://codesearch.debian.net/search?q=fw_env.config


>>>> root@cube:~# cat /usr/share/doc/u-boot-tools/examples/mx6cuboxi.config 
>>>> # Configuration file for fw_(printenv/saveenv) utility.
>>>> # Up to two entries are valid, in this case the redundant
>>>> # environment sector is assumed present.
>>>> #
>>>> # XXX this configuration might miss a fifth parameter for the "Number of
>>>> # sectors"
>>>> 
>>>> # MTD device name   Device offset   Env. size   Flash sector size
>>>> /dev/mmcblk00x8 0x2000
>>> 
>>> FWIW the micro-SD card on this box is identified as /dev/mmcblk1 — not
>>> as either /dev/mmcblk0 or /dev/mmcblk1p1.
>> 
>> Between versions of linux and u-boot the numbering of the devices may
>> vary. In general, the numbering of such devices has gotten more stable
>> over time, but it’s totally plausible that device numbers may vary.
>
> Ah… I see.  Would it make sense to note this fact in the comments?

These are in the "examples" section for a reason, and the end-user needs
to adapt them to match their hardware configuration.


>>> Does this represent a bug in u-boot-tools, or am I mis-interpreting
>>> something?
>>

Re: arch-test and armel on arm64

[Vagrant Cascadian]

On 2019-02-26, Adam Borowski wrote:
> Hi!
> Could you guys please educate me what's the matter with SWP on armel these
> days?  It seems that almost no programs use it anymore.  Should I remove the
> check for SWP from arch-test, so it reports a machine+kernel as capable of
> running armel even if it neither supports nor emulates this instruction?
>
> I somehow can't reproduce the crashes even with jessie's armel.  I remember
> reproducing such fails, including more subtle cases where instead of a clean
> SIGILL the intruction was silently ignored, resulting in code that appeared
> to work unless there's multithreaded lock contention.  So where did the
> crashes go?  I don't claim to understand this anymore...
>
> Thus, would it be a good idea to just ignore the SWP issue and let
> debootstrap proceed?

I have a strong feeling this is related to these two bugs, for a little
more background:

arch-test: reports armel invalid on arm64 system:

  https://bugs.debian.org/922728

debootstrap: unable to override arch-test:

  https://bugs.debian.org/922729


live well,
  vagrant


signature.asc
Description: PGP signature

Dreamplug fails to detect SPI and USB

[Vagrant Cascadian]

On 2019-02-26, Leigh Brown wrote:
> I tested u-boot 2019.01+dfsg-1 on my Globalscale Dreamplug and it 
> doesn't work:
>
> U-Boot 2019.01+dfsg-1 (Jan 15 2019 - 00:36:19 +)
> Marvell-DreamPlug
>
> SoC:   Kirkwood 88F6281_A1
> DRAM:  512 MiB
> Loading Environment from SPI Flash... Invalid bus 0 (err=-19)
> *** Warning - spi_flash_probe_bus_cs() failed, using default environment
>
> In:serial
> Out:   serial
> Err:   serial
> Net:   egiga0
> Error: egiga0 address not set.
> , egiga1
> Error: egiga1 address not set.
>
> 88E1116 Initialized on egiga0
> 88E1116 Initialized on egiga1
> IDE:   ide_preinit failed
> Hit any key to stop autoboot:  0
> => usb start
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008c80
> EHCI timed out on TD - token=0x80008c80
> EHCI timed out on TD - token=0x80008c80
>   ERROR: NOT USB_CONFIG_DESC a3
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008c80
> EHCI timed out on TD - token=0x80008c80
> 2 USB Device(s) found
> scanning usb for storage devices... 0 Storage Device(s) found
>
> So it cannot detect USB or SPI Flash.

I don't think Debian carries any particular patches that would affect
the dreamplug target and I'm not seeing any obvious changes in
upstream's master branch since v2019.01.

It would be good to find out the last known working version, if
possible:

  https://snapshot.debian.org/package/u-boot/


Please file a bug in the Debian bug tracker so I can keep track of this
issue in Debian:

  https://www.debian.org/Bugs/Reporting


live well,
  vagrant


signature.asc
Description: PGP signature

Re: fw_printenv says "Warning: Bad CRC, using default environment"

[Vagrant Cascadian]

On 2019-02-26, Rick Thomas wrote:
> On my Cubox-i4Pro when I run fw_printenv (from the u-boot-tools
> package) it says “Warning: Bad CRC, using default environment”.

If when booting, it also gives you this message, that would suggest you
have no saved environment for fw_printenv to read from, as it's using
the default environment. I recommend not using "saveenv" or "fw_saveenv"
for reasons described below...


> The “default environment” is clearly *not* the environment that u-boot
> is using to boot the box.  At least the “ethaddr” variable in that
> environment is clearly a fake one as show here:
>
>> root@cube:~# fw_printenv ethaddr
>> Warning: Bad CRC, using default environment
>> ethaddr=00:00:11:22:33:44
>
> This is definitely not the ethernet address that the box is using for dhcp.

fw_printenv will only work if there's an environment saved; it doesn't
read from u-boot's built-in defaults.

I generally recommend to avoid using "saveenv" and "fw_saveenv", since
most modern boards work with distro_bootcmd and there are various
options to configure the system at boot, such as boot scripts.

Having a saved environment means you're stuck with whatever environment
variables were present when you last ran "saveenv", which means any bugs
fixed in newer versions of u-boot will still be present, and worst case,
they might even be incompatible with the version of u-boot you're
running. It will also happily save auto-detected variables.

Additionally, "fw_saveenv" may require you to specify the entire
environment to save, rather than just values you want to change.


> A couple of more data points that may shed light on this:
>
>> root@cube:~# cat /etc/fw_env.config 
>> # Configuration file for fw_(printenv/saveenv) utility.
>> # Up to two entries are valid, in this case the redundant
>> # environment sector is assumed present.
>> #
>> # XXX this configuration might miss a fifth parameter for the "Number of
>> # sectors"
>> 
>> # MTD device name   Device offset   Env. size   Flash sector size
>> /dev/mmcblk1p10x8 0x2000

This looks like a bug in your configuration; it should specify the raw
device rather than a partition.


>> root@cube:~# cat /usr/share/doc/u-boot-tools/examples/mx6cuboxi.config 
>> # Configuration file for fw_(printenv/saveenv) utility.
>> # Up to two entries are valid, in this case the redundant
>> # environment sector is assumed present.
>> #
>> # XXX this configuration might miss a fifth parameter for the "Number of
>> # sectors"
>> 
>> # MTD device name   Device offset   Env. size   Flash sector size
>> /dev/mmcblk00x8 0x2000
>
> FWIW the micro-SD card on this box is identified as /dev/mmcblk1 — not
> as either /dev/mmcblk0 or /dev/mmcblk1p1.

Between versions of linux and u-boot the numbering of the devices may
vary. In general, the numbering of such devices has gotten more stable
over time, but it's totally plausible that device numbers may vary.


> Does this represent a bug in u-boot-tools, or am I mis-interpreting
> something?

My guess is just your misconfiguration above, and hopefully that you
have no saved environment for the tools to read from.


live well,
  vagrant


signature.asc
Description: PGP signature

Testing u-boot targets for buster!

[Vagrant Cascadian]

Hello fine u-boot testers. You were one of the gracious people who
offered to test one or more u-boot targets from the debian
packages. Thanks!

  https://salsa.debian.org/debian/u-boot/blob/master/debian/targets

Since we're in the process of freezing Buster, at the very least I would
like to get positive confirmation that each platform is still
working. Please test your boards and update:

  https://wiki.debian.org/U-boot/Status

There have been a variety of regressions in u-boot versions over time,
and I would really hate to release Buster for any platform with a broken
u-boot.

I've tested a few myself, but I can't possibly test them all.

If you're unable to continue to test a particular platform in the
future, please let me know that as well, and I'll update the file
accordingly.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Bug#922729: debootstrap: unable to override arch-test

[Vagrant Cascadian]

On 2019-02-20, John Paul Adrian Glaubitz wrote:
> On 2/19/19 11:56 PM, Vagrant Cascadian wrote:
>> I tried installing an armel chroot on an arm64 machine:
>> 
>>   $ sudo debootstrap --variant=minbase --arch=armel --no-merged-usr 
>> --verbose sid /srv/chroots/armeltest http://deb.debian.org/debian/
>>   E: Unable to execute target architecture
>
> I just pass --foreign in these case and then chroot into the target to
> run ./debootstrap/deboostrap --second-stage.
>
> Alternatively, use qemu-deboostrap.

Ok, I guess those are also workarounds, but --second-stage seems like a
lot of extra hoops to jump through, and qemu-debootstrap +
qemu-user-static seems resource inefficient on a system that should
otherwise be able to support it "natively".


live well,
  vagrant


signature.asc
Description: PGP signature

Re: After update to latest Stretch--boot stops

[Vagrant Cascadian]

On 2019-02-19, Nate Bargmann wrote:
> * On 2019 19 Feb 15:11 -0600, Vagrant Cascadian wrote:
>> On 2019-02-19, Nate Bargmann wrote:
>> > I've been running Stretch on my Olimes A20-Olinuxino Micro for several
>> > months without issue until just a while ago.  I performed an update
>> > through Aptitude whereupon the latest version of systemd and kernel were
>> > updated.  After a proper shutdown and restart the boot process stalls
>> > at the point where "Starting kernel ..." is displayed.
>> 
>> It's a known problem, see:
>> 
>>   https://lists.debian.org/debian-arm/2019/02/msg00011.html
>>   https://bugs.debian.org/922478
>> 
>> A fix is in process of getting pushed out.
>> 
>> You'll probably need to boot an older kernel to update to the new one
>> once it's available...
>
> Thanks Vagrant and Steve for the quick replies!
>
> There is an older kernel in /boot with a symlink of vmlinuz.old pointing
> to it.  As I've not studied uboot in depth, is there an "easy" way of
> booting that kernel?  I've been poking around the Debian Wiki, but have
> yet to find the trick to selecting another kernel as in Grub which I am
> more familiar with.

If you're using the flash-kernel boot script, from the u-boot prompt:

  setenv fk_kvers 4.9.0-7-armmp

You might have to do "ls mmc 0:1" or wherever your boot partition is to
find the correct version.


It doesn't help you right now, but in the future you might want to
experiment with the "u-boot-menu" package(in testing and
stretch-backports), which should work out of the box for many boards as
long as /boot, / and /usr/lib/linux-image-* are on the same partition
and the device-tree defines the default console (and with some tweaks
and cooperation from flash-kernel can work with a split /boot as well).


live well,
  vagrant


signature.asc
Description: PGP signature

Re: After update to latest Stretch--boot stops

[Vagrant Cascadian]

On 2019-02-19, Nate Bargmann wrote:
> I've been running Stretch on my Olimes A20-Olinuxino Micro for several
> months without issue until just a while ago.  I performed an update
> through Aptitude whereupon the latest version of systemd and kernel were
> updated.  After a proper shutdown and restart the boot process stalls
> at the point where "Starting kernel ..." is displayed.

It's a known problem, see:

  https://lists.debian.org/debian-arm/2019/02/msg00011.html
  https://bugs.debian.org/922478

A fix is in process of getting pushed out.

You'll probably need to boot an older kernel to update to the new one
once it's available...


live well,
  vagrant


signature.asc
Description: PGP signature

linux-image-4.9.0-8-armmp-lpae:armhf 4.9.144-3 renders many systems unbootable

[Vagrant Cascadian]

I strongly advise to hold off on updating your kernels on stretch armhf
systems until this issue is resolved:

  upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to
  4.9.144-3 renders many systems unbootable

  https://bugs.debian.org/922478

I haven't yet seen an armhf system that can boot the kernel shipped with
stretch's latest point release. Fix is in progress and will hopefully be
resolved soon...


live well,
  vagrant

support for OpenRD and Sheevaplug (was Re: Debian Installer Buster Alpha 4 release)

[Vagrant Cascadian]

On 2018-12-17, Rick Thomas wrote:
>> On Dec 15, 2018, at 2:26 PM, Cyril Brulebois  wrote:
>> 
>> Hardware support changes
>> 
>> 
>> * debian-installer:
>>   - [armel] Disable OpenRD targets, no longer present in u-boot.
>
> Does this mean that my OpenRD hardware will no longer be supported in Buster?
> What about SheevaPlug hardware?  Is that still supported by upstream u-boot?
>
>> * u-boot:
>   …
>>   - [armel] Drop openrd targets (no longer supported upstream).
>
> Nice, physically small, reliable hardware…  A shame to see it go…

It's marked as Orphaned in upstream u-boot for 3 months, and failed to
build from source whenever it was I disabled it. With nobody working to
fix it upstream, I dropped it from the Debian u-boot package. You'll can
probably continue to use it with an old u-boot version.

It might continue to work with the buster kernels... I would strongly
recommend testing it and reporting and fixing bugs sooner than later if
you want to make sure it continues to be supported.

Sheevaplug continues to build and is listed as Maintained in upstream
u-boot, but it's an old enough platform that I'd recommend testing it
for those who want to ensure continued support...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Debian buster on Pine64+ (2 GiB RAM)

[Vagrant Cascadian]

On 2018-12-09, Andrei POPESCU wrote:
> On Du, 09 dec 18, 10:23:02, Christian Marillat wrote:
>> 
>> I don't see issues with the experimental kernel 4.19.5-1~exp1 :
>
> Could the issue be with u-boot then, possibly not initializing the 
> hardware correctly?
>
> I'm using the u-boot-sunxi 2018.11+dfsg-1 package from Debian.

I've also tested it with 2018.11+dfsg-1(and nearly all of the versions
uploaded to debian), and it works for me more reliably than earlier
u-boot versions.

I've seen occasional issues on the pine64+ with ethernet either not
showing a device at all, or with showing a device but being unable to
get a dhcp lease... I have an early generation pine64+ with a hardware
bug that works much better forcing it to 100mbit speeds...

The allwinner-A64 also tends to have issues with the clock being
unstable; periodically leaping into the future by 90+ years... which
cause all sorts of issues... such as dhcp leases are always expired.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Debian buster on Pine64+ (2 GiB RAM)

[Vagrant Cascadian]

On 2018-12-08, Andrei POPESCU wrote:
> I'm trying to run buster on a Pine64+ (2 GiB RAM). So far I created the 
> rootfs with debootstrap, installed linux-image-arm64 and ran 
> u-boot-install-sunxi64 on the SD card.
>
> The systems boots only to the u-boot prompt, so I'm missing something to 
> have u-boot find and load the kernel.

You'll want u-boot-menu and/or flash-kernel installed. I'd recommend
u-boot-menu since you have a simple partition layout.


> In case it matters, the SD card has only one ext4 partition marked 
> bootable and I have HDMI output and keyboard input at the u-boot prompt 
> (I don't have serial).

Glad to hear HDMI output is working!

I would strongly recommend getting a serial adapter as well in case you
need it at some point. In case the kernel version you have installed
doesn't yet support HDMI or other surprises along the way.

I'm writing from a pinebook, a close cousin to the pine64+ :)


live well,
  vagrant


signature.asc
Description: PGP signature

#9065700: firefox-esr segfaults during startup on arm64

[Vagrant Cascadian]

Control: found 906570 60.3.0esr-1
Control: found 906570 60.3.0esr-2

I've been having this same issue on a Pinebook.

The versions in stretch are also problematic; I tried those first before
the newer versions landed in buster, but I haven't confirmed which
versions for sure.

On the positive side, it seems firefox version 63.0.3-1 works fine, but
newer versions won't likely be included in buster or stretch until the
next esr release.

Attached is an strace log, from a fresh user, if that's any help. I
forgot to disable extensions, if that matters, I could probably try
again...

live well,
  vagrant



firefox-esr.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Regression in linux 4.9.x security update

[Vagrant Cascadian]

There's been a regression in linux 4.9.110-3+deb9u3 in stable security
updates causing problems booting various arm64 and arm systems.

I'd recommend avoiding upgrading your kernel until the issue is sorted
out, unless you love debugging these sorts of things.

For the details, please see:

  https://bugs.debian.org/906769


live well,
  vagrant


signature.asc
Description: PGP signature

Re: u-boot-mvebu for ESPRESSObin

[Vagrant Cascadian]

On 2018-08-12, Jan Kiszka  wrote:
> am I right that the u-boot.bin from the buster package u-boot-mvebu is 
> not for direct consumption by the ESPRESSObin?

You are right.


> All documents I found say that it has to be embedded into an ATF
> module, forming the final SPI flash content.

Yes. It's one of the more convoluted processes I've seen:

  http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Bootloader

But instead use the mainline/debian packaged u-boot, and experimented
with the parameters passed to make when building the vendor ATF to try
and get a working ram configuration. And of course the documentation is
a bit dated from the actual source code.

I found it pretty tedious and error-prone. It also happens to be
backwards from several other platforms I've seen (e.g. allwinner), where
the build process is build ATF, build u-boot (which incorporates ATF),
and also happens to be possible to build the various pieces
independently of their respective build processes and assemble a
bootable image out of the various parts (e.g. u-boot-install-sunxi64).


> Is there anything along this line packaged already?

Not to my knowledge.


It looks like upstream ATF has support for a3700, so might also be
possible to package this. But it seems to require a different build for
each ram configuration, which is... an unfortunate number of
permutations. And also requires embedding u-boot at ATF build-time...  I
haven't figured out how to properly packages A3700-tools, which seems to
also be built as part of the build process.


> what is the purpose/plan for this u-boot package?

To at least reduce the number of things the end-user has to build.

Unfortunately, I haven't had luck getting mainline u-boot to recognize
more than 512MB of ram.

Since the process is a little ugly and poorly documented, I've debated
removing this target from buster... help in improving the situation
would be greatly appreciated!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Bootstrapping an Olimex A64-OLinuXino

[Vagrant Cascadian]

On 2018-03-13, Martin Lucina  wrote:
> I'm trying to bootstrap an Olimex A64-OLinuXino board from scratch, using
> Debian stretch on x86_64 as the build host. So far, I've:
>
> - cross-built mainline U-boot 2018.01 including the SPL and BL31 from latest
>   https://github.com/apritzel/arm-trusted-firmware.git#allwinner and
>   a64-olinuxino_defconfig:

atf-allwinner is now in Debian (buster/testing and sid/unstable):

  https://tracker.debian.org/atf-allwinner

Also, there is a bug report about enabling the a64-olinuxino in Debian's
u-boot package, it just lacks someone committing to test it:

  https://bugs.debian.org/881564

  https://wiki.debian.org/U-boot/


Presuming the linux kernel support is ok enough, that *might* be enough
to then enable debian-installer builds for this board.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Using a custom device tree file

[Vagrant Cascadian]

On 2018-02-19, Rainer Dorsch wrote:
> Am Samstag, 17. Februar 2018, 16:22:06 CET schrieb Vagrant Cascadian:
>> > Can anybody tell, if it is possible to configure from u-boot shell to
>> > loada
>> > custom device treefile?
>> 
>> To manually change it for a one-off boot:
>> 
>>   # disable the built-in setting of fdtfile
>>   setenv findfdt
>>   # manually set fdtfile
>>   setenv fdtfile /path/to/your/custom.dtb
>
> Where is findfdt defined?

In the built-in u-boot environment on some boards. Typically with u-boot
variants that can support multiple similar boards; a single mx6cuboxi
u-boot binary supports several cubox-i and hummingboard variants.

It's typically run from bootcmd, so "printenv bootcmd" from the u-boot
prompt might show something like "run findfdt ; run distro_bootcmd".


>>From looking into the bootscr fdtfile needs only the filename:
>
> if test -n "${fdtfile}"; then
>setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
> else
>setenv fdtpath dtb-${fk_kvers}
> fi
>
> Correct?

Ah, yes, full path wouldn't work in this case- you'd have to have it in
one of the above locations the boot scripts look for.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Using a custom device tree file

[Vagrant Cascadian]

On 2018-02-18, Gene Heskett wrote:
> On Saturday 17 February 2018 19:22:06 Vagrant Cascadian wrote:
>> On 2018-02-17, Rainer Dorsch wrote:
>> > Am Sonntag, 11. Februar 2018, 22:24:51 CET schrieb Rainer Dorsch:
>> >> Am Sonntag, 11. Februar 2018, 13:20:07 CET schrieb Vagrant Cascadian:
>> >> > On 2018-02-11, Rainer Dorsch wrote:
...
> Thank you very very much, this is probably the post, a howto, that I've 
> been looking for, for months.

Glad it was helpful.


> Now my problem is that the db for flash-kernel is 2 or 3 years out of 
> date and contains no mention of either the pi-3b,

Please report bugs against flash-kernel, but please first check against
current versions of flash-kernel. There's support for raspberry pi 2b
and and 3b in the current version of flash-kernel.

You can sometimes grab the relevent stanzas from newer versions and use
them on the old version of flash-kernel by adding them to
/etc/flash-kernel/db:

  Machine: Raspberry Pi 3 Model B
  Kernel-Flavors: arm64 armmp armmp-lpae
  DTB-Id: bcm2837-rpi-3-b.dtb
  U-Boot-Script-Name: bootscr.uboot-generic
  Required-Packages: u-boot-tools
  Boot-Script-Path: /boot/boot.scr


I am using the pi 2b with the version of linux and flash-kernel from
Debian stretch. Raspbian's kernel likely has the legacy device-tree
names and you might have to adjust flash-kernel configuration for
that. Raspbian also doesn't typically use u-boot for a bootloader, and
flash-kernel doesn't do anything to configure booting from the default
boot firmware.


> nor the pine offering called the rock64.

There isn't support for the rock64 in mainline u-boot, and I'm not sure
how good the linux kernel support is. So I'm not sure it makes sense to
add a flash-kernel entry for it until it's better supported in mainline
linux and u-boot; Debian doesn't usually add support that isn't present
in mainline, as long-term maintenance impractical.

I've got one, so I'll keep an eye on it and try to enable support in
Debian as it becomes available.


> And quite likely, u-boot-tools is also dated.

I'm not sure what you're referring to here, but there's u-boot 2018.01
in experimental, and 2017.11 in sid/buster. There's a 2018.03-rc1 that I
haven't yet uploaded.  Stretch has the most recent u-boot version at the
time of stretch freeze, which was in late 2016, so it only has
2016.11. But that's how stable releases work; major new versions of
software does not typically get added to a stable release.


> Where can I report that?

In Debian, it's often good to report a bug through the Debian Bug
Tracking System:

  https://www.debian.org/Bugs/Reporting


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Using a custom device tree file

[Vagrant Cascadian]

On 2018-02-17, Rainer Dorsch wrote:
> Am Sonntag, 11. Februar 2018, 22:24:51 CET schrieb Rainer Dorsch:
>> Am Sonntag, 11. Februar 2018, 13:20:07 CET schrieb Vagrant Cascadian:
>> > On 2018-02-11, Rainer Dorsch wrote:
>> > Try adding the following to /etc/flash-kernel/ubootenv.d/fdtfile:
>> >   setenv fdtfile imx6dl-hummingboard-spi.dtb
>> > 
>> > And running flash-kernel to regenerate the boot script.
>> 
>> Thanks for your quick answer Vagrant.
>> 
>> In case I try to boot a broken dtb (kernel does not boot), is there a way
>> back to the previous dtb?
>
> AFAIK there are two ways to tell the kernel where to find the device tree:
> -> append to the kernel binary
> -> the bootloader handles this during boot and makes it available for the 
> kernel
>
> Can anybody tell, which method u-boot in Debian implements (in particular for 
> the hummingboard)? 

In Debian, using Debian-supplied u-boot and a boot script generated by
flash-kernel, hummingboard/mx6cuboxi variants run a
bootscript... flash-kernel defines in /usr/share/flash-kernel/db/all.db:

  Machine: SolidRun HummingBoard DL/Solo
  Machine: SolidRun HummingBoard Solo/DualLite
  Kernel-Flavors: armmp
  DTB-Id: imx6dl-hummingboard.dtb
  Boot-Script-Path: /boot/boot.scr
  U-Boot-Script-Name: bootscr.uboot-generic
  Required-Packages: u-boot-tools

  Machine: SolidRun HummingBoard Dual/Quad
  Kernel-Flavors: armmp
  DTB-Id: imx6q-hummingboard.dtb
  Boot-Script-Path: /boot/boot.scr
  U-Boot-Script-Name: bootscr.uboot-generic
  Required-Packages: u-boot-tools


So, flash-kernel copies the .dtb file listed there to
/boot/dtbs/VERSION/ and symlinks /boot/dtb* to the .dtb in the versioned
directory, based on the machine name defined in /proc/device-tree/model.

All the above variants use the uboot-generic boot script, which can be
found and edited on an installed system in:

  /etc/flash-kernel/bootscript/

So you could edit the script to do whatever you want.


> Can anybody tell, if it is possible to configure from u-boot shell to loada 
> custom device treefile?

To manually change it for a one-off boot:

  # disable the built-in setting of fdtfile
  setenv findfdt
  # manually set fdtfile
  setenv fdtfile /path/to/your/custom.dtb

You could, of course, also manually load the kernel, initrd, fdt and use
bootz rather than trying to work around the defaults in the boot script.


> Is that somewhere documented? The latest documentation on flash-kernelI found 
> is from 2011...


I'm not sure what sort of documentation you're looking for.

You can learn about u-boot by looking in the source code for the README,
the doc/* files, and of course the source code itself.

Many modern boards are using distro_bootcmd, which is documented in
doc/README.distro, which has improved the consistancy of behavior of
boards.

There's the README for flash-kernel in
/usr/share/doc/flash-kernel/README*


> https://wiki.debian.org/FlashKernelRework

Some of the features documented there have been implemented, or don't
really apply to modern boards that make use of distro_bootcmd.

Now that I'm on a roll and this email is getting really long...

I do think we should consider replacing flash-kernel with something else
at this point. The tool has grown and evolved all sorts of features;
I've never used it to "flash a kernel". I've exclusively used it for
purposes other than it's original design (mostly just copying a .dtb and
generating a boot script that is essentially re-useable on most boards I
use it with).

Scalability is a bit questionable; it actually cats the entire contents
of all.db and reads it into a variable, and then does "echo $VARIABLE |
grep FOO" type things in order to get data out of it. With new sunxi
boards coming out what *feels* like twice each week, grepping through an
echo'ed variable starts to seem like a bad idea to me.

Of course, it also kind of works well enough for what it is... but
adding new features is, in my experience, an unpleasant task. And
occasionally those new features are really needed with modern changes.


I've used u-boot-menu on a handful of boards, although it also currently
has some limitations. For example, it doesn't support /boot on a
separate partition without manual configuration ... anyone remember the
lovely hack "ln -s . /boot/boot" ... well, yeah... using *that*
again. It also doesn't handle copying the .dtb into /boot, so I still
need flash-kernel for that.

And then there's the support for u-boot emulating EFI so you could use
grub-efi-*, which has made great progress in recent u-boot versions. But
then we could use grub on more platforms ... that would be a nice goal
for buster, at least.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Using a custom device tree file

[Vagrant Cascadian]

On 2018-02-11, Rainer Dorsch wrote:
> I try to use a custom device tree file, but uEnv.txt does not have any effect:
>
> rd@mohot:~$ cat /boot/uEnv.txt 
> fdtfile=imx6dl-hummingboard-spi.dtb
...
> Do I need to run flash-kernel or something else that uEnv.txt has any effect?

I don't believe the u-boot in Debian or mainline supports uEnv.txt for
the hummingboard variants. Or any of the variants supported in Debian's
u-boot package, though I haven't looked closely.

Try adding the following to /etc/flash-kernel/ubootenv.d/fdtfile:

  setenv fdtfile imx6dl-hummingboard-spi.dtb

And running flash-kernel to regenerate the boot script.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Utilite Pro - U-Boot

[Vagrant Cascadian]

On 2018-02-11, Scott wrote:
> On 2/1/2018 1:13 AM, Vagrant Cascadian wrote:
> Curious if I am overlooking a U-Boot option/parameter/command for 
> loading initrd.
>
>  From the vendor-provided U-Boot prompt, I could not load initrd.gz into 
> memory without first wrapping with mkimage.  After debian installation, 
> I found the same case when configuring U-Boot to use bootcmd.  I ended 
> up wrapping initrd.img-4.9.0-4-armmp.  I suspect his will be a problem 
> when updating kernel.  Aptitude already shows a security update 
> available for kernel/image.

Yes, if u-boot was not compiled with CONFIG_SUPPORT_RAW_INITRD, it will
likely require wrapping with mkimage. Many vendor-supplied u-boot images
do not have this feature enabled.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Utilite Pro

[Vagrant Cascadian]

On 2018-01-31, Scott wrote:
> but would like to user installer via SD-card-image
>
> http://ftp.nl.debian.org/debian/dists/stretch/main/installer-armhf/current/images/hd-media/SD-card-images/
...
> Are the Stretch u-boot images based off v2017.05 
> 
> https://anonscm.debian.org/cgit/collab-maint/u-boot.git/

Stretch is based off of u-boot 2016.11, the upstream version available
at the time stretch froze.

I don't see any mention of utilite models in upstream u-boot, so it's
not possible to provide pre-built bootable debian-installer images.

If you have a vendor-provided u-boot, you might be able to get it to
work with the debian-installer images, possibly manually loading the
kernel+initrd+dtb from the u-boot prompt and booting. You'll likely need
a serial console connected to troubleshoot.

Good luck!


live well,
  vagrant

Re: flash-kernel and dtbs

[Vagrant Cascadian]

On 2017-11-30, Rainer Dorsch wrote:
> many thanks for you excellent suggestions, they helped me a lot.

Glad it worked!


> Am Dienstag, 28. November 2017, 13:12:42 schrieb Vagrant Cascadian:
> [...]
>> 
>> When the user installs them.  Install u-boot-imx and see
>> /usr/share/doc/u-boot-imx/README.Debian* for instructions on how to
>> install u-boot manually.
>
> That worked, but I had to install it to /dev/mmcblk1 (not mmcblk0)

Of course, the device numbering that linux detects may vary from one
boot to the next...


> The dtb has 4 spi entries
>
> ecspi@02008000 {
> #address-cells = <0x0001>;
...
> status = "disabled";
> };

> Is that sufficient for enabling the spi interfaces on the 26 pin interface?
>
> I do not see a /dev/spidev* even after loading spi_imx, which also does not 
> produce any entry in syslog. Do you have any clue why the the spi devices do 
> not show up?

The 'status = "disabled"' entries in your device-tree suggest it is not
yet supported on that hardware with the kernel version you're running.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: flash-kernel and dtbs

[Vagrant Cascadian]

On 2017-11-28, Rainer Dorsch wrote:
> Am Sonntag, 26. November 2017, 16:25:59 schrieb Vagrant Cascadian:
>> On 2017-11-26, Rainer Dorsch wrote:
>> > On Sonntag, 26. November 2017 11:30:04 CET Vagrant Cascadian wrote:
>> >> On 2017-11-26, Rainer Dorsch wrote:

>> >> Can you get to the u-boot console
>> >>
>> >> (probably serial console), and run the following commands:
>> >>   ver
>> >>   run findfdt
>> >>   printenv fdtfile
>> >
>> > Yes, that should work, but I need to do that later this week.
>>
>> Well, that's where the next troubleshooting steps would be...
>
> u-boot seems to be definitely outdated.
>
> Here is what I get here, findfdt is undefined. IIRC on the SDcard was 
> initially
> Debian jessie which I upgraded to stretch.
>
> CuBox-i U-Boot > ver
>
> U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43)
> gcc (Debian 4.9.2-10) 4.9.2
> GNU ld (GNU Binutils for Debian) 2.25
> CuBox-i U-Boot > run findfdt
> ## Error: "findfdt" not defined
> CuBox-i U-Boot > printenv fdtfile
> ## Error: "fdtfile" not defined

This is the u-boot version from jessie, and didn't support the
hummingboard variants, based both on my memory and now your reported
experience...


>> > The missing u-boot points also in this direction, I installed u-boot-imx
>> > now, but that did not change anything...
>>
>> The packages just ship pre-built binaries, they do not actually install
>> anything.
>
> hmm...when do they get installed?

When the user installs them.  Install u-boot-imx and see
/usr/share/doc/u-boot-imx/README.Debian* for instructions on how to
install u-boot manually.

If you have no memory of installing it explicitly, it was probably
included as part using an old debian-installer image, such as the
netboot SD card images:

  
https://deb.debian.org/debian/dists/jessie/main/installer-armhf/current/images/netboot/SD-card-images/


For a newer installer image:

  
https://deb.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/
  


live well,
  vagrant


signature.asc
Description: PGP signature

Re: flash-kernel and dtbs

[Vagrant Cascadian]

On 2017-11-26, Rainer Dorsch wrote:
> On Sonntag, 26. November 2017 11:30:04 CET Vagrant Cascadian wrote:
>> On 2017-11-26, Rainer Dorsch wrote:
>> > I try to setup the correct dtb for a HummingBoard DualLite using
>> > flash-kernel,
>> > but the kernel seems to load always the Cubox-i dtb:
>> What u-boot do you have installed? 
>
> It seems there is no u-boot installed at all

The version of u-boot you're running is probably whatever version was
used to set up the initial system or installation image...


>> Can you get to the u-boot console
>> (probably serial console), and run the following commands:
>> 
>>   ver
>>   run findfdt
>>   printenv fdtfile
>
> Yes, that should work, but I need to do that later this week.

Well, that's where the next troubleshooting steps would be...


> The missing u-boot points also in this direction, I installed u-boot-imx now, 
> but that did not change anything...

The packages just ship pre-built binaries, they do not actually install
anything.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: flash-kernel and dtbs

[Vagrant Cascadian]

On 2017-11-26, Rainer Dorsch wrote:
> I try to setup the correct dtb for a HummingBoard DualLite using 
> flash-kernel, 
> but the kernel seems to load always the Cubox-i dtb:

What u-boot do you have installed? Can you get to the u-boot console
(probably serial console), and run the following commands:

  ver
  run findfdt
  printenv fdtfile


> root@mohot:~# cat /etc/flash-kernel/machine 
> SolidRun HummingBoard DL/Solo
> root@mohot:~# fdtdump /boot/dtb-4.13.0-0.bpo.1-armmp |grep model
> model = "SolidRun HummingBoard Solo/DualLite";
> model = "On-board Codec";
> model = "On-board SPDIF";
> root@mohot:~# uname -a
> Linux mohot 4.13.0-0.bpo.1-armmp #1 SMP Debian 4.13.4-2~bpo9+1 (2017-10-17) 
> armv7l GNU/Linux
> root@mohot:~#  ls -l /boot/dtb-4.13.0-0.bpo.1-armmp 
> lrwxrwxrwx 1 root root 49 Nov 26 15:16 /boot/dtb-4.13.0-0.bpo.1-armmp -> dtbs/
> 4.13.0-0.bpo.1-armmp/imx6dl-hummingboard.dtb

What is the output of "ls /boot/dtbs/*/*.dtb" ?


> Looks all good for me so far, but another dtb is loaded:
>
> rd@mohot:~$ grep fdt /var/log/kern.log
> Nov 19 16:45:14 mohot kernel: [0.00] OF: fdt: Machine model: SolidRun 
> Cubox-i Dual/Quad

What is the output of "cat /proc/device-tree/model" ?


> Can anybody tell, what I am doing wrong? Is that a flash-kernel bug?

I doubt it's flash-kernel; more likely you have the wrong u-boot build,
or wrong environment variables saved in u-boot.


live well,
  vagrant


signature.asc
Description: PGP signature