jaeger changed the topic of #crux-arm to: CRUX-ARM 3.6 Released! - http://crux-arm.nu/Documentation/ReleaseNotes3-6 | Logs: https://libera.irclog.whitequark.org/crux-arm/
<jaeger> Another suggestion for crux-arm-release: maybe clean up /var/lib/pkg/rejected in the rootfs before creating the tarball
<pitillo> ummmm
<pitillo> interesting
<pitillo> that's a good one
<pitillo> can you create an issue?
<jaeger> sure
<jaeger> It's only resolv.conf, ld.so.cache, prt-get.conf, and pkgmk.conf for reference
<pitillo> ummm but it must be clean for a release
<jaeger> updated pkgutils in crux-ports-raspberrypi4-arm64 3.7
<pitillo> great, bit by bit
pitillo has quit [Ping timeout: 252 seconds]
pitill0 has quit [Ping timeout: 255 seconds]
pitillo has joined #crux-arm
pitill0 has joined #crux-arm
<pitillo> I'm dumb.... I have noticed after sorting/cleaning the entire development tower (all arm devices) that they weren't connected to UPS (wrong socket connected because they aren't labeled) xD
<jaeger> oops
<mnkydeth> I may have some time tonight. I would gladly run an intall or try it out on a Compute module 4 on the stock official IO board. I would be using an sdcard and nothing else most likely. I think I have a module with 32GB emmc on it I might be able to test as well. I would just need a point in the right direction on how to install rpi4 image onto the storage. If it's just an extraction like with piOS or if
<mnkydeth> I have to build it up from scratch like an official x86_64 install.
<jaeger> It should be pretty easy and I think the stuff I've already built would work. The CM4 is very similar to pi4, right?
<jaeger> same CPU
<mnkydeth> Yep, mostly the same. Just has access directly to the pcie lane. To my knowledge
<jaeger> Formatted the uSD card with 2 partitions, 1 fat32 and 1 ext4. The fat32 partition needs to have the LBA flag set.
<jaeger> Mounted the uSD to /mnt and /mnt/boot
<jaeger> Copied everything from the firmware master.zip "boot" directory into /mnt/boot, then uncompressed the rootfs and kernel archives into /mnt
<jaeger> The kernel archive overwrites some of the stuff that came from the firmware master.zip and that's fine
<mnkydeth> I'll prolly be able to try it out after dinner. Or when the kids go to bed.
<mnkydeth> Just out of curiosity .. Is there a universal install or is what you discribed ok for any PI device? If I can get it to work on a compute module 4. I do have a real RPI4, RPI Zero W and RPI Zero W 2. I am much more of a normal user then developer. And I think if I run into issues it may give some knowledge to what an average user might run into.
<jaeger> That should be pretty standard for pi installs, though this particular rootfs is optimized with CFLAGS for the pi4 and A72 CPU
<mnkydeth> ok
<jaeger> You'd want something else for the others, I think
<jaeger> Oh, you'd also want to set up cmdline.txt and config.txt in /mnt/boot, I can post examples of those later
<mnkydeth> That would be great. I always enjoy your example text files. Saves a ton of time.
<jaeger> cmdline.txt just contains:
<jaeger> console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait ro quiet
<jaeger> config.txt: http://ix.io/4igq
<jaeger> This config.txt is mostly from upstream, I only added the last 3 lines
<jaeger> The hdmi_group and hdmi_mode options are usually unnecessary, I just wanted to force 1080p for the display to which this rpi4 is connected
<jaeger> I've got to head out for a while but can lend a hand later if you need it
<pitillo> just a side note here mnkydeth: for other devices there are generic releases for arm32 and arm64, so they canbbe deployed to target devices in the same wsy (no install or image process yet, should'd be difficult the image one, but it's more work and we need to priorize atm)
<pitillo> starting with a test on the rpi4 image could be really good to check things and fix whatever you find, or improve it
<pitillo> time to rest here, have fun and a good night