Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
NekoMay has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
indy has quit []
indy has joined #linux-sunxi
vpeter has quit [Remote host closed the connection]
NekoMay has joined #linux-sunxi
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
vpeter has joined #linux-sunxi
lunixoid has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
JoaoSchim has quit [Ping timeout: 480 seconds]
tnovotny has joined #linux-sunxi
lunixoid has quit []
lunixoid has joined #linux-sunxi
JoaoSchim has joined #linux-sunxi
apritzel has joined #linux-sunxi
<mps>
apritzel: I looked at u-boot test during boot and made order according to this. next time I will look u-boot source, though not sure will it conform to kernel ordering
<apritzel>
mps: Hi, so first: there should be no real need for ordering, it's mostly just convenience for us hackers that like to say "root=/dev/mmcblk0p2"
<apritzel>
mps: there is always the far better and more sustainable solution of using label, UUIDs and PARTUUIDs
<mps>
well, I mean fixed ordering for particular board
<mps>
and not random by every boot
<apritzel>
mps: that is a generic problem, not at all related to any board
<apritzel>
there was some discussion about this on the list a few months back
<mps>
I prefer to use /dev/mmcblkXpY more than cryptic PARTUUID
<apritzel>
I understand that, but it's not about you only ;-)
<apritzel>
and IIRC mripard's position on this was that we do not add aliases
<mps>
apritzel: there are already some boards with this fixed order in kernel tree
<apritzel>
Rockchip, you mean?
<DuClare>
UUIDs are not a real solution if you need to know which slot is which
<DuClare>
There may be no card in, it may not be formatted, but you need to know which slot it is
<mps>
apritzel: not only rockchip
<apritzel>
it's somewhat a platform maintainer discussion, and I don't see any Allwinner boards using that in the tree
<mps>
apritzel: look this git commit message in kernel tree f00a99a7a5d066061df21bdce1f2adfd84eb4c2b
<apritzel>
the main argument is that the numbers should not really matter, it's basically at the kernel's discretion to just uniquely number devices, and users should not rely on it
<mps>
apritzel: second answer: about linux-sunxi kernel for alpine, we have few kernels, two 'main' ones i.e. linux-lts is long term supported and linux-edge is latest stable
<apritzel>
mps: arch/arm64/configs should give you an idea about how many kernels there should be for arm64 ;-)
<mps>
and we have linux-amlogic for amblogic (ofc) which is outdated now
<mps>
and we have linux-elm for some mediatek chromebooks
<apritzel>
there should be no reason for platform specific kernels, this is not 2010 anymore (and not arm32)
<mps>
and linux-gru for gru-kevin chromebook
<mps>
most of these I maintain
<mps>
and would like idea to have smaller kernels tweaked and/or tailored for particular SoCs
<mps>
that is why I thinking to add linux-sunxi (for sunxi SoC ofc)
<apritzel>
that's not a good idea, just maintenance burden
<mps>
yes, I know
<gamiee>
I don't think that you need separate kernel for sunxi platform, since most of the things are in mainline and they are working fine ootb
<mps>
but it is burden already, anyway
<mps>
so not much more to have few more of them :)
<mps>
and I have a hope that someone will take some burden from me
anarsoul|2 has joined #linux-sunxi
anarsoul has quit [Read error: Connection reset by peer]
<DuClare>
So if the user should not rely on device numbers, what *is* the correct way to figure out which slot a device corresponds to?
<mripard>
DuClare: why does it matter? It doesn't for which PCIe slot I plugged my SSD on?
<mripard>
or which USB port you plug a USB key
<DuClare>
It matters when when one is meant to be permanent and another is removable, for example
<DuClare>
You don't want to accidentally format and install your system on the USB key when you wanted it on the card that's on the board, in the case
<DuClare>
Or maybe you want to install on the faster slot
<DuClare>
How does an automated installer figure out? Same problem
<DuClare>
Want to install in the internal slot and format the external one for user data for example
<DuClare>
Or whatever
<DuClare>
Do USB host controllers pop up in a random order?
<DuClare>
I think they all have clearly numbered slots if I'm not mistaken
<DuClare>
But if I have no idea what /sys/bus/mmc/mmc0 (or whatever) is, then I don't know if I have a way to figure out which slot it corresponds to without reverse enigneering the board and reading datasheets or something
<mripard>
they are clearly numbered
<mripard>
it's just not stable
<mripard>
same situation
<DuClare>
USB slot numbers are not stable?
<mripard>
even network interfaces numbers aren't stable
<DuClare>
Yea but I was asking about USB now
<DuClare>
Are the bus and port numbers not stable?
<mripard>
there's no guarantee, it depends on the discovery order
<DuClare>
> This identifier is intended to be “stable”, reflecting physical paths in hardware such as physical bus addresses for host controllers or ports on USB hubs. That makes it stay the same until systems are physically reconfigured, by re-cabling a tree of USB devices or by moving USB host controllers. Adding and removing devices, including virtual root hubs in host controller driver modules, does
lunixoid has joined #linux-sunxi
<DuClare>
not change these path identifiers; neither does rebooting or re-enumerating.
<DuClare>
And fwiw I have seen plenty systems rely on bus & port numbers being stable
<DuClare>
Which is kind of relevant when you have multiple USB devices onboard, e.g. usb->rs232 converters
<DuClare>
If you want to know which port is which
<DuClare>
Likewise for PCI, it should have stable slot numbers
<mripard>
we're not talking about the same thing. The physical path to the MMC controller is stable, you'll always get the same path in sysfs, etc.
<DuClare>
Ok
<karlp>
(you just can't use it for any userspace tools...)
<karlp>
at least for ttys, we have /dev/serial/by-path...
<mripard>
but what you're after is the mmc card index, and that depends on the configuration, how and when it's discovered, how and when the module is loaded or not
<karlp>
is there anything like htat for "disks" (be they mmc or sd or other?
<mripard>
karlp: and that's maintained by udev
<karlp>
I still think it's crazy to just go "oh well, sucks, no-one can ever have a predictable number" and think that's a great way forward :|
<DuClare>
Well
<DuClare>
I guess you can make a predictable number for you, with udev or mdev or what have you
<DuClare>
But I feel like it's just terrible UX :(
<mps>
some people don't use udev
<DuClare>
Yea
<mps>
looks like I will just keep these aliases patch for me (and alpine) for some future
<mps>
just booted teres notebook from emmc and see emmc is mmcblk0 and rebooted from external mmc and emmc become mmcblk1
<karlp>
winning!
<karlp>
just the way the gods intended!
<karlp>
but "this is unfixable" and we should just pretend it's ok :)
<mps>
karlp: not for me, I already have fix ;)
<karlp>
I know, just being snarky about how long this thing has been going on for :|
<mps>
yes
<NekoMay>
How is D1 stuff going? Are we mainline-capable yet?
<mps>
(I resisted full year to by apple M1, but changed mind previous week and ordered one, will try install linux on it and forget arm notebook jungle)
prefixcactus has joined #linux-sunxi
<mripard>
karlp: we mentionned 4 robust alternatives already today, so that's a bit misleading don't you think?
<apritzel>
we were just lucky so far that root=/dev/mmcblkxp2 works, it certainly doesn't reliably for /dev/sdax on a PC even, think of USB devices shifting in, or a new SATA disk appearing, or whatever
<apritzel>
that's why distros gave up on this a long time ago
<karlp>
what 4 alternatives? I've read the thread from smaul earlier, re-read it today, I'm not seeing any alternatives other than "of course you should be usiing uuids" and the thread already explains where that falls apart, I'm having a hrd time counting _4_ solid alternatives...
<apritzel>
there is /dev/disk/by-path, btw
<apritzel>
and by-id
<mps>
apritzel: by-path and by-id works only with udev
<apritzel>
sure
lunixoid has quit []
lunixoid has joined #linux-sunxi
qCactus has joined #linux-sunxi
lunixoid has quit []
prefixcactus has quit [Ping timeout: 480 seconds]
<mripard>
karlp: 3, not 4, but partition uuid, label and anything udev-based
<mripard>
you don't even have to use udev, you could achieve the same thing with busybox's mdev
lunixoid has joined #linux-sunxi
<karlp>
I personally don't think uuids are viable as you dont' know them until after the fact, or by experimentation to figure out which is which.
<karlp>
but yes, I know that's often touted as the solution.
<mps>
for ready made images and ready made installs it is, but not for specific usage
<mps>
I usually use FS labels (and initramfs) for installs where I have 'stable' and don't like to mess often with them
<mps>
but for development boxes where I 'play' a lot I don't
<mripard>
isn't it self inflicted then?
<mps>
no, imo
NekoMay has quit [Ping timeout: 480 seconds]
<mps>
with linux (and free software) I like to have different options how I will use it
NekoMay has joined #linux-sunxi
<mripard>
you do have that option though, and you're using it at the moment apparently
<mripard>
each option has their own set of drawbacks, you made a choice
<mripard>
everything's fine then?
<mps>
I will accept whatever sunxi (and kernel devs) decide, don't want to impose my POV
<mps>
just asked about idea
NekoMay has quit [Ping timeout: 480 seconds]
<apritzel>
mps: you could also either use U-Boot's DT ($fdtcontroladdr instead of loading and using $fdt_addr_r)
<apritzel>
mps: or you cheekily add code to U-Boot that sneaks those aliases even into the loaded DT
<apritzel>
mps: we amend this DT already (for filling the /memory node), so it's just a matter of adding a few lines of code there
<mps>
apritzel: thanks. for now it is enough to fix this in kernel, for my use cases
<mps>
apritzel: sorry for curiosity, are you u-boot developer
<apritzel>
mps: I co-maintain the Allwinner port, if that answers your question, but I also do kernel and Trusted-Firmware work
<apritzel>
mps: and honestly I would always prefer a firmware hack over a kernel hack ;-)
<mripard>
apritzel: this opens a can of worm that will just create more inconsistencies
<apritzel>
mripard: patching the loaded DT, you mean?
<mripard>
yes
<mripard>
at least using the algorithm arnd mentioned earlier
<apritzel>
sure, that's was just to add your fourth workaround :-D
<mripard>
like, the Pine H64 has a removable eMMC. We would then make it mmc0, right?
<mripard>
so, what happens if it's not there, but an external SD card is there?
Daanct12 has joined #linux-sunxi
<mripard>
is it mmc0? mmc1?
<mripard>
it would be logical for it to be mmc0, but then we go into the same argument
<apritzel>
no, "SD card" is always mmc0
<apritzel>
that's what U-Boot somewhat relies on
<apritzel>
so we had to fix that
<apritzel>
"SD card" as in: the device connected to SMHC0 @0x01f0f000/0x04020000
<apritzel>
and the one that has the highest BROM boot priority
<mripard>
that's not always the case though?
<mripard>
(the BROM boot priority)
<apritzel>
in 99.9% of the cases
<apritzel>
I think there are some fuses that can change boot priority, but I haven't heard of a board which actually uses that
Danct12 has quit [Ping timeout: 480 seconds]
<apritzel>
also the usage of MMC0/SMHC0 is fixed in the SPL. You can enable/disable MMC2, but not MMC0
<apritzel>
and I am not even sure you can de-throne MMC0 as the boot king, I think the boot order changes in the fuses affect NAND vs. eMMC, IIRC
<apritzel>
at least that's what I read in the H6 manual
<gamiee>
BTW, when mentioning PINE H64, why by default the it's device tree don't contains high speed parameters for eMMC? Since without modification, some eMMCs doesn't work on it.
warpme__ has joined #linux-sunxi
warpme_ has quit [Ping timeout: 480 seconds]
<apritzel>
gamiee: do you mean that it say "mmc-hs200-1_8v", but that doesn't work with some eMMC modules?
cnxsoft has quit []
JohnDoe_71Rus has joined #linux-sunxi
<gamiee>
apritzel: oh wait, I just find out that in latest kernel, the mmc-hs200-1_8v is added only in recent versions and kernel I was using didn't had it
<apritzel>
gamiee: I know, I sent the patch ;-)
<gamiee>
I needed to add mmc-hs200-1_8v, mmc-hs400-1_8v and mmc-hs400-enhanced-strobe to make the eMMC work.
<gamiee>
apritzel: oh thanks! Much appreciated, so I don't need to edit the device tree next time :D (Armbian is on 5.10 atm)
<apritzel>
the later two should not make any difference, the sunxi-mmc driver does not support HS400
<apritzel>
and *having* to add the mmc-hs200-1_8v property points to other problems, because it *should* work with lower speed modes, regardless
<apritzel>
I dimly remember something about DDR modes having problems (HS200 is SDR)
<jernej>
this part is universal enough, that it's shared in all platforms using this script
<karlp>
I think the concern (at least form my pov) is that that method there doesn't really tell me which or where it is, it just takes the first one...
<jernej>
karlp: which method? in my script?
<mps>
jernej: yes, it is possible (but whats wrong to have consistent order after every boot)
lunixoid has quit []
<karlp>
jernej: yeah.
<apritzel>
mps: I think the main argument is to discourage people to *rely* on a fixed order, because it's prone to change
<jernej>
mps: you can rely on order only on one platform. If you don't make any assumptions, it can work everywhere.
<jernej>
karlp: that script is proven (used by end users), where do you see an issue?
<jernej>
loop finds emmc device by looking at properties, so at the end of the loop it either fails (no emmc device found) or you have it in variable
<mps>
jernej: yes, that is what i need, and there are some platforms already with these changes in kernel tree
<apritzel>
as jernej pointed out, looking at sysfs is a generic kernel feature, that works even on ACPI machines or PCs, even
<apritzel>
so it's preferable solution, because that problem is not really limited to MMC. I have a box where sda is USB storage if I happen to have a stick plugged in, or a SATA hard disk, if not
tnovotny has quit [Quit: Leaving]
<apritzel>
mps: I understand it sucks when root=/dev/mmcblk1p2 is so easy, but it's often better to invest some time into a better solution, one that's more future proof
<apritzel>
and jernej's script is a good example for that
<apritzel>
I am halfway into a tiny initrd (8KB), that can be linked into the kernel, which would do LABEL= and UUID= resolution (for ext2)
<mps>
apritzel: good. but I 'play' a lot with devices and FS and it is nice to have consistently ordered e/mmc devices
<mps>
when mounting, making fs etc always have to check which device is at what index
<apritzel>
mps: for mounting within Linux, I use LABEL=xxx in /etc/fstab, that works nicely even with just busybox
<mps>
apritzel: yes I know this, I use it
<apritzel>
mps: and when you talk about "playing around", I just use U-Boot's DT, for A64 that works very nicely
<apritzel>
there is just a difference between "just playing around as a developer" and "pushing a solution to other people"
<mps>
apritzel: I'm not so versed in u-boot inner working
<apritzel>
well, in this case it's not complicated: we sync the DTs from the kernel into U-Boot, semi-regularly. This DT ends up in the U-Boot image, and at runtime is available at $fdtcontroladdr
<apritzel>
so when you boot your kernel, you probably do this via "booti $kernel_addr_r - $fdt_addr_r" at the moment. Then you just replace $fdt_addr_r with $fdtcontroladdr, and be good
<apritzel>
if you want to be really grown-up, you use "bootefi $kernel_addr_r", which automatically uses $fdtcontroladdr
<mps>
nowadays I usually use extlinux.conf
<apritzel>
who is removing all those underscores, btw? is that my client on sending, OFTC, or my client on displaying?
<mps>
to have more kernels and boot options to select during boot
<apritzel>
I use grub for that, just like on a real computer(TM)
<mps>
I don't know, I see underscores in your messages
Benjojo_ has quit []
Benjojo has joined #linux-sunxi
<apritzel>
mps: ah, thanks, so just a misconfiguration on my side, sorry
<apritzel>
(or a pango rendering issue, apparently ...)
<DuClare>
jernej: That's fine if you can rely on type
<DuClare>
Which is not always the case
<DuClare>
E.g. no eMMC but two sd cards
<DuClare>
You go back to figuring out which slot is which
Daaanct12 has joined #linux-sunxi
<DuClare>
And I still think the user experience isn't great if you have to go fishing around for.. what is it on this board.. oh yeah, slot 2 is ff0f000.dwmmc
<DuClare>
Or whatever
Daaanct12 is now known as Danct12
<DuClare>
It'd be so much simpler *for everyone* if you could just document "emmc is mmcblk0, sd card slot 1 is mmcblk1, sd card slot 2 is mmcblk2" and leave all these roundabout ways of getting what you want
<DuClare>
Whether that's spelunking for device type or io register offset in sysfs or maybe sometimes partuuid or label or whatever
<DuClare>
But what do I know about UX :(
Daanct12 has quit [Ping timeout: 480 seconds]
<buZz>
DuClare: what if your device has 6 emmc modules?
<DuClare>
So?
<buZz>
the sd card slot 1 isnt mmcblk1
<DuClare>
Give them a number and document it
<DuClare>
That's all
<buZz>
document where?
<buZz>
globally for all boards ever?
<buZz>
its documented in dmesg
<DuClare>
dmesg doesn't document the board
<DuClare>
It documents the chips on it
<buZz>
[ 1.552468] mmc_host mmc0: card is non-removable.
<buZz>
so, emmc
<DuClare>
Which means nothing to a user
<buZz>
[ 1.640027] mmc1: new high speed SDXC card at address 59b4
<buZz>
oo my mmc2 interface is my SDIO wifi :D
<buZz>
fancy
<buZz>
DuClare: its like PCI slots , they can be any device
<DuClare>
Sigh
<DuClare>
The controllers and slots themselves are hardwired
<DuClare>
And if you have more than one exposed slot on a board, usually the documentation is going to have to have some way to refer to it
<buZz>
DuClare: they arent wired similar on >1 board
<DuClare>
So?
<buZz>
so you are suggesting documenting -all- boards forever
<buZz>
start a document :D
<apritzel>
DuClare: I think your case is a separate thing, and won't be solved by aliases
<DuClare>
Why not?
<apritzel>
it's about putting names or labels to certain device, putting a *purpose* to each of them
<DuClare>
Yes
<apritzel>
so that sounds like a DT property in the MMC node
<DuClare>
For my and my users' sanity, it would be nice if you could rely on hardwired emmc and sd card slots having hardcoded numbers. That's all.
<apritzel>
somewhat like this new chassis-type property
<DuClare>
Yet another way to refer to a device :/
<buZz>
DuClare: how many users are you targetting , and why do they need to know mmc numbers on all boards?
<buZz>
if you are targetting a single device, just write a decent DTS?
<apritzel>
or use an FDT overlay and apply it in U-Boot, without changing the original DT
<buZz>
also a option, but DuClare made it sound like they're setting up a SBC to be shipped to customers
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
Danct12 has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
Daanct12 is now known as Danct12
qCactus has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
anarsoul|2 has quit []
anarsoul has joined #linux-sunxi
JohnDoe_71Rus has quit []
Danct12 has quit [Quit: Quitting]
hlauer has quit [Ping timeout: 480 seconds]
sunshavi has quit [Remote host closed the connection]