<sjg1>
mps: If you add a link here I'll make some comments
<mps>
sjg1: I have to register there to create issue?
<sjg1>
mps: Yes I already registered, but yes, you do. I don't have that device in my lab at present but I could add it. Feel free to send an email to the mailing list also in the meantime
<mps>
sjg1: ok, I will send mail
<mps>
looking source I think it is mmc issue and not spi
<SheriF>
sorry, about this garbage :D darn yubikey :)
<SheriF>
sjg1: thanks! I will check the package, I am building off fedora 2022.01 package and if the distro + ubotu on emmc, cpu resets, if the uboot on emmc and distor in sdcard on rk3399,it boots, so I am just trying to figure out what is wrong
<sjg1>
SheriF: Is this using chainloading or bare metal?
<SheriF>
I am not sure to be honest, I am so new to this :) so I have the uboot on the image and then that uboot loads efi and the efi will load shimaa64 / bootaa64 to grub and goes kernel from there, not sure if that consider chaining? I am using pine64 rockpro64 and I guess it is only "maskrom" that boots uboots and then all goes from there, fedora35 works btw with the uboot I built from fedora rpms
<mps>
sjg1: after looked more at peach pi problem I talked about above I think I should try first to reset its flash and test again to see will it happen again, so will not report bug yet, maybe it is not problem with u-boot
redbrain has quit [Ping timeout: 240 seconds]
sdfgsdfg has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
mmu_man has joined #u-boot
vagrantc has joined #u-boot
indy has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
indy has joined #u-boot
jwillikers has joined #u-boot
<sjg1>
SheriF: neither am I. Here are the instructions, if you are not reflashing the SPI then it must be chain-loading