lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
Tenkawa has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<Armbian-Discord> <T​onymac32> Sigh I'm tired of hearing about tow-boot
<Armbian-Discord> <T​onymac32> I run RK3399 off of NVMe on 2 devices currently. One boots an eMMC U-boot and the other a SPI
<Armbian-Discord> <T​onymac32> Then immediately hands off to NVMe.
<Armbian-Discord> <T​enkawa> @Tonymac32 do you have your spi setup/reference handy to boot from nvme so I can ditch tow-boot?
Tenkawa has joined #armbian-rockchip
Tenkawa has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<Armbian-Discord> <T​onymac32> I literally just nand-sata-installed it to my Roc-RK3399-PC
<Armbian-Discord> <T​onymac32> I can test if that is still a viable method or not
<Armbian-Discord> <T​onymac32> maybe my rockpro64 will cooperate with me for the first time ever
<Armbian-Discord> <l​anefu> but tow-boot has a cool menu, right?
<Armbian-Discord> <T​onymac32> le sigh
<Armbian-Discord> <T​onymac32> wtf is nix and why are they using it to build stuff
<Armbian-Discord> <I​gorPec> nix is next cool thing 😉
<Armbian-Discord> <T​onymac32> bullshit
<Armbian-Discord> <T​onymac32> 😄
<Armbian-Discord> <c​0rnelius> isn't it mostly just a package manager?
<Armbian-Discord> <c​0rnelius> Nix is a tool that takes a unique approach to package management and system configuration.
<Armbian-Discord> <c​0rnelius> says google
<Armbian-Discord> <T​onymac32> *shrugs I have no idea what it does exactly, I thought it was a package manager tool
<Armbian-Discord> <c​0rnelius> there is also NixOS but I've never used either.
<Armbian-Discord> <l​anefu> Nix turns everything in and out
<Armbian-Discord> <l​anefu> its package adn configuration mangement
<Armbian-Discord> <l​anefu> 1 config file defines whole system
<Armbian-Discord> <T​onymac32> uh-huh
<Armbian-Discord> <T​onymac32> until it doesn't
<Armbian-Discord> <l​anefu> well it means your system is too large / complicated
<Armbian-Discord> <T​onymac32> "If the tool doesn't work in your use case, your use case is wrong"
<Armbian-Discord> <l​anefu> I CAN see the appeal for building appliances
<Armbian-Discord> <T​onymac32> in the land of 10 billion tools, lets add the 10 billion and 1nth
<Armbian-Discord> <l​anefu> i mean thats true.. wrong hammer
<Armbian-Discord> <T​onymac32> well, sometimes you have stupid tools, too
<Armbian-Discord> <T​onymac32> like VW with their triple-square bolts
<Armbian-Discord> <T​onymac32> in any case, this project looks cool, but why learn an entire new tool to just compile an "opinionated" u-boot?
<Armbian-Discord> <T​onymac32> btw what does u-boot have opinions about in this case?
<Armbian-Discord> <T​onymac32> 😄
<Armbian-Discord> <l​anefu> wait WTF.. how does towboot play into NIX
<Armbian-Discord> <l​anefu> oh lord
<Armbian-Discord> <l​anefu> thats how he builds it
<Armbian-Discord> <T​onymac32> someone finally caught up
<Armbian-Discord> <T​onymac32> 😉
<Armbian-Discord> <T​onymac32> so evil U-boot == tow-boot
<Armbian-Discord> <T​onymac32> rofl
<Armbian-Discord> <c​0rnelius> whats the menu for? does it let u boot from diff drives or something?
<Armbian-Discord> <T​onymac32> it's what you can 90% do in u-boot already
<Armbian-Discord> <T​onymac32> so I think yes
<Armbian-Discord> <l​anefu> yeah makes it easy to boot fom stuffs
<Armbian-Discord> <l​anefu> i mean in native uboot has a menu feature
<Armbian-Discord> <c​0rnelius> so its like Petitboot?
<Armbian-Discord> <T​onymac32> they also appear to have an embedded linux for a few device like the Libre Computer LOST system
<Armbian-Discord> <l​anefu> no petit boot does kexec bullshit
<Armbian-Discord> <l​anefu> its actually linux
<Armbian-Discord> <l​anefu> this is at least staying in uboot
<Armbian-Discord> <c​0rnelius> ah gotcha
<Armbian-Discord> <l​anefu> this conversation is too interesting looking away now
<Armbian-Discord> <T​onymac32> pssht
<Armbian-Discord> <T​onymac32> anyway, like I said it's a neat project, but the build tools and the "We invented something" attitude at least conveyed by the users is... annoying
<Armbian-Discord> <c​0rnelius> they be real proud of them selves. must be millennials.
<Armbian-Discord> <T​onymac32> lol
<Armbian-Discord> <T​onymac32> like I said, it's neat, but I can't see adding another toolset to my list just to gain access to something I can just plain do in u-boot
<Armbian-Discord> <c​0rnelius> I'm with you. I know I wouldn't.
<Armbian-Discord> <M​anoftheSea> what is tow-boot, anyway?
<Armbian-Discord> <M​anoftheSea> You know what makes more sense to me? If u-boot followed the bootloader standard that Pottering wrote systemd-boot (gummiboot) to use, or if u-boot just launched systemd-boot. Having provided that third opinion out of left field, I'll disappear.
<Armbian-Discord> <M​anoftheSea> https://systemd.io/BOOT_LOADER_SPECIFICATION/ Type 2 allows single-file images that embed all metadata in the kernel binary itself, which is useful to cryptographically sign them as one file for the purpose of SecureBoot (“Type #2”). LOOK, it's a FIT (Flattened Image Tree) by another standard.
<Armbian-Discord> <M​anoftheSea> The first type is text based, very simple, and suitable for a variety of firmware, architecture and image types Basically, a config file goes in $ESP/loader/*.conf which points at files within the ESP for loading kernel, initrd, dtb, commandline. Those files are separated by directory, allowing multi-booting not to conflict with each other.
<Armbian-Discord> <M​anoftheSea> There's even a devicetree-overlay option within the type 1 definitions
<Armbian-Discord> <M​anoftheSea> For “EFI Unified Kernel Images” (Type #2), the vendor or kernel package installer should create the combined image and drop it into $BOOT/EFI/Linux/. Seems the same could be done for FIT files.
<Armbian-Discord> <M​anoftheSea> hmm. But I suppose u-boot doesn't have to rely on an ESP, anyway. As long as it can find ANY boot-marked partition... and u-boot has extlinux menu parsing and presentation.
<Armbian-Discord> <M​anoftheSea> extlinux doesn't appear to do drop-in files in a directory, though.
<Armbian-Discord> <c​0rnelius> could use grub
<Armbian-Discord> <c​0rnelius> but then you gotta deal with that nightmare
<Armbian-Discord> <M​anoftheSea> Does grub bring any advantage?
<Armbian-Discord> <T​onymac32> U-boot can boot a microcontroller
<Armbian-Discord> <T​onymac32> That's kind of the thing about it that makes it a bit rough to tune
<Armbian-Discord> <T​onymac32> All the EFI stuff just brings up grub anyway
<Armbian-Discord> <T​onymac32> But yeah, U-boot specific scripting, extlinux, EFI, pick your poison
<Armbian-Discord> <M​anoftheSea> https://elinux.org/images/9/90/Barebox-elce2013-bootloaderspec.pdf Oh, maybe it's not all Pottering
<Armbian-Discord> <M​anoftheSea> Ahah, slide 17 says gummiboot was Kay Sievers and Harald Hoyer. Which would later become systemd-boot. Neat.
<Armbian-Discord> <M​anoftheSea> And that slide also says grub2 can read bootloader specification (bls) entries.
<Armbian-Discord> <M​anoftheSea> In 2013.
<Armbian-Discord> <M​anoftheSea> https://arm-software.github.io/ebbr/ Or in simpler terms, EBBR is designed to solve the embedded boot mess by adding a defined standard (UEFI) to the existing firmware projects (U-Boot). Oh yeah, because they couldn't standardize installing on u-boot, they'll definitely be able to standardize UEFI on u-boot
<Armbian-Discord> <M​anoftheSea> hmm. I should try UEFI booting systemd-boot on an ebin and see if that gets me farther than UEFI booting the linux kernel. Which, I suppose, is outside scope of "armbian-rockchip".
<Armbian-Discord> <T​onymac32> lol
<Armbian-Discord> <T​onymac32> let me know where to get those rockchip ebins
<Armbian-Discord> <T​onymac32> 🙂
<Armbian-Discord> <l​anefu> marvellchip
<Armbian-Discord> <T​onymac32> I know what they are lanefu
<Armbian-Discord> <T​onymac32> 😄