Is it possible to make an image of a neutrino...?

[DM900]

Hmm, chroot comes from BA itself and also included at Busybox. At sh4 there was not really changes needed for BA. You should see with serial log what is wrong. The main problem with the old "BA method" (chroot) is, only one kernel for all images used. And a image update will not work (or destroy all images), because not a real single partition for one image is used. A mini-UBoot (2nd bootloader) would be a better way for a real multiboot, because a manual start from the original bootloader itself is no problem with real partitions. I have try'd something with a 2nd UBoot but I think my config is wrong.

I am talking about this it is new way of multiboot
https://www.opena.tv/viewtopic.php?t=68241&start=160

[zozman]

Sorry, but not really new, all based on the old SH4 BA (chroot) method. chroot changes only the root source, a kernel is loaded before root given via chroot. If enough space available, image count "unlimited". Also other source of root (usb/sd/flash etc.) no problem with chroot. But I don't like and don't use this method. If this works, OK, but I don't support this. A 2nd UBoot is imho a better way and safer. But nobody works on this.

[zozman]

challenges of mini-U-Boot :
​- Bypassing Secure Boot:
​- Hardware-Specific Porting
​- Critical Memory Management:
​- knowledge of boot processes and hardware datasheets.

[zozman]

I have tried something with a 2nd UBoot/Loader. Secure Boot and the other? Hmm, I think not really needed. They are all part of the main loader (UBoot/Loader). The 2nd loader needs only a menu (LCD, if no LCD then TV/HDMI) and should then load the kernel. The config which image is active stored in a very small extra partition or own partition as file. Manually I can boot the kernel from a 2nd loader (as clean ELF, not GZ). All hardware things knows the main loader and the 2nd loader use these infos. Same how the mini-UBoot at SH4. A 2nd loader as mini-UBoot is not a full loader, only a extension.


EDIT: Here a output of my Test U-Boot, but many functions still missing, other not needed. STRG-C at BOLT, then via manual start of the U-Boot:

Code: Alles auswählen

BOLT> boot -elf usbdisk0:u-boot
Loader:elf Filesys:fat Dev:usbdisk0 File:u-boot Options:(null)
Starting program at 0x10100000 (DTB @ 0x7728000)

32 bit boot...


U-Boot 2025.10-rc2-v1.00-00045-g0c558bbad9e7 (Aug 14 2025 - 20:50:01 +0200) - BPanther-2nd-stage-loader

Model: BCM97252SSFF
DRAM:  1 GiB (total 2 GiB)
Core:  18 devices, 10 uclasses, devicetree: board
MMC:   sdhci@f03e0100: 0, sdhci@f03e0300: 1
Loading Environment from nowhere... OK
In:    serial@f040a900
Out:   serial@f040a900
Err:   serial@f040a900
Net:   No ethernet found.
Working FDT set to 7728000
Working FDT set to 1f00000
Working FDT set to 1f00000

  *** U-Boot Boot Menu ***

      0. Exit


  Press UP/DOWN to move, ENTER to select, ESC to quit
BPanther-U-Boot>

And here the printenv:

Code: Alles auswählen

BPanther-U-Boot> printenv
baudrate=1000000
bootargs=set bootargs bmem=640M@384M bmem=384M@2048M console=ttyS0,1000000 root=/dev/mmcblk0p2 rootwait rootfstype=ext4 coherent_pool=2M
bootcmd=run bootargs; bootm 0x7728000
bootdelay=5
fdt_high=0xffffffff
fdtaddr=1f00000
fdtcontroladdr=7728000
fdtsaveaddr=0x1f00000
initrd_high=0xffffffff
loadaddr=0x02000000
preboot=fdt addr ${fdtcontroladdr};fdt move ${fdtcontroladdr} ${fdtsaveaddr};fdt addr ${fdtsaveaddr};
stderr=serial@f040a900
stdin=serial@f040a900
stdout=serial@f040a900

Environment size: 499/65532 bytes
BPanther-U-Boot>

The bdinfo:

Code: Alles auswählen

