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.

ToxicExMachina wrote:

If you want affordable computer with blobless firmware - go buy Thinkpad T60 and flash libreboot.

The hard drive controller in that machine contains embedded firmware which is powerful enough to pwn the device.

alupoj wrote:

ToxicExMachina wrote:

BIOS is opensource: https://www.seabios.org/
UEFI is also opensource: https://www.tianocore.org/

SeaBIOS originally looks like a BIOS for virtual machine guests.

Can SeaBIOS be used directly on any physical motherboard without Coreboot hack which I already mentioned?
Is not SeaBIOS just one of many other possible payloads like GRUB or KEXEC, etc. for Coreboot/Libreboot?

Where would be SeaBIOS without Coreboot/Libreboot projects which actually are apposite of what was intended for "openness" (actually lack of openness) of X86 boot loader?

It doesn't matter. Every vendor had own BIOS implementation because it totally depends on hardware by design. BIOS is a part of MS-DOS designed to provide abstraction layer for compatibility purposes. SeaBIOS is another implementation. In this case Coreboot+SeaBIOS == BIOS.

Enough of the loony tunes, This is a board forum about the Devuan operating system, not x86 god mode. Go away

x86 has own firmware standard. Initially it was BIOS. Now it's UEFI instead of BIOS. There are mostly same hotkeys, 99% same boot mechanism for motherboards from totally different vendors. At the same time every ARM board (even development boards) has own uboot fork, own bugs, own BSP kit incompatible with others, etc. There are enough powerful ARM workstations even today - see ThunderX based computers. The result is still same: proprietary platform. The only advantage is a lot of devices with ultra low power consumption. That's all ARM has. Some terrible things came to x86 from ARM. For example, AMD PSP is just an ARM TrustZone implementation.

BIOS is opensource: https://www.seabios.org/
UEFI is also opensource: https://www.tianocore.org/