Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
Daanct12 has left #linux-msm [Leaving]
Daanct12 has joined #linux-msm
Daanct12 has quit [Quit: Leaving]
Daanct12 has joined #linux-msm
cxl000 has quit [Quit: Leaving]
Daanct12 has quit [Quit: Leaving]
<DylanVanAssche>
The WCN3990 WiFi/BT driver (ath10k) fails to retrieve its MAC addresses, the driver uses a random one instead according to dmesg. Is that a known bug? I digged into the src and I think this info is retrieved over WMI?
<Mis012[m]>
where would it retrieve it from exactly?
<Mis012[m]>
you can put it in the device tree
<DylanVanAssche>
Mis012: Putting it in the device tree only works for 1 specific device, I would expect it would read it somehow from the chip which seems to happen using some WMI protocol (I heard of QMI, but not of WMI)
<Mis012[m]>
WMI sounds like Windows clownery
<Mis012[m]>
I don't think it's ever stored in the chip
<DylanVanAssche>
If not on the chip, maybe some partition then? Like the IMEI is also stored on some partition for example
<Mis012[m]>
on 8916 we have the secondary bootloader generate it from emmc id
<Mis012[m]>
s/id/serial number/
<Mis012[m]>
but yes, on android it's probably read from some partition...
<DylanVanAssche>
Well the one that is now picked for the BT stuff is a multicast one and Linux network bridges do not like these addresses making BlueZ unhappy in NAP profile mode.
<Mis012[m]>
the easiest thing to do would be to put it in your devicetree
<Mis012[m]>
if you port u-boot, you could have it added automatically from the partition or wherever you'd want to store it
<Mis012[m]>
maybe u-boot env :P
<DylanVanAssche>
I was hoping for an easier fix than porting U-boot 😛
<Mis012[m]>
well, you can put it in your dts
<Mis012[m]>
manually
<Mis012[m]>
that's easier
<minecrell>
DylanVanAssche: Having the bootloader do it or changing it from userspace are probably the only two sane options
<minecrell>
Since the assigned MAC address is often stored in some board-specific way cluttering the kernel with it would be a big mess
<minecrell>
When doing it from userspace the main challenge is the timing. It usually needs to be done before WiFi/BT are beginning to be used
<DylanVanAssche>
minecrell: In userspace you could (1) read it, (2) bring the iface down, (3) set it, (4) bring iface back up. Since this is at boot, users won't notice this
<DylanVanAssche>
Changing bootloader is tricky or you need to chainload one
<DylanVanAssche>
This is an SDM845 device btw
<minecrell>
DylanVanAssche: Well, personally I am a strong advocate of the "chainload bootloader" approach because it can help in many different situations when the stock firmware behaves weirdly. It is definitely worth the effort IMO. And maybe we just need an easier standalone "chainloaded bootloader" (!= U-Boot) that would be easier to port
<minecrell>
Thinking about the display panel detection for example that is a fundamentally easy thing to do that requires little to none hardware-specific code
<z3ntu>
On FP4 the bootloader puts this in cmdline WifiMac=12:34:56:78:9A:BC (obviously with correct MAC)
<minecrell>
Parsing cmdline and adjusting DT a bit is completely generic ARM code
<minecrell>
Strictly speaking this should not require "porting" at all
<DylanVanAssche>
I agree that chainloading a sane bootloader would be even better 🙂 I started with Bluetooth NAP (=hotspot) but ended up in a rabbit hole why it didn't work.
<DylanVanAssche>
Tested the same setup on the PinePhone Pro which has a sane MAC address and there it works. After some printk statements I couldn confirm in the kernel side that it is indeed the MAC
<DylanVanAssche>
calebccff: is more familiar with the bootloader on SDM845 devs than me TBH
<minecrell[m]>
<DylanVanAssche> "minecrell: In userspace you..." <- iirc when I implemented this for asus-me176c in pmOS (or maybe Android, don't remember) this was a bit challenging because sometimes the MAC address was being changed at the same time when wpa_supplicant or BT started scanning for stuff and the interface was busy
<DylanVanAssche>
minecrell[m]: Ah ok I wasn't sure about that. The userspace stuff is a last resort, if this can be resolved with chainloading (or whatever) the better.
<minecrell>
DylanVanAssche: If you want to get it through QMI (which is definitely used in some qcom devices) userspace would probably be the only choice :S
<DylanVanAssche>
minecrell: I rather not use QMI as it undocumented and proprietary, that's even a further last resort
<minecrell>
DylanVanAssche: the call is supported in libqmi FWIW
<minecrell>
(the one I'm referring to)
<DylanVanAssche>
Ah didn't know that, makes things easier if I need the QMI route
<minecrell>
should be --dms-get-mac-address=[wlan|bt], guess you can check if that returns the MAC address used on Android
<minecrell>
but there are just as many devices that store it in random files in random partitions or wherever
<calebccff>
minecrell: downstream also does it in userspace on sdm845, it's stored in a file on the persist partition
<minecrell>
calebccff: qcom downstream or $whatever-vendor downstream?
<calebccff>
minecrell: qcom
<minecrell>
Guess they switched then, thought they used qmi on earlier SoCs
<Mis012[m]>
minecrell: you could in theory make a u-boot board that is just "run as secondary bootloader on generic aarch64 device" and take the few board/soc specific things like ram address/size from the dt passed by primary bootloader
<z3ntu>
On FP2 (msm8974) the wifi and bluetooth MAC come from modem(?) via this qmi call. FP3 (sdm632) I don't know right now
<Mis012[m]>
there is already efi payload for x86
<Mis012[m]>
so it would be similar to that
<minecrell>
Mis012[m]: It's probably not worth taking U-Boot at all then. Initializing a stack and having some very basic libc implementations is probably enough to compile libfdt. And once you have that you can easily read the cmdline from the passed DTB and modify a new one
<minecrell>
In principle it's a fairly simple thing to write
<Mis012[m]>
well, it's always nice to have u-boot ported
<Mis012[m]>
since you can then add more stuff to it gradually and build up to u-boot1st
<minecrell>
Mis012[m]: yeah I'm just saying that it would be nice to have something that would possibly just work(TM), everywhere so we don't have to keep discussing hacking stuff into Linux because SoC XYZ doesn't have a good open-source bootloader
<Mis012[m]>
well, u-boot could just work everywhere and as a plus it would make it more approachable to people who might then port it properly
<minecrell>
Mis012[m]: sure, I'm not generally ruling out U-Boot but it doesn't fully fit into the idea of a very small "chainloader" that would let the previous bootloader handle all the loading from flash/eMMC/UFS/SSD/USB/Network/Serial/... and just apply some additional quirks
<Mis012[m]>
but it can be used like that, and introducing more people to it might be beneficial for actual u-boot support
<minecrell>
Mis012[m]: iirc U-Boot wants a fixed memory layout on aarch64 already though which might already be too much
<minecrell>
I was kinda thinking of a very simple binary that would literally load on any ARM platform
<minecrell>
read the passed DTB, modify it a bit, continue
<Mis012[m]>
minecrell: eh... can probably be read from the devicetree passed by primary bootloader
<minecrell>
possibly
<calebccff>
minecrell: +1 to having a tiny generic chainloader, that would be really nice! Something that would be prepended to the kernel and just do basic DT stuff. Maybe it could even be upstreamed into Linux then too?
<minecrell>
the chainloader source code into Linux?
<calebccff>
would solve a lot of problems, realistically beyond that the next useful step is full UFS support, which... if it can reuse Linux drivers in some form would be pretty nice :P
<calebccff>
minecrell: yeah! I really don't want some external step or thing to flash. We have issues which have to be solved between the bootloader and the kernel somehow, we either do it in kernel (unadvisable) or we add a chainloader, no reason that chainloader shouldn't be maintained with the kernel
<minecrell>
Well I think the Linux repo is big enough, in theory it should be just as easy to collaborate on some separate repository
<calebccff>
I suppose.. But being able to integrate it into the kernel build system would be nice
<calebccff>
arch/arm64/chainloader :D
<minecrell>
calebccff: it is probably hard to get people to agree exactly on something like that, since the use case is still somewhat specific to Android devices, I guess
<minecrell>
There is the boot-wrapper already for example, which is also some kind of chainloader but more intended if you have no firmware at all and just want to do minimal initialization in EL3 to boot Linux
<calebccff>
minecrell: well there is EFISTUB too already, any a huge amount of code in Linux is almost exclusively for Android devices now, loads of devices are supported to some extent, and I'm sure there are other useful applications
pespin has joined #linux-msm
<Mis012[m]>
wasn't the point to NOT have ugly hacks in Linux?
cxl000 has joined #linux-msm
qyousef_ has quit [Ping timeout: 480 seconds]
qyousef has joined #linux-msm
jstultz_ has joined #linux-msm
jstultz has quit [synthon.oftc.net graviton.oftc.net]
rnayak has quit [synthon.oftc.net graviton.oftc.net]
qyousef has quit [Quit: WeeChat 2.8]
qyousef has joined #linux-msm
rnayak has joined #linux-msm
svarbanov has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
jstultz_ has quit []
jstultz has joined #linux-msm
pespin has quit [Remote host closed the connection]