ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
libv_ is now known as libv
ftg has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
szemzoa has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme has joined #linux-sunxi
loki6660 has quit []
loki6660 has joined #linux-sunxi
loki6660 has quit []
loki666 has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
ungeskriptet has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
<machinehum> dsimic: Can I see your change for this buildin driver firmware load thing?
<machinehum> Just for curiosity sake
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
<machinehum> Also, another somewhat related problem/question. Between different builds my rootfs is sometimes mmcblk0 or mmcblk1, which makes things anoying because my boot script has to change
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
colinsane has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
warpme has quit []
bauen1 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
<apritzel> machinehum: that's an old (and nasty) story ;-) The kernel position is that there is no particular meaning in the enumeration order, so you have to use other means, like UUIDs or labels
<apritzel> you can force the naming on the kernel side using aliases in the DT
<apritzel> some platforms (like RK, I think) accept them in the mainline DTs, but others (including sunxi) do not
<apritzel> U-Boot puts them in its own copy of the DT (in arch/arm/dts/sunxi-u-boot.dtsi), because it relies on the numbering to be meaningful
<apritzel> so if you do like I preach for years and just use U-Boot's DT for the kernel as well, you get that forced numbering for free!
<machinehum> apritzel: Thanks, sounds reasonable
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.4 Quasar http://www.kvirc.net/]
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #linux-sunxi
<dsimic> machinehum: I haven't implemented it yet, but it's going to be very simple... it's just about doing pretty much the same as in the function linked below
<dsimic> the hard part will be building the case, i.e. making the changes and their users convincing enough to be accepted upstream
<dsimic> s/in the function/in the patch/
<dsimic> machinehum: just checking, the root device changes you're experiencing are on some Allwinner board?
<dsimic> as apritzel already described, Rockchip has that already handled rather nicely
<machinehum> dsimic: allwinner parts
<machinehum> But I made the board
<dsimic> apritzel: do you, by chance, have links to some failed attempts to add aliases to the upstream Allwinner DTs?
<dsimic> machinehum: I see, so it's as apritzel already described :/
<machinehum> Yes
<dsimic> I'd like to read more about those failed attempts to add aliases, if possible
<apritzel> dsimic: please don't go there ;-)
<dsimic> ah, I believe it's better not to, but reading a bit shouldn't hurt :)
<apritzel> I see that it's convenient, but there is indeed no meaning in those numbers, and it's not different from USB/SATA/SCSI devices
<apritzel> I don't have links handy, and that was some years ago, I think triggered by patches trying to introduce that?
<dsimic> true, but the rasoning behind the aliases in Rockchip DTs is how the interfaces are named or numbered in the official documentation, reference schematics, official hardware design guides, etc.
<dsimic> maybe the same reasoning could be apllied to Allwinner DTs
<dsimic> s/rasoning/reasoning/
bauen1 has joined #linux-sunxi
<dsimic> s/apllied/applied/ ... sorry for the typos
<apritzel> yes, that is one argument, but the counter argument is that the kernel never made a promise that say mmcblk0 points to a particular device (in general)
<dsimic> here are some rather recent examples of adjusting the aliases in Rockchip DTs, in which the linked ML discussions may provide a better insight
<apritzel> and you would need other methods anyway (labels, UUIDs) to solve this problem
<dsimic> absolutely, aliases aren't the definitive solution, but they make people's lives a bit easier
<apritzel> I know that Heiko was in the other camp, and courtesy of being a maintainer he just pushed that through ;-)
<dsimic> yup, being a maintainer helps a bit :)
<dsimic> IDK, I'm already going through Allwinner A64 documentation for some other patches, so I'll try to see is there some ground for using the same reasoning
<apritzel> dsimic: as I said, I am not sure it's worthwhile to come up with that again: if you wanna hack it, just smear it into your board DT, or, more elegantly: just use U-Boot's version
<apritzel> dsimic: if you are bored and want to help, I can compile a list of tasks to tackle ;-)
<dsimic> I see, perhaps there's no ground for the same reasoning to be applied
<dsimic> I'm not exactly bored, but it's something that has bothered me and other people for a while :)
<apritzel> I once worked on some tiny userland tool to do the label and UUID resolution, which is small enough (few KB) to be appended to the kernel, so you don't need an initrd, but you can still use the root=LABEL=foo notation
<apritzel> I can try to dig that out, if that helps
<dsimic> perhaps it can help... machinehum, what do you say?
<machinehum> So I think I might have been doing something stupid and getting dtb's mixed up
<machinehum> But I need to fuss around with it a litte more
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
dsimic is now known as Guest3631
dsimic has joined #linux-sunxi
Guest3631 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
bauen1 has joined #linux-sunxi
ftg has joined #linux-sunxi
hramrach has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has quit []
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 480 seconds]
libv_ has quit [Ping timeout: 480 seconds]
libv has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.4 Quasar http://www.kvirc.net/]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
libv_ has quit [Ping timeout: 480 seconds]
libv has joined #linux-sunxi
apritzel has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
apritzel_ has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 480 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 480 seconds]
freemangordon has quit [Ping timeout: 480 seconds]
libv has quit [Ping timeout: 480 seconds]
libv has joined #linux-sunxi