[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help with testing u-boot!

On 12/29/22 05:06, Vagrant Cascadian wrote:

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
You too. I did find out the dfu problem is the robin nano boards, I cloned the gitub version 0.11, built and installed it on the bpi5 only to get the exact same failure message, finding in an old old klipper config that dfu didn't work on robin nano boards but they also have a recipe to upload to a nano. But that build is for the wrong mcu.
but the klipper board files are even older than Marlins so I'm still screwed. 

Thanks Vagrant.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>
Reply to: