<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..
<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?
<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: https://pastebin.com/dniXbUJ8
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!
<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
<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
<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: https://pastebin.com/YARvR2RV, 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
<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
<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
<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?
<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
<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
<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