I am installing armhf on my BeagleBone Black.

I read that armel and armhf both work but that Debian plans to obsolete armel eventually.

I tried the arm-sdk but soon realized I was in over my head, as the config file is not fully filled out.

Additional dependencies were installed besides the ones mentioned here:
https://git.devuan.dev/devuan-sdk/arm-sdk
% sudo apt install quilt bison flex chrpath gawk texinfo libsdl1.2-dev whiptail diffstat cpio libssl-dev zsh

% load devuan beagleboneblack 
Disabling additional executable binary formats: binfmt-support.
Enabling additional executable binary formats: binfmt-support.
[E] no valid distro specified
[E] error in: load devuan beagleboneblack
[W] called in: arm-sdk loaded

So...
https://pkgmaster.devuan.org/devuan/dists/chimaera/main/installer-armhf/current/images/

I am working from this directory. First stumbling block is the sheer amount of files, and there is no README. I'm not sure what files I need, what the purpose of each file is.. It's akin to having all the ingredients, but not the recipe.

Maybe this only reflects that what is needed right now is skilled devs, more than anything, before it can be made accessible to others. Any documentation out there?

Related threads:
https://dev1galaxy.org/viewtopic.php?id=1158
https://dev1galaxy.org/viewtopic.php?id=2043

Here's how u-boot is built for the devuan image: https://git.devuan.org/sdk/arm-sdk/blob … ack.sh#L63
I have two here, did not try them yet, but that's on my todo list, so if you need halp I can spend some time on it
but basically you should make an SD card with two partitions, one fat32 of a few Mo, with 5 files :
MLO : a reduced version of u-boot, which fits in the CPU instruction cache (128k), and which MUST have the name MLO
u-boot.img : full version of u-boot
uEnv.txt : environnement for the full version of u-boot
zImage : linux kernel
am335x-boneblack.dtb : device tree for the linux kernel
the names of the last four files depends on the configuration you have in the MLO, u-boot and uEnv.txt
You can find the files in this archive : http://www.nathael.org/Data/Devel/BBB/r … 4.1.tar.xz
in the same directory you also have base images for the rootfs to be extracted on the second partition of the SD card
and the patched sources for both u-boot and linux kernel
IF you rather want to do it on your own, then you can follow instructions from here : http://www.nathael.org/wiki_cpe/index.php/Dev/BBB
these are in french, but I think that a google translate whould do the job ... though there is very little text to translate.
the difference between the cross-compilation toolchains gcc-arm-none-eabi, gcc-arm-linux-gnueabi and gcc-arm-linux-gnueabihf are :
none vs linux : none targets micro-controllers and thus includes no libc, while linux targets linux systems, whith a libc
gnu : targets GNU libc
eabi vs eabihf : eabi is for ARM processors without a FPU (debian armel architecture), while eabihf targets those with a FPU (hardfloat) (debian armhf architecture)
you can also have gcc-arm-linux-uclib
which uses the uClibc instead of the GNU libc
the name is in the form "gcc-architecture-OS-libc"
whith some addition of the ABI used for ARM and MIPS toolchains where there can be many of them (mips is much worse than ARM for the ABI part)
apt-cache search gcc mips ...
boot.scr is not like a grub "stage 2"
it's an u-boot script
it is converted from boot.cmd using this command : mkimage -C none -A arm -T script -d boot.cmd boot.scr
which only adds a header to the boot.cmd file for u-boot
it has the same role as the uEnv.txt file for the beaglebone, and the name is specified in the u-boot configuration when u-boot is compiled
the support for text files with or without the header is also an u-boot configuration option
and you can create a system which needs no such configuration file, as u-boot can embed a default config, so once you know what you want, you can put it in the default u-boot config and get rid of the text file
same for the second u-boot on both beaglebone and allwinner boards
the first one (MLO for beaglebone or spl.bin for allwinner) is a simplified u-boot which can run in the processor instruction cache and data cache, which thus needs to be small enough, and which job is to init the DDR and start a second u-boot which in turns loads the linux kernel
the need for two u-boot is only beacause a full-featured u-boot does not fit in the instruction cache
needs to be less than 32k or something like that, right?
but once you know what you need, you can keep only the required parts in the first u-boot and tell it to load you kernel instead of the second u-boot
the size depends on the processor
under 128k for the AM335x of the beaglebone
I did not check for the Allwinner H2+ of the OrangePi zero
hum, the spl is indeed very small (18k) so the limit may be lower for the Allwinner H2+
i do remember getting that impression from elsewhere before
yep, from the H2+ documentation, 32k L1 instruction cache
this is very processor specific
it might be harder to get enough in the first stage u-boot (spl) to run the Linux kernel

