eduardas has quit [Quit: Konversation terminated!]
ldevulder has joined #linux-sunxi
ldevulder has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 240 seconds]
lucascastro has quit [Ping timeout: 264 seconds]
tuxillo has joined #linux-sunxi
lucascastro has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
lurchi_ is now known as lurchi__
apritzel has joined #linux-sunxi
<karlp>
"automatic privacy mode by default" ;)
<mirko>
hm, i broke something and now kodi doesn't play videos anymore. log says "ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: Operation not permitted (-1)" and atm I'm out of ideas. kernel? ffmpeg? kodi? something apparently is lacking support for something..
<mirko>
i'm on h6
<jernej>
mirko: most likely cause for that is out of sync headers between ffmpeg and kernel
<jernej>
but could be anything, really
<mirko>
hm, ok, i'll go for the "most likely cause" first then i guess :)
<mirko>
another curious thing: when i levelled up from 5.9 to 5.10 (both having libreelec patches applied), booting failed, root=mmc0blk0 didn't match anymore. enumeration seems to change, as it listed mmcblk*2* as available block device. when changing the root= cmdline param accordingly to my surprise it couldn't find it either, but now listing mmcblk*1* as available. changing cmdline root= param to that
<mirko>
switched back to mmcblk*2* being available. no matter what i specified it was wrong
<jernej>
starting with 5.10, mmc is probed async
<jernej>
so best bet is partuuid
<mirko>
ö
<mirko>
oops for the 'ö' - hm, ok, that's quite a semi-subtle change in behaviour i gotta say
<jernej>
not sunxi specific
<mirko>
i figured.. but still, especially the jumping
<mirko>
i mean, it's a fixed device and the only mmc one, shouldn't
<jernej>
thankfully, LibreELEC uses partuuid for a long time and there was no impact
<jernej>
using partuuid has another advantage, it doesn't change with the boot device
<jernej>
so same image can be written to either SD card or eMMC and it will work
DonkeyHotei has joined #linux-sunxi
lurchi__ is now known as lurchi_
lucascastro has quit [Remote host closed the connection]
<kjn260>
this is still present on mainline device tree for A33 - is it a problem? anything to add to suppree?
<kjn260>
supress*?
DonkeyHotei has quit [Ping timeout: 256 seconds]
<mirko>
jernej: i totally see the advantages of PARTUUID and/or (FS)UUID, don't get me wrong. But if I set up a computer let's say 10 years ago and bumped my kernel every couple of months and no HW support was dropped for good reason, I really don't expect it to break because root=/dev/hda1 is suddenly wrong
<apritzel>
kjn260: it's not a problem, I would actually say the fact that this is using dev_err is almost a bug
* apritzel
agrees to mirko that this is annoyingly close to a regression
<jernej>
some are treat it like regression for sure
<jernej>
*treating
<apritzel>
mirko: you can try to add aliases to the DT to force an order
<apritzel>
mirko: like: mmc0 = &mmc0;
<apritzel>
the redundancy of which gives already a hint that something is fishy here
<mru>
you can try, but it won't work
<mru>
support for that was rejected by the kernel maintainers years ago
<apritzel>
mru: yeah, that's my experience as well, but it was once recommended as workaround
<apritzel>
and by try I mean add to your DT copy
<mru>
the mmc driver doesn't honour it
<apritzel>
mru: did that never work? I had the impression the discussion was about whether that's the right approach in general
<apritzel>
mru: thanks, from the more recent discussion I got the impression that this was working at some point in time
<apritzel>
but maybe not in mainline
<apritzel>
mru: ah, I see you warmed this up later ...
<mru>
only to be told I was doing it wrong
<mru>
"use UUID" isn't a solution
<mru>
because to do that, you have to write the UUID to the device you're trying to find
<apritzel>
I would say that UUID is *one* solution, but not the only one, and not working in some cases (cloning partitions, running kernels without initramfs, ...)
<mru>
initramfs has nothing to do with it
<mru>
I need to find the correct device when it's brand new and blank
<apritzel>
sure, but that's just one of the problems, me being used to root=/dev/mmcblk0p2 is another one
<mru>
referring a PARTUUID would be an inconvenience but not impossible once it's written
hlauer has quit [Ping timeout: 256 seconds]
<mru>
but I have to write the partition table to the correct device
<apritzel>
mru: I hear you ...
<mru>
and I need to access /dev/mmcblockNbootM devices
<apritzel>
well, I used that as a differentiator between eMMC and SD the other day
laj has quit [Quit: Connection closed]
<mru>
let's pretend I have two emmc devices
<apritzel>
for num in 0 1 2; if [ -b /dev/mmcblk${num}boot0]; then ...
<apritzel>
mru: yeah, not saying it's bullet-proof, but most boards barely have one eMMC