ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
robinp has joined #armlinux
Tokamak has joined #armlinux
apritzel has quit [Ping timeout: 265 seconds]
HdkR has joined #armlinux
cdaudt has joined #armlinux
rbutlerc1728 has quit [Read error: Connection reset by peer]
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ajb-linaro>
seems pretty fatal (I get a sdhci register dump with it). But the sdcard itself mounts fine and obviously the boot (uboot) gets read fine
amitk has quit [Quit: leaving]
amitk has joined #armlinux
<arnd>
ajb-linaro: -5 is EIO, so it might be a card that is failing intermittently, or it could be failing to move into high-speed mode because of an issue with clocks or regulators
<arnd>
ajb-linaro: in general, I don't think it's worth bothering with sd cards as a system file system, they are far too flaky.
<arnd>
what card model is it?
torez has quit [Ping timeout: 245 seconds]
torez has joined #armlinux
<ajb-linaro>
arnd: a Samsung Evo
<ajb-linaro>
arnd: it's not like I'm hammering the file system with anything. The other card seems to boot OK so I'm just comparing boot logs
<arnd>
ajb-linaro: that message is from the SDIO code, not from the block storage. You could try asking ulfh over on #linaro-kernel, but I'd just toss the card at this point
<ajb-linaro>
arnd: it would be unusual for it to fail so early surely? (I only brought this one a week ago)
<ajb-linaro>
but I'm sure work can spring for a proper SSD for the Pi4 for the increased stability
<ardb>
ajb-linaro: if you are going down the USB route, check for UAS support (if you care about performance)
<arnd>
I'm using a "SanDisk extreme portable v2" SSD for my local test machine here, it has a decent PCIe SSD, and works great overall. Went with the "ICE Tower" cooler for the Pi, which may be overkill
<ajb-linaro>
arnd: can you get a PCIe SSD connected directly to the bus? I knew they added PCIe but I thought it was all internal for their own peripherals?
* ajb-linaro
isn't overly concerned about performance - but does want self-hosted development to not be a pain
<arnd>
ajb-linaro: it's not worth the soldering, you get almost the same performance in practice with the USB-to-NVMe adapter
<arnd>
NVMe SSD over UAS is definitely better than SATA-over-USB with the old mas-storage protocol
<ajb-linaro>
arnd: the video I just watched seemed to imply the Compute Module variant exposes the PCI but I need something now ;-)
<mkl>
ajb-linaro: if you want to access the pcie on the rpi4 you have to desolder to usb controller chip :)
<ajb-linaro>
mkl: yeah my main concern is Xen development so I'm not overly concerned - sounds like a USB adapter will work fine
<arnd>
more importantly, the remaining SATA SSDs on the market tend to be crap, so getting an NVMe disk gives you better quality
* ajb-linaro
looks nervously at the 4 Samsung Evo SSD's in his desktop case
<ukleinek>
mkl: or use a compute module :-)
<mkl>
ukleinek: ack
tre has quit [Remote host closed the connection]
<ajb-linaro>
so far the only SSD that has failed on me since I started using them was the 128Gb Intel 520 drive I installed when I first started at Linaro
<arnd>
ajb-linaro: those drives are probably fine, but check the output of 'sudo smartctl -a /dev/nvme0n1p1 | grep "Data Units Written"' to be sure
<arnd>
or "/dev/sda" I guess
cdaudt has joined #armlinux
Misotauros has joined #armlinux
crummel has joined #armlinux
<Sledge_>
ajb-linaro: there's a good cheap USB->SATA adapter that does UAS
jlinton has quit [Ping timeout: 256 seconds]
<Sledge>
Startech USB3S2SAT3CB is what I've tested here
sudeepholla has joined #armlinux
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gpiccoli>
In my case, I'm facing an issue and reaching this point (still debugging), but for me it'd make more sense to BUG()
sudeepholla has quit [Ping timeout: 265 seconds]
<gpiccoli>
since it seems kernel can't progress anyway. This code is old, it's present in the first commit of aarch64
<gpiccoli>
I'm considering changing it to BUG but I might/probably not seeing something...
<broonie>
gpiccoli: This is happening *very* early, are you sure BUG() won't try to print out data structures that aren't set up yet and hence be at best misleading.
<gpiccoli>
broonie, there's a message printed there currently - I need to check the BUG implementation, to see if it's not too much for this point...
<gpiccoli>
but breaking seems to make more sense than just spinning quietly
<gpiccoli>
(the question is how to break properly? heh)
Amit_T has joined #armlinux
frieder has quit [Remote host closed the connection]
Amit_T has quit [Client Quit]
Amit_T has joined #armlinux
CrashTestDummy2 has joined #armlinux
CrashTestDummy has quit [Ping timeout: 252 seconds]
<gpiccoli>
broonie, BUG() calls panic(), which indeed does a lot of stuff - I think that's the reason of cpu_relax, lack of better alternative hehe
<gpiccoli>
Thanks!
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ukleinek>
gpiccoli: then adding a comment for the next who wonders if BUG() would be better, is a nice idea maybe?
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #armlinux
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tudorel has quit [Quit: tudorel]
russ has quit [Ping timeout: 260 seconds]
apritzel has quit [Ping timeout: 265 seconds]
russ has joined #armlinux
<gpiccoli>
heheh ukleinek - maybe!
sudeepholla has joined #armlinux
<gpiccoli>
It's very hard to debug this level of early code...not much resource!
tre has joined #armlinux
jlinton has quit [Quit: Client closed]
jlinton has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
apritzel has joined #armlinux
<milkylainen_>
Any chance of getting a working uefi stack on top of a board with a NXP imx8m or a Cavium Octeon TX 80xx?
<milkylainen_>
As in actual uefi stack, not U-boot playing uefi services?
<broonie>
You mean Tianocore there, u-boot's UEFI is just as UEFI as anything else. I'd not imagine there's any fundamental obstacles, though no idea if anyone's worked on it.
amitk has quit [Ping timeout: 265 seconds]
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
Amit_T has quit [Remote host closed the connection]
tre has quit [Remote host closed the connection]
<milkylainen_>
broonie: Mm. I don't know how complete the U-boot implementation is? Like the secure storage needs some special bits if you'd want something like secure boot to work somewhat as intended?
<broonie>
milkylainen_: The main thing it's missing AFAIR is anything to do with variable storage.
<milkylainen_>
Mmm. I think the U-boot folks are working on it. There is also a custodian branch for U-boot running under UEFI services as an app, much like Barebox. Curious to see how that develops.
<milkylainen_>
I tried it out this monday. But unfortunately there seems to be a toolchain issue with ld.bfd and thin archives. All toolchains I tested segfaults when linking the 64-bit app version.