Q: please let me know, where can I find BROM description?
does it always try to boot from SD at first?
A: the details of bootrom behaviour can be found in the AM335x Technical Reference Manual, but the short answer is: on the BBB by default bootrom checks { eMMC, μSD, uart0 (xmodem), usb0 (rndis } in that order

Q: how can I boot from SD if something bootable is present on the eMMC?
A: if you power on with the S2 button (aka the boot mode button) held down then the boot order (for bootrom) becomes { SPI flash, μSD, usb0 (rndis), uart0 (xmodem) }
you can (and should) let go of the S2 button once the power led turns on (or to be technical, 20 milliseconds after the power led turns on)
there is no SPI flash on beaglebones (except the BeagleBone Enhanced if I remember correctly) but you're free to connect one if you have some reason for it
note that this only determines where bootrom looks for u-boot (or rather, the MLO which contains the u-boot SPL), u-boot typically makes its own decisions with regard to where to load linux from

Q: thanks for letting me know
SPI flash is an additional storage option? it is connected to some pins?
A: angstrom has not been the default for many, many years.  this was before I started using beaglebones so I don't know anything about it

Q: are uboot and kernel bound to each another somehow?
A: nope, in general they are not, however it is recommended to use the u-boot that came with whatever image you want to use
u-boot = x86 bios + grub...
in theory, but in practice there can still be trouble... for example, current debian images normally use u-boot overlays, but this isn't supported by old u-boot versions

Q:then what BROM is?
a very basic bios that you have no control other then 16/8 gpio..
does not BROM do hardware initialization like DDR?
A: nope

Q: is it reflashable?  is there a source for BBB BROM somewhere?
A: bootrom is hard-baked into the SoC basically just does very rudimentary setup of the processor and loads the next stage into the internal SRAM. it will not do any board-specific setup such as DDR memory

Q:how can I be sure there is no a trojan for TrustZone?
A: you can't, but trustzone is not really supported anyway (technically there's a secure monitor, but it is only used to handle a small number of Secure Monitor Calls used to write to special registers that are not directly writable by the OS)
there's no secure-world kernel on AM335x GP devices

Q: Cortex A8 is stated to have a TrusZone? Is TI version any different?
A: I feel like I literally just answered that

Q: it means BBB CPU does not meet Cortex A8 specs?
A: it's r2p1 Cortex-A8 with neon...
and I feel like you're asking questions about things you don't really understand yet yourself
thumb2 works unlike the r1p3's we used on the Beagle/xM
also, I think it's r3p2

Q: sorry, I even do not know what r2p1 is, are these revisions?
A:yep, definitely r3p2,
yes, cortex-a8 revisions
r3p2 is the last revision
anyway, the short summary is: even though the cortex-a8 core itself has trustzone support, it is not usable on GP versions of the AM335x, which is what's used on the BBB

Q: can you please point me to a public explanation of this interesting issue related to TrustZone being revision specific for a Cortex A8 CPU?
A: support@ti.com can help you.
except for a tiny bit of initialization after reset and a tiny SMC handler, everything on the BBB runs in public (aka "non-secure") world
has nothing to do with the cortex-a8
it's just how it's setup on the AM335x

Q: may be TZ is just not usable by end users but still usable by a trojan injected on the factory?
A: if you want to be able to trust hardware, you'll have to design your own processor and create it by soldering transistors together
have fun

