rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at - *only registered users can talk*
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 252 seconds]
specing_ is now known as specing
Mangy_Dog has quit [Ping timeout: 252 seconds]
<wens> apritzel: they used to have numbering assumptions, at least for the chromebooks
<wens> DuClare: the commits you mentioned did get merged
mripard has quit [Ping timeout: 268 seconds]
huawei has quit [Ping timeout: 260 seconds]
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
huawei has joined #linux-sunxi
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #linux-sunxi
ganbold has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-sunxi
buzzmarshall has quit [Remote host closed the connection]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
Splitice has joined #linux-sunxi
<Splitice> So I've been working on upgrading from u-boot 2018.09 - 2020.01 (initially for python3 support) for my H3
<Splitice> After revertingthe patch "sunxi: psci: avoid error address-of-packed-member"
<Splitice> (which is reverted in master now)
<Splitice> I got past u-boot, finally. However I'm hitting a kernel stall now :(
<Splitice> Anyone else done a similar upgrade? Hit anything?
<Splitice> Debian is running 2021.01, I've got issues even getting past SBL for some reason on that (built with Yocto) so I walked back a year.
jstefanop has quit [Ping timeout: 246 seconds]
<vagrantc> all my H3 boards may be dead at the moment...
<vagrantc> looks like i last tested u-boot 2020.10 on an orangepi_plus 2
<Splitice> vagrantc: any patch required?
<Splitice> did you go via 2020.01?
shailangsa has quit []
<vagrantc> i'm not sure i follow
<vagrantc> i've tested various boards at various versions over the years
<Splitice> did it work vanilla?
<vagrantc> debian's packages have few-to-no patches, typically
<Splitice> I wonder if it's emmc related, I'm running on the neo air
<Splitice> smells like it's completing initrd but failing to mount rootfs or something. I just fail to see how u-boot could cause that.
jstefanop has joined #linux-sunxi
<tuxd3v> Splitice, doesn't it drop you in a shell?
<Splitice> nope nothing
<tuxd3v> what are your command arguments for the kernel?
<tuxd3v> by the way, you can use kernel 5.10, its what I am using on neo Air
<Splitice> arguments and kernel are the same between working and non-working u-boots
<tuxd3v> you can test with uboot 2021.04 it also works..
<tuxd3v> there are a problem, uboot mmc0(sdcard), sometimes become maped to mmcblk1, sometimes its mmvblk2
<Splitice> I've had issues getting past SBL on 2021.01, not sure why so I moved back.
<Splitice> That's what would normally follow on from the point the output stops
<vagrantc> SBL? or SPL?
<Splitice> *SPL
<tuxd3v> in that case emmc is mmvblk2, which meand sdcard is mmcblk1
<Splitice> Really all I wanted was python3 support to move forward in meta-oe...
<tuxd3v> what do you mean as python support?
<tuxd3v> in uboot?
<Splitice> 2018.09 doesnt support python3
<tuxd3v> in the OS, you need to bootit up correctly
<Splitice> (it's tools)
<Splitice> yeah the bootargs are for mmcblk2, those havent changed.
<Splitice> it's the same bootargs
<tuxd3v> probably sometimes you are trying to boot with emmc, sometimes with sdcard
<tuxd3v> the emmc has a old version of ubuntu installed on it
<Splitice> any idea how u-boot can influence that? in both cases I'm booting the same rootfs on eMMC. The only thing I'm swapping is the u-boot (via dd)
<Splitice> the eMMC is my primary boot drive for the device.
<Splitice> eMMC contains a yocto device build
<tuxd3v> well the problem is that emmc is not always mmcblk2, I told you above...its floating
<tuxd3v> sometimes is one, next reboot is 2 and so one..
<vagrantc> uuid and/or partition/filesystem labels
<Splitice> I've not seen that, and I should have cycled enough to get a good boot if that was the case but I'll check
<tuxd3v> PARTUUID, its what I am using, but that is a work around
<vagrantc> or yeah, partuuid :)
<tuxd3v> you are only trying to boot from emmc?
<Splitice> yes, the sd card is purely for recovery purposes
<swiftgeek> 30 days uptime passed on A13, so it really was about temperature dropping too much for something
<tuxd3v> if so, you need to change the bootargs to use UUID or PARTUUID, and in the boot.scr, you need to find the rootfs partition UUID, and pass it in the bootargs
<swiftgeek> maybe i should try attaching peltier to A13 and cooling it sub 10°C
<tuxd3v> not the problem is, you you only have emmc, your best option is to try reboting until the numbers mach, and correct that, or try to boot a sdcard image, and correct that on emmc
<swiftgeek> then if not crashing, repeat for PMIC
<swiftgeek> I just didn't have much success with peltier module to cool anything xD
<tuxd3v> I was unsuccessful with uboot 2021.01, I only succeded with uboot 2021.04, apritzel was very helpful that day.. :)
<tuxd3v> Splitice, but in any case its better for now to use UUID's or PARTUUID
<tuxd3v> I for instance , as a human, prefer PARTUUID, they are smaller , easy to read, and identify partition 1, and 2, exe: /boot , rootfs
<Splitice> I'll test your theory by booting to /dev/disk/by-id/mmc-8GTF4R_0xda6ac021-part3 in a few minutes
<Splitice> just building a u-boot without the auto boot (bootm at the end)
<tuxd3v> its not a theory, its a problem :)
<tuxd3v> I am facing it also on my nanopi neo Air :)
<Splitice> theoretically it's my problem too
<tuxd3v> yes, agree :)
<Splitice> if so I wonder what commit between 2018.09 and 2020.01 it is, I might be able to revert it
<Splitice> I thought linux's dtb would set the mmc numbers... I mean they are defined there
<tuxd3v> well, we even some hours ago sopke about that here in the forum :)
<Splitice> seems strange that they would float
<tuxd3v> spoke*
<Splitice> tuxd3v might I have a link if you have it?
<tuxd3v> let me check the log..
embed-3d has quit [Ping timeout: 260 seconds]
jstefanop has quit [Remote host closed the connection]
shailangsa has joined #linux-sunxi
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
<Splitice> => setenv bootargs "dmmod_numcluster=599036 dmmod_root=/dev/disk/by-id/mmc-8GTF4R_0xda6ac021-part3 dmmod_datablocks=299518 dmmod_hashstart=306706432 dmmod_hash=* rootwait root=/dev/dm-0 rootfstype=ext4 console=ttyS0,115200";
<Splitice> => bootm ${kernel_addr_r} - ${fdt_addr_r}
<Splitice> no such luck
<tuxd3v> part uuid mmc 2:2 rootfsuuid
<tuxd3v> the in bootargs "root=PARTUUID=${rootfsuuid}"
<Splitice> tuxd3v it's not failing to find the partition. I checked the init script used, it reports a failure there.
<tuxd3v> the mmvblk2p3 is the /root, the rootfs in the emmc is in mmcblk2p2
<tuxd3v> but its the partiton 2
freemangordon has quit [Ping timeout: 260 seconds]
<tuxd3v> the rootfs in the emmc its partiton 2 not 3
<tuxd3v> its a sh**T way of creating a OS, but its what it is :)
<Splitice> tuxd3v it's actually 2 and 3 in my case
<tuxd3v> nope rootfs in partiton 2
<tuxd3v> the /root is partiton3
freemangordon has joined #linux-sunxi
<Splitice> err maybe in your specific distribution
<Splitice> but thats entirely customizable
<tuxd3v> well my distribution probably its the same as your since I never touched the Os that come flahed in emmc :)
<tuxd3v> flashed*
<tuxd3v> yet ;)
<tuxd3v> I am creating mine..
<tuxd3v> but the bluethoot is driving me crazy..
<Splitice> Mines a yocto build of balenaos :)
<tuxd3v> sometimes it load the firmware patch sometimes don't and I didn't figured out why it has a willing of its own :D
<tuxd3v> ho so you changed the original OS already?
<tuxd3v> well in that case you know better what partition is your rootfs ;)
apritzel has joined #linux-sunxi
<tuxd3v> Splitice, you have "root=/dev/dm-0"
<Splitice> yup it's a verity mount
<Splitice> boot params havent changed, nothing has but u-boot
<Splitice> that's the confusing thing. It's getting fairly reasonably deep into the kernel before it freezes
<tuxd3v> I boot with bootz
<tuxd3v> you need to sort that out
<tuxd3v> anso the /etc/fstab needs to change acordingly
<Splitice> It's not getting that far, kernel freezes before recognizing mmc2 it appears
<tuxd3v> you will have to boot with a sdcard, tos solve that problem since you are not capable to solve it perse with emmc
<tuxd3v> because you can't change the bootscr that is in the emmc
<tuxd3v> try to start with a simple option, and then jump tp the nuclear one
<tuxd3v> this is to boot from sdcard:
<Splitice> I'm going to try a build on 2020.04. If that doesnt work it's back to 2018 for me
<Splitice> actually I'm just going back to 2018, stuff this. It's been all day
<tuxd3v> :D
<tuxd3v> things litle things sting like a bee :D
tuxd3v has quit [Ping timeout: 240 seconds]
victhor has quit [Ping timeout: 240 seconds]
tuxd3v has joined #linux-sunxi
jstefanop has joined #linux-sunxi
<tuxd3v> Splitice, actually seems that nanopi nei Air enjoy so much success that costs now 999$:
<Splitice> Thats interesting, 20 of them is much cheaper
<tuxd3v> yeah, but buying only one is more exclusive :)
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
<Splitice> They don't have any stock, must be what their billing page does when out of stock
jstefanop has quit [Ping timeout: 265 seconds]
apritzel has quit [Ping timeout: 252 seconds]
diego71 has joined #linux-sunxi
<Splitice> and now after an entire days work I welcome back v2018.09
<Splitice> forward ported the recipe to support some of the newer requirements in the yocto recipe and for now it should work
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 240 seconds]
gsz has joined #linux-sunxi
hlauer has joined #linux-sunxi
cmeerw has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 240 seconds]
matthias_bgg has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
kaspter has joined #linux-sunxi
warpme_ has joined #linux-sunxi
reinforce has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
<warpme_> jernej: apritzel: fyi our yesterdays exchange about uboot on tanix-tx6s: querying gpio with+without sd card gives no change on any gpio pin. uboot shell output for "gpio status -a" is always like this:
andy25225 has quit [Ping timeout: 260 seconds]
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
andy25225 has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
apritzel has joined #linux-sunxi
<apritzel> warpme_: in case you are still having issues with the card detect, a not-too-bad workaround would be:
<apritzel> 1) set CONFIG_MMC0_CD_PIN="" in your defconfig: this is to make the SPL work
<apritzel> 2) do not specify a cd-gpios property in the DT: this is to make U-Boot proper work
<apritzel> 3) add "broken-cd;" to the DT: this is to make Linux work
<apritzel> I have some patch so that you won't need 2)
<apritzel> warpme_: or you find the actual CD GPIO pin ;-)
mripard has joined #linux-sunxi
<warpme_> apritzel: many thx. for hints. let me try above!
<warpme_> apritzel: i added changes you propose and no change :-(. uboot output is like To be on the same page with you now i'm rebuilding 5.13 kernel to your i'll try again and report
akaWolf has quit [Ping timeout: 252 seconds]
prefixcactus has joined #linux-sunxi
akaWolf has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Changing host]
Mangy_Dog has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
<apritzel> warpme_: ah, I see, it's the annoying "SD is no longer MMC0 change" in 2021.07-rc1
<apritzel> I sent this patch as a stop gap measure, but need to revisit that:
<apritzel> I wanted to rework it, but you gave a good argument: all kinds of scripts break
<apritzel> so we probably should go forward with this patch, to avoid those regressions
matthias_bgg has quit [Ping timeout: 240 seconds]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 252 seconds]
camus is now known as kaspter
<apritzel> warpme_: looks like it: if you don't set CONFIG_MMC_SUNXI_SLOT_EXTRA, the MMC line is: #define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0)
<apritzel> so it will try to scan mmc0, which isn't there
<apritzel> (the SD card is probably mmc2)
matthias_bgg has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
<hexdump01> warpme_: i played around with a tx6s some time ago and this is what i used for the cd pin "cd-gpios = <&pio 8 16 GPIO_ACTIVE_LOW>; /* PI16 */" - maybe worth a try
gsz has quit [Quit: Konversation terminated!]
Mangy_Dog has quit [Ping timeout: 252 seconds]
Splitice has quit [Quit: Connection closed]
BorgCuba has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<warpme_> ok. i added in defconfig CONFIG_MMC2_CD_PIN="PI16" CONFIG_MMC_SUNXI_SLOT_EXTRA=2. In DT i have entry with mmc2 and cd-gpios = <&pio 8 16 GPIO_ACTIVE_LOW>;>/* PI16 */. uboot still fails but now says: "Loading Environment from FAT... Card did not respond to voltage select! : -110". Probably too many chages in defconfog+DT to conclude?
<apritzel> warpme_: did you apply the patch I pointed to?
<warpme_> no. shoud i?
<apritzel> MMC2 has no card detect, that's the eMMC, and it's unrelated to your problem
<apritzel> warpme_: you *must*
<warpme_> sure. give me sec!
<apritzel> if you do "mmc list", it probably lists 1 and 2, but no 0
<warpme_> mmc@4022000: 1
<warpme_> mmc list
<apritzel> but the default boot environment looks for mmc 0
hlauer has quit [Ping timeout: 240 seconds]
<apritzel> eventually you should enable the eMMC, both in the defconfig and the DT, but that is orthogonal to your problem here
<apritzel> warpme_: just this one?
<BorgCuba> ohh, orthogonal it is :-)
<apritzel> warpme_: you still need the three things from above
<warpme_> apritzel: let me summarise: 1\ need to add "mmc0 = &mmc0;" alias in sunxi-u-boot.dtsi. What about rest?
<apritzel> yes, you need that, so that the default boot flow finds your boot.scr (I guess this is what you use)
<apritzel> but you still don't see the SD card, for some reason
<apritzel> can you point to your defconfig & DT again? too lazy to scroll up and find it ;-)
<warpme_> ok so CONFIG_MMC2_CD_PIN="PI16" CONFIG_MMC_SUNXI_SLOT_EXTRA=2. in defconfig still needed? And in DT entry with mmc2 with cd-gpios = <&pio 8 16 GPIO_ACTIVE_LOW>;>/* PI16 */?
<warpme_> sure
<apritzel> no MMC2 stuff, this is just distraction
<tuxd3v> apritzel, on nanopinei air WIFI is mmc1
<apritzel> tuxd3v: mmc1 is ambiguous, that's part of the problem here
<warpme_> here it is (for uboot):
<apritzel> tuxd3v: in DT / device lingo that is correct, but U-Boot enumerates it differently
<tuxd3v> due to it beign floating, sometimes I got bluetooth sometimes don't
<BorgCuba> part of the problem or non-orthogonal to the problem so to say?
<apritzel> warpme_: so did your remove &mmc0 completely?
<warpme_> rename it to mmc2
<warpme_> rename->renamed
<apritzel> that's wrong
<apritzel> it must be mmc0, that's not just a name, it's a reference
<warpme_> ok. will go with mmc0. what else?
<apritzel> remove (or comment) the cd-gpios line, and un-comment the broken-cd line
<warpme_> ok
<apritzel> and define CONFIG_MMC0_CD_PIN="" in the defconfig
<tuxd3v> apritzel, shouldn't it be :
<tuxd3v> mmc0 = &mmc0;
<tuxd3v> mmc1 = &mmc1;
<tuxd3v> mmc2 = &mmc2;
<warpme_> CONFIG_MMC_SUNXI_SLOT_EXTRA=2 should stay?
<apritzel> warpme_: shouldn't matter
<apritzel> you don't have mmc2 in the DT anymore, so U-Boot proper will ignore it
<apritzel> I'd remove it for now, to focus on the fix
<apritzel> tuxd3v: eventually that is what smaeul proposed for the mainline DT, but for the sake of fixing the SD card problem just mmc0 is the bare minimum required patch
<tuxd3v> ha ok
<apritzel> tuxd3v: and this U-Boot override .dtsi is some kind of kludge anyway, so I don't want to put too much stuff in there
<apritzel> tuxd3v: and as the current enumeration rules stand, mmc2 would be enumerated as mmc2 anyway, so it's redundant
<warpme_> so for aliases i have now: aliases {
<warpme_> <------>};
<warpme_> <------><------>mmc1 = &mmc2;
<warpme_> <------><------>mmc0 = &mmc0;
<apritzel> tuxd3v: I think the right solution is to remove mmc1=&mmc2; and not add the mmc0 alias, then let fastboot find the eMMC in a more reliable way
<apritzel> tuxd3v: by getting rid of the fixed CONFIG_FASTBOOT_FLASH_MMC_DEV
<tuxd3v> because mmc1 I beliebe its the sdio WIFI
<apritzel> warpme_: yes
<warpme_> ok. building&flashing :-)
<apritzel> tuxd3v: on boards that use that!
<apritzel> tuxd3v: so if you have just SD and eMMC, it was (before 2021.07-rc1): U-Boot mmc device 0 = DT mmc0, U-Boot mmc device 2 = DT mmc2
<apritzel> tuxd3v: if you have an SDIO WiFi, it was: U-Boot mmc device 0 = DT mmc0 (SD), U-Boot dev 1 = DT mmc1 (WiFi), U-Boot dev 2 = DT mmc2 (eMMC)
<tuxd3v> yes
<apritzel> argh, wrong, in the first case it should read: U-Boot mmc device 1 = DT mmc2
<apritzel> so depending on whether you have WiFi the eMMC is either U-Boot mmc device 1 or 2
<apritzel> but for fastboot we need to say which device is the eMMC. So we have "default 1 if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA != -1" in the Kconfig
<apritzel> fixing it to 1
<apritzel> hence the mmc1 = &mmc2; "hack" in this -uboot.dtsi
matthias_bgg has quit [Ping timeout: 252 seconds]
<warpme_> ok - it building now. just to double-check: here is patch im using now:
victhor has joined #linux-sunxi
<apritzel> warpme_: that looks alright now
<apritzel> warpme_: for the DRAM issue, try to unset WRITE_LEVELING, READ_TRAINING, WRITE_TRAINING
<apritzel> warpme_: that's what's needed on the T95 and X96
<apritzel> and enable CONFIG_DRAM_SUN50I_H616_UNKNOWN_FEATURE
<warpme_> apritzel: do you have somewhere uboot additions for T95 and X96?
fourkbomb has quit [*.net *.split]
<apritzel> warpme_: this is my defconfig:, the DT is the one from the h616-v6-WIP branch
<warpme_> apritzel: qll! i see "Starting kernel ..."
<warpme_> now next steep: add kernel DT for tx6s. many thx for your help!!!!
<apritzel> warpme_: there is only one DT
<apritzel> just use $fdtcontroladdr instead of loading something to $fdt_addr_r
<apritzel> ($fdtcontroladdr is the address of U-Boot's DT, you can just pass that to the kernel)
matthias_bgg has joined #linux-sunxi
random_yanek has quit [Quit: random_yanek]
<warpme_> ah yes. that would be perfect world. but h616 has sooo early support that i prefer more "decomposed" model where uboot gives minimum to load kernel and then kernel plays with all peripherials it can. looking on this model only because i foreseen many changes in h616 kernel code + DT. this model requires recompile only kernel to play with.
random_yanek has joined #linux-sunxi
prefixcactus has quit [Ping timeout: 260 seconds]
prefixcactus has joined #linux-sunxi
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 240 seconds]
specing_ is now known as specing
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
gsz has joined #linux-sunxi
Danct12 has joined #linux-sunxi
fourkbomb has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 240 seconds]
<apritzel> warpme_: yes, early means many changes, but also that it's minimal, and any DT would work, really, given you have low expectations
<warpme_> apritzel: fyi: unset WRITE_LEVELING, READ_TRAINING, WRITE_TRAINING and enabling CONFIG_DRAM_SUN50I_H616_UNKNOWN_FEATURE makes correct RAM detection on tx6s. thx for hint!
<apritzel> warpme_: interesting that it did somehow work, on the T95 and X96 you get an error, and it won't work without those settings
<apritzel> warpme_: if you have some time and want to help us out in understanding this, you could experiment which combination works for you
<warpme_> indeed. i see uboot starts kernel - but not yet tested how kernel will go on tx6s... will try soon (professional work is calling :-(((( )
<apritzel> (by just trying to test every combination, or at least trying to enable single options and see if that still works for you)
<warpme_> sure. will do :-)
<apritzel> warpme_: at this stage (serial and MMC only, mostly), the kernel should just work
uis has quit [Quit: ZNC 1.7.5 -]
uis has joined #linux-sunxi
<warpme_> can i assume yours x96_mate defconfig + DT from your h616-v6-WIP are ok for both: x96-mate and T95?
gsz has quit [Quit: Konversation terminated!]
<apritzel> warpme_: yes, the x96 DTS is a pretty safe minimal DT
<apritzel> you might miss out some features, but it should not destroy your box ;-)
<warpme_> :-)
<apritzel> apart from the (mostly ;-) standard PF6 CD GPIO, it's really just the AXP and H616 defaults
e1z0 has quit [Quit: :O]
buzzmarshall has joined #linux-sunxi
e1z0 has joined #linux-sunxi
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Remote host closed the connection]
kaspter has quit [Quit: kaspter]
kaspter has joined #linux-sunxi
hlauer has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Changing host]
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-sunxi
<tuxd3v> apritzel, one the aliases are neded right in ./arch/arm/dts/sunxi-u-boot.dtsi?
<apritzel> tuxd3v: this is the U-Boot hac^Wworkaround to make fastboot work out of the box
<apritzel> the mmc1=&mmc2; line in there
<apritzel> if that stays, we also need to add mmc0=&mmc0;, to make the SD card device 0 again
<apritzel> that's my current patch, but in the long run it seems more sustainable to remove *both* aliases, and let fastboot pick the right eMMC device instead
reinforce has quit [Quit: Leaving.]
jstefanop has joined #linux-sunxi
jstefanop has quit [Read error: Connection reset by peer]
jstefanop has joined #linux-sunxi
jelly has quit [Read error: Connection reset by peer]
<tuxd3v> can't make uboot mmc0, linux mmcblk0
<tuxd3v> also the emmc stays at mmc1( which in uboot is WIFI )
<tuxd3v> by some reason it makes bluetooth module not loading the patch firmware, and not working ..
jelly-home has joined #linux-sunxi
<apritzel> tuxd3v: if you put something in sunxi-u-boot.dtsi, it applies only to U-Boot (unless you use $fdtcontroladdr)
<tuxd3v> ho.. I neded a way to fix mmc1 as WIFI/Bluetooth
<apritzel> tuxd3v: so if you want something consistent all the way through, you would have to put that in both the DT you give the kernel
<apritzel> and the U-Boot DT
<apritzel> tuxd3v: you mean in Linux?
Danct12 has quit [Remote host closed the connection]
<apritzel> then just put mmc1=&mmc1; in your DT you give to Linux
Danct12 has joined #linux-sunxi
<tuxd3v> yeah, if uboot mmc1 is not mmc1 in linux it fails to load the firmware for bluetooth
<apritzel> sorry, that doesn't make much sense: U-Boot's device numbering has nothing to do with Linux enumeration
JohnDoe_71Rus has joined #linux-sunxi
<apritzel> tuxd3v: for a start: I guess you use a separate DT for Linux? Something you load (for instance in your boot.scr) to $fdt_addr_r?
<tuxd3v> well its the patern I found :/ if in linux mmc1 is not WIFI/bluetooth WIFI works, but bluetooth doesn't load the firmrware automatically..
<apritzel> that sounds like a Linux bug, or maybe some firmware load problem
<apritzel> loader*
<apritzel> how do you load the BT firmware?
<tuxd3v> seems that the stars need to bi aligned for it to work :)
<tuxd3v> this is braking my head for some days now, and I managed to pinpoint the problem to the fact that in linux if mmc1 is not wifi then no bluetooth..
<tuxd3v> be*
<apritzel> what userland/distro is that?
<tuxd3v> my own :)
<apritzel> so how do you load the BT firmware?
<tuxd3v> I don't
<apritzel> via some self-baked script?
<tuxd3v> vit DT
<apritzel> ???
<tuxd3v> is thas a compatible line
<tuxd3v> it loads it
<tuxd3v> but if mmc1 is not wifi it simply doesn't load..
<apritzel> I mean there must be something (a script?) that picks up a firmware file from your storage and uploads it into BT chip
<tuxd3v> its in the linux DT
<apritzel> what is in the Linux DT?
<tuxd3v> compatible = "brcm,bcm43438-bt";
<tuxd3v> it loads automatically the firstware, but the stars need to be aligned by sone reason that I still don't know
<tuxd3v> firmware*
<apritzel> sorry, I can't reach that far to fix the stars for you, so we have to revert to good old debugging ;-)
<tuxd3v> :)
jelly-home is now known as jelly
<apritzel> just to be sure, we are talking about a magic firmware file for the Bluetooth chip, right? Something from the /lib/firmware/brcm/ directory?
pnill_ has joined #linux-sunxi
<apritzel> does dmesg tell you anything about it when this works (with the stars are in line)?
pnill has quit [Read error: Connection reset by peer]
<tuxd3v> yes we are :)
<jernej> apritzel: driver autogenerates BT FW and WIFI config file name from chip ID
<jernej> and picks them from that locations, yes
<apritzel> that was my understanding, but I fail to make the connection to the Linux device name
<apritzel> unless this is sloppily hardcoded in some script
<jernej> if chip is properly powered up, driver complains about missing config file or BT firmware
<apritzel> but normally this goes directly via the kernel, right? there should be no userland involved?
<jernej> correct
<jernej> the only responsibility from userland is that config file and firmware exists in pre-determined location
<apritzel> right
<apritzel> so it maybe that the driver is not coming up, and doesn't even ask for the firmware
<jernej> correct
<jernej> that happened a while ago for me with PineH64
<apritzel> tuxd3v: can you post the respective dmesg lines in question in both cases?
<tuxd3v> ok I can..
<jernej> mmc driver somehow couldn't recognize what sdio device was connected
<tuxd3v> Also thete are a second way to load the firmware via userspace
<jernej> but it's working now
<tuxd3v> with:
uis has quit [Quit: ZNC 1.7.5 -]
<tuxd3v> hciconfig hci0 up
<tuxd3v> this will force the firmware to load
uis has joined #linux-sunxi
<tuxd3v> but the bluetooth stach will not work
<tuxd3v> but the firmware is loaded it appears in dmesg
<tuxd3v> usually the first version of loading via DT is the one that works out of the box
<apritzel> I get the impression that this firmware loading is a red herring, it's more a symptom of something else than the cause
<apritzel> if the firmware doesn't load via the kernel driver already (what you call "via the DT"), then you already have a problem, and hciconfig can't fix that
<tuxd3v> here is a failed firmware load, you can see that bluetooth is not working(but WIFI is..diferent firmware..):
<apritzel> so: could this be an ordering issue with the WiFi driver? There is something (regulator/reset) that is only tied to WiFi in the DT
<apritzel> so if that probes first, the kernel activates that, and BT then works
<tuxd3v> WIFI is loaded first always
<apritzel> but if not, the power or reset is off when BT probes, and the driver load fails
<tuxd3v> this board only have WIFI, to ethernet, so I know that WIFI workls 100% of the times :)
<tuxd3v> works..need to buy new glasses..
<tuxd3v> :)
<apritzel> jernej: for those typical WiFi/BT combos, does the WiFi regulator affect the BT part of the chip as well?
embed-3d has joined #linux-sunxi
<jernej> I have no idea, just to be sure, I always extract config file from board maker image
<jernej> and config files are usually board dependant
<jernej> (driver uses board name as part of config file name)
<jernej> I would say that wifi and bt parts are codependent
<jernej> because they both run on same base frequency, they both use same RF path on chip (AFAIK) and driver has usually some code to handle them concurrently
<apritzel> I guess that also depends on the board design: if the regulator is really an external regulator/switch, providing VCC-WIFI, or just some WL-REG-ON *line* into the chip
<jernej> anyway, keep wifi regulator always on
<apritzel> you mean not as a regulator inside the WiFi DT node?
<jernej> no, as mmc-pwrseq-simple node
<apritzel> on the NanoPi Neo Air the actual power seems to come from VDD_SYS_3.3V, and I guess WL_REG_ON pin just activates the WiFi part
<apritzel> jernej: but this would only be activated as part of the WiFi probe, wouldn't it?
<jernej> np
<jernej> *no
<jernej> it's connected to mmc bus
<jernej> and before mmc is scanned, it's powered on
<jernej> well, that's how I understand it
<apritzel> ah, I see
<jernej> check for example pineh64 model b dt
<jernej> there is no wifi node and yet it works
<apritzel> but if the mmc1 device is status="disabled", for instance, it wouldn't activate
<jernej> correct
<apritzel> I see, indeed
<jernej> I don't think you can only power up BT on brcm modules
<apritzel> but since BT is typically an independent UART child (DT wise), this might probe before the MMC busses are scanned?
<jernej> hm... now that I think about, this is very similar case to AC200 :D
<apritzel> or does Linux scan *all* busses first, and only then goes after the devices in each of them?
<jernej> idk
<apritzel> so with the probing becoming more random in mainline recently, maybe that's the problem? Formerly mmc was probed first, the regulators activated, BT coming later: works?
<apritzel> and now the UART and its child are probed before MMC, and it fails?
uis has quit [Quit: ZNC 1.7.5 -]
uis has joined #linux-sunxi
<jernej> could be, but for that we need full dmesg output
<jernej> to see if that's the case
<jernej> note, I'm not 100% sure if wifi part is independent or not
<apritzel> me neither, and the fact that WL_REG_ON is just a GPIO pin, not a real power supply, suggests it is probably independent
<apritzel> but it would somewhat explain the observation ;-)
ganbold_ has joined #linux-sunxi
jstefanop has quit [Remote host closed the connection]
<jernej> apritzel: what is status of H616 USB? do you need any additional workaround than just enabling phy2 resets and clocks?
ganbold has quit [Ping timeout: 240 seconds]
<tuxd3v> this is a full dmesg( bt not working after 10 retires..):
<apritzel> jernej: unclear at the moment, and the Covid jab effects killed my late night hacking time in the last two days ;-)
<apritzel> jernej: with those things it works when booting via FEL (and actually clearing the resets and clock gates before entering Linux)
<apritzel> jernej: but there must be soemthing more, as it fails when booting from SD
<jernej> so there is probably some additional bit somewhere, like that one for video PLLs
<apritzel> yeah, smaeul gave some good hints, I plan to explore tonight
<jernej> I can check boot0 disassembly again
<apritzel> I can compare some registers in U-Boot between SD and FEL boot
<apritzel> if I know which to look at ;-)
<jernej> I suggest you check PRCM :)
<jernej> tuxd3v: are you 100% sure you have right FW? Last time you had that error was due to wrong frequency used in FW
<tuxd3v> if you take a closer look, you will see that WIFi/Bluetooth sdio device is in mmc0 which is plain wrong, because it should be in mmc1( sdio WIFI)
<tuxd3v> jernej, yes I have.. when WIFI is in mmc1, bt just works
<jernej> that can happen with 5.10 and above, due to async probe
jstefanop has joined #linux-sunxi
<apritzel> tuxd3v: this is the *Linux* device name, it doesn't have any real meaning
<apritzel> (other than being used for the block device as well, which triggers those rootfs problems)
prefixcactus has quit [Ping timeout: 268 seconds]
<tuxd3v> jernej, apritzel , many thanks I will try that :)
<jernej> but I fail to see any reason, why probe order would matter - unless something in DT is not right
<jernej> wifi chips are sometimes picky about power on sequence
<apritzel> jernej: post-power-on-delay-ms just delays the Wifi driver probe, right?
hexdump01 has left #linux-sunxi ["WeeChat 1.9.1"]
iamfrankenstein has joined #linux-sunxi
<jernej> IIRC yes
<tuxd3v> well the linux DT has mmc1 node for bluetooth
<tuxd3v> for WIFI sdio
<tuxd3v> bluetooth works via uart3 in nanopi neo air
<tuxd3v> but its the same module
<apritzel> tuxd3v: just to be sure: those various mmc numbers are ambiguous and independent
<tuxd3v> I tough that if you have something described in the DT as mmc1, kernel should use mmc1 for that thing :)
<apritzel> what you see if your .dts file (and only there, in the source!) is a label called mmc1, you reference this with &mmc1
<apritzel> that name does NOT exist in the DTB that the kernel reads
<tuxd3v> you right , but there are there a reference right?
<apritzel> the kernel only sees mmc@1c10000
<tuxd3v> yes
<apritzel> and the numbering you see in the dmesg is just some random, but unique Linux numbering, totally independent from those labels, and mostly meaningless
<tuxd3v> well if that is the case I fail again to understand why the bluetooth doesn't work..
<anarsoul|2> do you actually describe bt in dt?
<tuxd3v> I realize that sd card and emmc are floating , and that gives problems to rootfs.. but for the Bluetooth no clue then..
<tuxd3v> anarsoul|2, yes
<tuxd3v> it loads the firmware that way
<apritzel> sd and emmc are a bit special, because their numbering also creates the userland visible block device names
warpme_ has quit [Quit: Connection closed for inactivity]
<apritzel> if you boot a normal distro, which uses UUID= on the command line and in fstab, then you don't really have a problem with those either
<tuxd3v> this is were I describe bluetooth
iamfrankenstein has quit [Quit: iamfrankenstein]
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
vagrantc has joined #linux-sunxi
ganbold__ has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 240 seconds]
<jernej> apritzel, smaeul: what do you think about this A64 timer fix approach: ?
warpme_ has joined #linux-sunxi
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria]
<apritzel> jernej: do we have people that can reliably reproduce the original issue?
<apritzel> (original issue meaning current mainline fix failing)
<apritzel> because smaeul couldn't do that, IIRC
<jernej> I don't know, tbh
<apritzel> if I find some time, I can upgrade my timer test tool and let it look for failing the mainline pattern
<vagrantc> let's party like it's 2115
<apritzel> shame that that party only happened on some web forums and not on the mailing list :-(
<apritzel> where those remaining errors really about those 100 year time jumps? Not every call to read_cntvct_el0 & friends updates the system time, right?
jstefanop has quit [Remote host closed the connection]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
Putti has quit [Ping timeout: 240 seconds]
putti_ has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
matthias_bgg has quit [Ping timeout: 260 seconds]
choozy has joined #linux-sunxi
hlauer has quit [Ping timeout: 240 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
<apritzel> wow, depending on the "mood" of the A64 (across resets) I see between 1/7th and 1/4th of two consecutive CNTPCT_EL0 reads not reading the same value (at 1008 MHz)
<apritzel> which makes that Freescale workaround quite expensive
<apritzel> and I see the only sane differences being 0 or 1, the rest is clearly bogus
<apritzel> of all those bogus values all have at least the lowest 11 bits all set or cleared
cmeerw has quit [Ping timeout: 250 seconds]
<MoeIcenowy> apritzel: but UUID= in root= is not natively supported by the kernel, it's parsed by initramfs
<apritzel> MoeIcenowy: I know, that is my argument in favour of having smaeul's patch ;-)
<apritzel> because that affects me heavily (booting lotsa kernels without initramfs)
<apritzel> what I said before is that *regular distro kernel* boots should not be affected
<apritzel> because they tend to rely on initramfs, and solve this problem there
jbrown has quit [Ping timeout: 260 seconds]
jbrown has joined #linux-sunxi
choozy has quit [Quit: - Chat comfortably. Anywhere.]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
<tuxd3v> apritzel, puting:
<tuxd3v> mmc0 = &mmc0;mmc1 = &mmc1;mmc2 = &mmc2; in the aliases of linux DT solved the problem related with floating mmc ids :)
lukedashjr has joined #linux-sunxi
<tuxd3v> noe I still can't initialize bluetooth
<tuxd3v> now*
luke-jr has quit [Ping timeout: 240 seconds]
<tuxd3v> only with: hciconfig hci0 up
<apritzel> tuxd3v: because we already guessed that this is unrelated ;-)
<tuxd3v> in this way it loads the firmware patch..
<tuxd3v> apritzel, indeed, you were right
<tuxd3v> :)
<apritzel> but it still doesn't work? (hciconfig triggering the firmware load)
<tuxd3v> cviconfig trigger the firmware load
<tuxd3v> but only using bluetoothctl, it doesn't show up
<tuxd3v> hciconfig*
<apritzel> the aliases influence the numbering only, not the probe order
<apritzel> and my guess is that this order is the problem
<apritzel> I wanted to do some experiments on my BPi-M64, but spent the whole evening with the bloody A64 timer
<tuxd3v> :)
lukedashjr is now known as luke-jr
<apritzel> tuxd3v: do you have some (older, but still mainline) kernel where it works?
<tuxd3v> .probe_type = PROBE_PREFER_ASYNCHRONOUS, it not related or could be?
<tuxd3v> I had it working before
<tuxd3v> but between reboots on /off
<tuxd3v> not always
<tuxd3v> at some 10 reboots is worked or so :)
<apritzel> changing the probe_type would only be a hack (if that would even work)
<apritzel> that's the AP6212, right?
<tuxd3v> yes
<tuxd3v> 26 Mhz crystal
<apritzel> how do you verify that it works? (last time I played with BT was some years ago)
<tuxd3v> if after reboot you see that the firmware was loaded, that's a good sign 'dmesg|grep -E "Bluetooth|cfg80211|brcmfmac|mmc" --color'
<tuxd3v> then use the tool 'bluetoothctl'
<tuxd3v> 'show'
<tuxd3v> if the device is corretly shown, with a correct macaddress, 99.99% of the time it will work..
<tuxd3v> you can use 'scan' then to scan for devices
<tuxd3v> 'pair'
<tuxd3v> and so on
<tuxd3v> inside bluetootctl
<tuxd3v> you can also conect to other devices using 'connect macadress'
<tuxd3v> in mycurrent case
<tuxd3v> I have firmware is not loaded automatically, and 'show' inside bluetootctl shows me this:
<tuxd3v> for a debian based distro, I install this packages:
<tuxd3v> 'apt-get install bluetooth bluez-obexd pulseaudio-module-bluetooth bluez-tools'