BPanther-U-Boot> bdinfo
boot_params = 0x00000000
DRAM bank   = 0x00000000
-> start    = 0x00000000
-> size     = 0x40000000
DRAM bank   = 0x00000001
-> start    = 0x80000000
-> size     = 0x40000000
flashstart  = 0x00000000
flashsize   = 0x00000000
flashoffset = 0x00000000
baudrate    = 1000000 bps
relocaddr   = 0x10100000
reloc off   = 0x00000000
Build       = 32-bit
current eth = unknown
eth-1addr   = (not set)
IP addr     = <NULL>
fdt_blob    = 0x3d744170
lmb_dump_all:
 memory.count = 0x2
 memory[0]      [0x0-0x3fffffff], 0x40000000 bytes, flags: none
 memory[1]      [0x80000000-0xbfffffff], 0x40000000 bytes, flags: none
 reserved.count = 0x3
 reserved[0]    [0x0-0xfff], 0x1000 bytes, flags: no-overwrite
 reserved[1]    [0x3c744150-0x3fffffff], 0x38bbeb0 bytes, flags: no-overwrite
 reserved[2]    [0x80000000-0xbfffffff], 0x40000000 bytes, flags: no-overwrite
devicetree  = board
serial addr = 0xf040a900
 width      = 0x00000004
 shift      = 0x00000002
 offset     = 0x00000000
 clock      = 0x04d3f640
arch_number = 0x00000000
TLB addr    = 0x3fff0000
irq_sp      = 0x3d744160
sp start    = 0x3d744150
Early malloc usage: 354 / 400
BPanther-U-Boot>

And the help:

Code: Alles auswählen

BPanther-U-Boot> help
?         - alias for 'help'
askenv    - get environment variables from stdin
base      - print or set address offset
bdinfo    - print Board Info structure
blkcache  - block cache diagnostics and control
boot      - boot default, i.e., run 'bootcmd'
bootd     - boot default, i.e., run 'bootcmd'
bootdev   - Boot devices
bootelf   - Boot from an ELF image in memory
bootflow  - Boot flows
bootm     - boot application image from memory
bootmenu  - ANSI terminal bootmenu
bootmeth  - Boot methods
bootp     - boot image via network using BOOTP/TFTP protocol
bootstd   - Standard-boot operation
bootvx    - Boot vxWorks from an ELF image
bootz     - boot Linux zImage image from memory
cat       - Print file to standard output
cls       - clear screen
cmp       - memory compare
coninfo   - print console devices and information
cp        - memory copy
crc32     - checksum calculation
dcache    - enable or disable data cache
dm        - Driver model low level access
echo      - echo args to console
editenv   - edit environment variable
env       - environment handling commands
exit      - exit script
ext2load  - load binary file from a Ext2 filesystem
ext2ls    - list files in a directory (default /)
ext4load  - load binary file from a Ext4 filesystem
ext4ls    - list files in a directory (default /)
ext4size  - determine a file's size
ext4write - create a file in the root directory
false     - do nothing, unsuccessfully
fatinfo   - print information about filesystem
fatload   - load binary file from a dos filesystem
fatls     - list files in a directory (default /)
fatmkdir  - create a directory
fatrm     - delete a file
fatsize   - determine a file's size
fatwrite  - write file into a dos filesystem
fdt       - flattened device tree utility commands
fstype    - Look up a filesystem type
fstypes   - List supported filesystem types
go        - start application at address 'addr'
gzwrite   - unzip and write memory to block device
help      - print command description/usage
icache    - enable or disable instruction cache
iminfo    - print header information for application image
imxtract  - extract a part of a multi-image
itest     - return true/false on integer compare
lcdputs   - print string on video framebuffer
ln        - Create a symbolic link
load      - load binary file from a filesystem
loadb     - load binary file over serial line (kermit mode)
loadm     - load binary blob from source address to destination address
loads     - load S-Record file over serial line
loadx     - load binary file over serial line (xmodem mode)
loady     - load binary file over serial line (ymodem mode)
loop      - infinite loop on address range
ls        - list files in a directory (default /)
lsblk     - list block drivers and devices
lzmadec   - lzma uncompress a memory region
md        - memory display
meminfo   - display memory information
mkdir     - create a directory
mm        - memory modify (auto-incrementing address)
mmc       - MMC sub system
mmcinfo   - display MMC info
mv        - rename/move a file/directory
mw        - memory write (fill)
net       - NET sub-system
nm        - memory modify (constant address)
panic     - Panic with optional message
printenv  - print environment variables
random    - fill memory with random pattern
read      - Load binary data from a partition
reset     - Perform RESET of the CPU
rm        - delete a file
run       - run commands in an environment variable
save      - save file to a filesystem
setcurs   - set cursor position within screen
setenv    - set environment variables
setexpr   - set environment variable as the result of eval expression
sf        - SPI flash sub-system
showvar   - print local hushshell variables
size      - determine a file's size
sleep     - delay execution for some time
source    - run script from memory
sspi      - SPI utility command
test      - minimal test like /bin/sh
tftpboot  - load file via network using TFTP protocol
true      - do nothing, successfully
unlz4     - lz4 uncompress a memory region
unzip     - unzip a memory region
usb       - USB sub-system
usbboot   - boot from USB device
version   - print monitor, compiler and linker version
write     - Store binary data to a partition
xxd       - Print file as hexdump to standard output
zip       - zip a memory region
BPanther-U-Boot>

