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
DC-IRC has quit [Remote host closed the connection]
<DC-IRC>
[Discord] <raspberrygb> I have just tested 6.17 rc 0 on Fedora Rawhide aarch64 iso. And have experienced serious issues with the screen freezing for a number of minutes. 6.16 is fine.
<DC-IRC>
[Discord] <raspberrygb> I have just tested 6.17 rc0 on Fedora Rawhide aarch64 iso. And have experienced serious issues with the screen freezing for a number of minutes. 6.16 is fine.
<DC-IRC>
[Discord] <igorpec> That's rc0
<DC-IRC>
[Discord] <tenkawa42> there is no "6.17.rc0" either
<DC-IRC>
[Discord] <tenkawa42> If you are building something called that... it is something completely Armbian only... the linux kernel is currently in linux-6.17 and linux-next
<DC-IRC>
[Discord] <tenkawa42> If you are building something called that... it is something completely Armbian only... the linux kernel is currently in linux-6.16 and linux-next
<DC-IRC>
[Discord] <tenkawa42> If you are building something called that... it is something completely Armbian/local modified only... the linux kernel is currently in linux-6.16 and linux-next
<DC-IRC>
[Discord] <Werner> I think taking Linux-next and calling it rc0 is some sort of fedora/arch thing
javabean has quit [Quit: well, shoot]
javabean has joined #armbian-rockchip
<DC-IRC>
[Discord] <raspberrygb> Ok. Weird ...
<DC-IRC>
[Discord] <mecoblock> Upstream U-boot as well as Collabora U-Boot both work with vendor 6.1.115 images which is really nice.
<DC-IRC>
[Discord] <mecoblock> for example armbian-install would do everything right then but it would still continue to boot from emmc (tried it out with a local patch where it then worked)
<DC-IRC>
[Discord] <kwiboo> The order is already as intended by design, in the order of fast probe time before slower probe time, so mmc goes before scsi(sata), nvme, usb and at end ethernet
<DC-IRC>
[Discord] <kwiboo> You can always override the order with u-boot env vars
<DC-IRC>
[Discord] <mecoblock> something with saveenv right? Is that doable from userspace?
<DC-IRC>
[Discord] <kwiboo> With correct config options enabled in u-boot and I think you possible need config for userspace to define where uboot env is stored
<DC-IRC>
[Discord] <mecoblock> I think keeping a boot order patch is easier for now. Do you think starting a discussion about this upstream makes sense? I do feel like it would make more sense
<DC-IRC>
[Discord] <mecoblock> but I also get the probe time argument, worked fine in my test though
<DC-IRC>
[Discord] <kwiboo> Feel free to start a discussion, my stand on the question is that the default order is already correct and should not be changed, as it is possible to change the order using uboot env and changing order could break devices in the field if they don't have saved env and is updated
<DC-IRC>
[Discord] <kwiboo> However, making it easier for distro builders to change the default boot_targets could be something to think about
<DC-IRC>
[Discord] <mecoblock> I'm just not sure bc of SPI boot.