HackENS/liminix-fork
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

think think

Browse source
This commit is contained in:
Daniel Barlow 2023-11-05 23:39:50 +00:00
parent 5c1f5fabe2
commit 6bbff2f5b3
1 changed files with 239 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

239
THOUGHTS.txt
View file

@ -2691,3 +2691,242 @@ to provide a commandline in that case, but maybe also no need to.
For tftpboot, am undecided. We could use the dtb rewriting thing
everywhere, in the interest of consistency.
Mon Oct 9 20:45:54 BST 2023
we bumped the kernel entry point to the 32MB mark, as
(1) when using jffs2 (big rootfs image) it was clobbering the dtb at
the end of the filesystem
(2) it should be 2MB aligned anyway and wasn't
However, this has given us the next problem:
OF: fdt: Reserved memory: failed to reserve memory for node 'secmon@43000000': base 0x00000000430B
OF: reserved mem: OVERLAP DETECTED!
phram-rootfs (0x0000000040400000--0x0000000053a31488) overlaps with ramoops@42ff0000 (0x000000004)
Zone ranges:
DMA [mem 0x0000000040000000-0x000000005fffffff]
DMA32 empty
Normal empty
Movable zone start for each node
the end of that phram-rootfs region looks well sus.
[ turns out that decimal is not hex ]
Tue Oct 10 21:37:31 BST 2023
UBI bleurgh ...
The DTB for this device, and/or the OpenWrt installer, seems to
expect already that mtd4 is a UBI thing
mtdinfo -a says:
mtd4
Name: ubi
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 1000 (131072000 bytes, 125.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:8
Bad blocks are allowed: true
Device is writable: true
<5>UBI: auto-attach mtd4
<5>ubi0: attaching mtd4
<5>ubi0: scanning is finished
<5>ubi0: attached mtd4 (name "ubi", size 125 MiB)
<5>ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
<5>ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
we made a volume using "ubimkvol /dev/ubi0 -N liminix -S 825"
and from ubinfo -a we can see
0 ubootenv
1 ubootenv2
2 recovery
3 boot_backup
4 liminix
Now we could use "ubiupdatevol /dev/ubi0_4 /path/to/ubifs.img"
to put a ubifs on that volume, but obviously we'd have to boot the
device into Liminix somehow first.
Alternatively in the build environment we could use ubinize to
create the entire image that can be flashed to MTD, but
- this will overwrite erase counters.
- we have to give it a config file that describes all the volumes,
and I'm guessing they need to match up with the existing ones
otherwise we trash the uboot env
Wed Oct 11 17:37:09 BST 2023
We can write ubi volumes from u-boot. Let's for the moment use
mkfs.ubifs and tftp those files to u-boot - we can figure out the
ubinize dance later
We need either
(a) to write an analogue of our jffs2 graft option for mkfs.ubifs, or
(b) to have a "cpio-like" mkfs.ubifs variant that reads filenames on stdin
and writes only those, or
(c) to create a "staging" directory during build with all the store folders that need to go into the filesystem
although the least elegant, option (c) is the simplest and probably
not even slow, at least by comparison with unpacking the kernel source
tarball
we used
uboot> tftpboot 0x40400000 result/rootfs
uboot> ubi write 40400000 liminix $filesize
then can use ubifsmount ubi0:liminix ; ubifsls / to check that it wrote
something valid. To boot this:
setenv serverip 10.0.0.1
setenv ipaddr 10.0.0.8
setenv bootargs 'liminix console=ttyS0,115200 panic=10 oops=panic init=/bin/init loglevel=8 root=ubi0:liminix rootfstype=ubifs fw_devlink=off'
tftpboot 0x4007ff28 result/uimage
bootm 0x4007ff28
The other thing we had to fix here is that activate wasn't being built
statically. Have to add -Xlinker -static to CFLAGS - I don't know if
this is a no-op on MIPS
Mon Oct 16 20:51:08 BST 2023
Here's a thing: the u-boot installed by openwrt on this device has a
ubifsload command, and it has a writable ubootenv. So instead of
having a separate partition for the kernel we could put the kernel in
the actual filesystem
I think we should do this by excluding flashimage and including some
other module (to be written) instead. ubimage or somesuch, perhaps.
So the image we wish to create is a ubifs with a kernel inside it in
/boot and we also need to change the u-boot env value of
boot_production=led $bootled_pwr on ; run ubi_read_production && bootm $loadaddr#$bootconf ; led $bootled_pwr off
so that it mounts the rootfs and finds /boot/uimage inside it
From uboot this is setenv and saveenv; from a running linux this is fw_setenv
Thu Oct 19 09:34:15 BST 2023
setenv bootargs 'liminix console=ttyS0,115200 panic=10 oops=panic init=/bin/init loglevel=8 root=ubi0:liminix rootfstype=ubifs fw_devlink=off'
ubifsmount ubi0:liminix
ubifsload 4007ff28 boot/uimage
bootm 0x4007ff28
Thu Oct 19 23:11:17 BST 2023
Assuming you've done the openwrt installer to repartion the device,
what are the steps to install Liminix?
1) build rootfs, which incorporates kernel
2) from u-boot:
uboot> ubimkvol /dev/ubi0 -N liminix -S 825
uboot> tftpboot 0x40400000 result/rootfs
uboot> ubi write 40400000 liminix $filesize
uboot> setenv boot_production 'led $bootled_pwr on ; ubifsmount ubi0:liminix; ubifsload 4007ff28 boot/uimage; bootm 4007ff28'
What if we don't have a serial console? can we do all this from openwrt?
Fri Oct 27 23:21:08 BST 2023
setenv serverip 10.0.0.1
setenv ipaddr 10.0.0.8
setenv bootargs 'liminix earlyprintk earlycon=uart8250,mmio32,0xf1012000 ramoops.mem_address=0x8000000 ramoops.mem_size=0x40000 ramoops=max_reason=2 mem=128M earlycon=ttyS0 console=ttyS0,115200 panic=10 oops=panic init=/bin/init loglevel=8 root=ubi0:liminix rootfstype=ubifs fw_devlink=off'
setenv bootargs 'liminix ramoops.mem_address=0x8000000 ramoops.mem_size=0x40000 ramoops=max_reason=2 mem=128M console=ttyS0,115200 panic=10 oops=panic init=/bin/init loglevel=8 root=ubi0:liminix rootfstype=ubifs fw_devlink=off'
tftpboot ${kernel_addr_r} result
bootm ${kernel_addr_r}
---
this is potentially worth checkng out because we do have very slow
decompress speed
https://scm.linefinity.com/common/u-boot/commit/5818198e6a184963c6afc82178b23a64435ace6a
Commit 5bb2c550b1 ("arm: mvebu: Move internal registers in
arch_very_early_init() function") implemented code movement according to
(now incomplete) comments which resulted in semi-broken code.
The result is that I-cache is currently disabled for all Armada 38x boards
and maybe there are some other (unreported / undetected) issues.
[...] After this change lzmadec command with lzma image of 0x7000000 bytes is
doing decompression just 5 seconds. Before this change it was 30 seconds.
Mon Oct 30 21:03:55 GMT 2023
We have a kernel that boots on the Omnia, now we need to build a
rootfs. Given this device uses mmc for its primary storage, we should
use a block filesystem not a flash filesystem.
setenv serverip 10.0.0.1
setenv ipaddr 10.0.0.8
setenv bootargs 'liminix console=ttyS0,115200 panic=10 oops=panic init=/bin/init loglevel=8 root=/dev/mtdblock0 rootfstype=ext4fs fw_devlink=off mtdparts=phram0:22M(rootfs) phram.phram=phram0,0x1300000,23068672,65536 root=/dev/mtdblock0'
tftpboot 0x1000000 tftpboot/uimage ; tftpboot 0x1300000 tftpboot/dtb ; tftpboot 0x29b0000 tftpboot/dtb; tftpboot 0x29c0000 initrd.img
Sat Nov 4 12:22:37 GMT 2023
setenv serverip 10.0.0.1
setenv ipaddr 10.0.0.8
setenv bootargs 'liminix console=ttyS0,115200 panic=10 oops=panic init=/bin/init loglevel=8 root=/dev/mtdblock0 rootfstype=ext4 fw_devlink=off mtdparts=phram0:22M(rootfs) phram.phram=phram0,0x40300000,23068672,65536 root=/dev/mtdblock0'
tftpboot 0x40000800 tftpboot/uimage ; tftpboot 0x419b0800 tftpboot/dtb ; tftpboot 0x41a00000 initrd.img ; tftpboot 0x40300000 tftpboot/rootfs
bootm 0x40000800 0x41a00000 0x419b0800
kernel 0x40000800 + 2af400 = "402afc00"
rootfs 0x40300000 + 15f9400 = "418f9400"
dtb 0x419b0800 + 4e00 = "419b5600"
Sun Nov 5 00:01:56 GMT 2023
Open questions
1) using -device loader for qemu phram, how do we choose appropriate
start address for all architectures? we could try to unify this
with the tftpboot approach, but that would mean providing the dtb
ourselves somehow which seems silly when qemu already does it
2) flash erase block size for tftpboot phram, it need to match the hardware
- we don't use it at all for squashfs
- for jffs2 it needs to match if tftpboot is to use same rootfs image
as flash
- we don't have any way to do a tftpboot ubifs
- ext4 doesn't care
3) the rootfstype needs thought.
- for all but squashfs it implies an initramfs
- jffs2 can be flashed naively
- ubifs needs an installer to not clobber erase counts
- ext4 (for omnia) needs a block device and can't be flashed along
with the kernel/initramfs because it's a separate disk. or maybe
the omnia can load kernel from mmc?
phram plus mtd_block is ok for ext4 for qemu, so that's one thing
fewer to deal with
4) for tftpboot with a separate initramfs, is there any way to
make address selection easier?
5) ubifs needs a different set of flash parameters (PEB, LEB etc)