[zozman]

:


1. Does the main bootloader allow loading any unsigned ELF from USB/MMC, or only this U-Boot ELF?


2. Have you tried booting a kernel ELF directly from the main loader (skipping the 2nd loader)?

3. Why does bootcmd point to the DTB address instead of a kernel image?
4. Have you tried fatload/ext4load a zImage + initramfs, then bootz?

5. Have you tested a minimal initramfs to load a rootfs from another partition/image?
6. Once a kernel is running from the 2nd loader, can you use kexec to switch kernels without full reboot?

7. Where will the active-image config be stored — small FAT file, or dedicated partition?
8. Will you add an HDMI/LCD boot menu that reads the image list from a config file?
9. Is Ethernet/TFTP support planned, or will you stick to USB/MMC only?

10. Since unzip/lzma commands exist, have you tried compressed kernels to save space?
11. Does the main loader block replacing stored kernels, or is it allowed but risky?

[zozman]

The main loader BOLT is nearly the same as other receivers. Means, no sig files needed for image starting. My images and also other have no sig. A sig is only for the NOR flash needed, not for the MMC. You can boot directly with BOLD any image at any source you want. Theoretically, if flash0.nvram (at NOR!) is writable, you can do the same as VU4K/HD51 etc. for redirecting to "Startup" - but it is not writable. May here a sig needed. I have also try'd a emmcflash0.nvram at MMC, but will be ignored by BOLT. Or with other words: You can create at MMC 6 additional parts for 4 images (4x kernel, 4x root) and start them manually from BOLT how VU4K/HD51.


And for your questions:

1. Does the main bootloader allow loading any unsigned ELF from USB/MMC, or only this U-Boot ELF?
2. Have you tried booting a kernel ELF directly from the main loader (skipping the 2nd loader)?

See above, yes.

3. Why does bootcmd point to the DTB address instead of a kernel image?

As I say'd, the test UBoot is not fully functional and the config is not really right. There no real menu or whatever, it's just a short test.

4. Have you tried fatload/ext4load a zImage + initramfs, then bootz?
5. Have you tested a minimal initramfs to load a rootfs from another partition/image?
6. Once a kernel is running from the 2nd loader, can you use kexec to switch kernels without full reboot?
10. Since unzip/lzma commands exist, have you tried compressed kernels to save space?

I don''t use kexec/initramfs or slow lzma, so not testet. There is enough space available without slow compressing. You can also use UPX to compress root - but also slow. If your image needs compression, then you should think about the image size and the content.

7. Where will the active-image config be stored — small FAT file, or dedicated partition?
8. Will you add an HDMI/LCD boot menu that reads the image list from a config file?
9. Is Ethernet/TFTP support planned, or will you stick to USB/MMC only?
11. Does the main loader block replacing stored kernels, or is it allowed but risky?

As I say'd, the test UBoot is only a short test, not really functionally. ETH/TFT may work, but not testet. But this is what I mean. Other may can do this better than me.
The source I've try'd was from here: https://github.com/u-boot/u-boot/

[zozman]

Main Hurdles :

Memory Maps: Understanding the exact memory layout of the DM900 to avoid conflicts.and correctly locate the kernel for loading.
File Systems: The ability to read boot files from various file systems, like ext4 or FAT.
Device Identification: Properly identifying essential hardware lik
Bootloader Compatibility: Ensuring the mini U-Boot works without interfering with the main BOLT bootloader.

[zozman]

All these are problems for a full u-boot, yes. I don't know how to build a mini u-boot, so the tests are with a full u-boot. This can currently, you can it see, read from fat, ext2, ext4 and so on. But it has a few problems, possibly a config problem...
I personally don't need the 2nd u-boot, because I simply switch the image via serial connection from BOLT directly if needed.