Q: haha, very smart, I still can choose AllWinner
A: lol, I'd trust a TI SoC a lot more than an AllWinner one
lol, and your worried about TI's trojans'!!!  China already back-doored that one..
I'm not concerned about trustzone on the BBB... if somewhere were going on in secure world, that would be observable anyway

Q: there is known method for a root escalation in AllWinner, but for a client mode it does not matter
I would prefer something with backdoors but without already injected active trojans
A: also, it's hard to imagine what that trojan could do, given that it only has 1KB of ram that's private to secure world

Q: is not all RAM related to TZ not readable from outside?
A: there's reason to believe TI would put a trojan in their hardware... it would be easy to discover and cause terrible damage to their reputation

Q: unless they are forced to do so by NSA or by above regulations
"RAM related to TZ" is meaningless... trustzone doesn't specify anything about RAM
otherwise no way to a public market?
for all things trustzone: https://developer.arm.com/ip-products/s … /trustzone
you just seem really paranoid about a topic you know very little about
trustzone is irrelevant on the BBB
sounds good, though hardly believable
A:what you do or do not believe is not my problem
sure, thank you very much for your earlier suggestions

Q:does a lack of TZ depend on BBB release year or revision
besides, DEFCON was last week, nothing is "secure" today, till all the things pointed out is fixed.
A:but I'm pretty security-paranoid myself, have dug a fair bit into bootrom on the AM335x, have dumped and partially reverse-engineerd the secure part of bootrom on the DM814x (a direct ancestor of the AM335x) to see what it does
based on all that, my opinion is: there's no need to worry about bootrom
all 1Ghz Aam335x are the same die revision..
no, it applies to all AM335x SoCs, and I think all TI SoCs in general (except maybe the latest ones, I don't know much about those yet)

Q: it looks like a BBB much better in terms of security than X86?
A: X86 is horrible, though BBB isn't secure.. it wasn't designed for that.. it was designed for usablity..

Q: cannot DMA be isolated by software on X86?
A: it's only isolated if you dump a bucket of cement on it and throw it into the ocean..

A: Regarding OpenBSD, it's easier then that..  While testing efi boot, i noticed u-boto doesn't scrub memory, hence if you reboot, and halt.. EVERYTHING is still in DDR3

Q:grsec pax is known to protect from unknown errors in code
does not grsec 4.9 do it better than linux v5x?
A:anything worth a damn was already implemented by kees and pushed into mainline.

After reading corresponding script:
https://git.devuan.org/sdk/arm-sdk/blob … ack.sh#L63

I am still not sure, what is rebuilt from source in it except kernel? Uboot?
All userspace is debootstrapped in a precompiled binary form from corresponding Devuan repository?

How to rebuild the whole installation from source like Gentoo?
Preferably by cross compiling on a X86 host or at least via distcc helper.

Can you please include those options for a full rebuild from source into the SDK?

/dev/loop0p1 on /mnt/d1 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/loop0p2 on /mnt/d2 type ext4 (rw,relatime)

First one is a boot loader and second is root fs.

I was suggested uboot is flashed into beginning sectors of the media from which BBB boots from its BROM.

There are a lot of manuals with a lot of undesirable time waste information how to flash Beaglebone Black, e.g.:
https://beagleboard.org/getting-started

The first what I have read of course is:
https://files.devuan.org/devuan_jessie/ … README.txt

It is clear I have to dd image to SD, it is easy.

How can I replace uboot and kernel?

I do NOT see an uboot bin for the BBB:
https://devuan.4isp.it/devuan_ascii/embedded/u-boot/

May I build my own kernel in Gentoo in cross compiling mode and place it to BBB?

Will grsec minipli kernel work fine on this board with Devuan?

Does there exist an RT grsec kernel source? Can RT and grsec be mixed at all?
Can grsec+deblobbed+RT kernel be run on BBB? Is RT kernel less secure than non RT or it does not matter?

Can I use XFS as a root FS for the installation? Or is it too much memory hungry for a 512Mb board? and may be even not compatible with grsec?

Thank you for your help, it is very valuable.