00:22 <machinehum> Hello, I've had some issues getting my board to boot (allwinner A33, SD and DDR3). https://pastebin.com/raw/ZBK7AeuX I traced the error to here https://elixir.bootlin.com/linux/latest/source/drivers/mmc/core/core.c#L1105 Then realised host->ocr_avail wasn't being set anywhere in the host driver. I then applied this patch https://pastebin.com/raw/Gu1nK3cN and everything booted

00:22 <machinehum> fine

00:23 <machinehum> Did I find a bug? Or am I doing something completely wrong

05:01 <jernej> machinehum: that is set automatically based on vmmc and vqmmc (if needed) power supplies from DT

05:02 <jernej> sorry, based on vmmc power supply only

05:26 <machinehum> What do you mean?

05:26 <machinehum> "set automatically"

05:27 <machinehum> Oh, so the power supply driver is responcible for changing those values

05:30 <machinehum> So if one is to use just normal power supplies they should write a dummy driver?

05:40 <jernej> what do you mean by "normal power supplies" ?

05:40 <jernej> you need to specify at least vmmc power supply, even if it uses fixed regulator, yes

05:41 <jernej> just add fixed regulator node and reference it

10:17 <jernej> arnd: do you know by any change why some SDIO quirks are applied in mmc core rather than in driver? like these: https://elixir.bootlin.com/linux/latest/source/drivers/mmc/core/quirks.h#L137

10:17 <jernej> *chance

10:20 <arnd> jernej: don't know. I guess it's either because it's needed for the core to interact with the device before the driver has a chance to apply quirks, or because this is old code that would be done differently now

10:21 <arnd> elixir tells me that the wfx driver applies the same quirk in the probe function: https://elixir.bootlin.com/linux/latest/source/drivers/staging/wfx/bus_sdio.c#L209

10:21 <jernej> hm... I'm untangling xr819 hacks and I'm not sure which way to go

10:22 <jernej> out of tree driver also does it in probe function

10:22 <jernej> so I guess it is ok to do it in driver

10:23 <arnd> ok, don't change it then, and maybe start adding changes into cw1200 to do the same where you something like this that xr819 appears to do better

10:23 <arnd> oh shit, is drivers/staging/wfx/ another copy of hte same driver? The file names look rather familiar

10:25 <arnd> Copyright (c) 2010, ST-Ericsson, Copyright (c) 2017-2019, Silicon Laboratories, Inc.

10:25 <arnd> yep

10:25 <jernej> looks like it

10:26 <jernej> but there is a lot of different code at first glance...

10:26 <arnd> it's been in staging for two years, so a lot of stuff may already have been "improved", without the goal of merging it into cw1200

10:27 <jernej> arnd: this is interesting one: https://elixir.bootlin.com/linux/latest/source/drivers/staging/wfx/fwio.c#L83

10:27 <jernej> read comment above

10:28 <arnd> in any case, looking at "git log -p drivers/staging/wfx/TODO" may reveal some problems that are also present in either cw1200 or xr819, and how to address them

10:29 <warpme_> jernej: sorry for late replay (prof. life gets me). here is log from xr819 with all debug set to 0xff: https://pastebin.com/Nc4jZx9a

10:30 <arnd> jernej: in any case, can you try contacting Jérôme Pouiller <jerome.pouiller@silabs.com> about this? He is the person that added the wfx driver in the first place, he is doing a lot of cleanup work, and he probably has access to the datasheet of at least some hardware versions

10:30 <jernej> warpme_: thanks!

10:30 <jernej> arnd: seems reasonable, will do!

10:39 <arnd> jernej: warpme_: I found jerome's driver repository, which has over 1500 commits

10:40 <arnd> the initial import of a driver described as "version 1.6" was from 2018, around the same time as the imports that icenowy did: https://github.com/SiliconLabs/wfx-linux-driver/commit/ae875cd4fd4c65e2

10:41 <arnd> comparing those two initial imports should make it easier to figure out whether the two are compatible enough to consider merging

10:42 <arnd> based purely on the number of commits, and the fact that he seems to be a full-time developer on this particular driver, I would guess that this is in fact a better base for future work, as long as the hardware is similar enough and someone can make it work

10:42 <jernej> hw_revision for wfx is 2 and for xr819 is 4, while cw1200 supports multiple

10:43 <jernej> but that shouldn't be major issue

10:45 <arnd> unfortunately, looking at the number of lines per file, the above already seems to have diverged from https://github.com/Icenowy/xradio/commit/5ba2bec7f4f4aa8, and we don't have any prior history of either side

10:46 <arnd> xradio has 27724 lines in the original commit, wfx has 15176, so either wfx is for a simpler version of the hardware, or it was already cleaned up before that commit

11:00 <MoeIcenowy> jernej: well I think the cw1x60 support in cw1200 driver is never complete, right?

11:03 <MoeIcenowy> BTW wfx seems to have no bootloader firmware file, so it should be not so cw1x60

11:22 <jernej> MoeIcenowy: yes, cw1200 doesn't support cw1x60, but it's easy to add, my hacks already make it work

11:23 <jernej> I wonder if API version 1060 for xr819 actually means that x in 1x60 is 0 or might be just coincidence

11:26 <MoeIcenowy> jernej: maybe coincidence

11:26 <MoeIcenowy> what I read about on wayback machine says x is 1 or 2

11:26 <MoeIcenowy> (meaning 2.4G only or dual band

11:29 <jernej> oh, xr819 is supposedly dual band, caps 0x3 means both bands are supported (1 - 2.44 GHz, 2 - 5 GHz)

11:30 <plaes> o_O

12:04 <arnd> https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2020/07/03/kba_wf200_wfm200linuxdriverwithallwinnersoc-jTTW

12:08 <arnd> I see wens and mripard were on Cc on that thread when Jérôme talked about using the wfx driver on an A20 machine, but it's possible that nobody made the connection that this might be the xr819 hardware

12:11 <arnd> I also found a couple of linkedin profiles of people working on wireless networking at silicon labs since 2010, and before that at ST-Ericsson, so it seems plausible that silabs took over that entire product line from ste and licensed it to xradio/allwinner later

12:11 <arnd> Jérôme only joined silabs in 2018, so he was not part of the original team

12:22 <arnd> https://github.com/XradioTech/xradiotech-wiki/wiki/Download#XR819 has newer datasheets than the copy on linux-sunxi.org, but I don't see anything helpful in there

16:47 <warpme_> jernej: fyi: i give run for cw1200 on my 2 boxes (TX6 & TX6s). On both driver works well!. Very nice work. I can connect to AP. Not yet tested under normal operation as by some reason driver is not autoloading (even when i have matching compatible string in DT). btw: also - by curiosity i checked sleep-resume on h6. karabek driver just hangs box. cw1200 driver causes box immediately returns from sleep. dmesg says:

16:47 <warpme_> https://www.irccloud.com/pastebin/eD63w5BW/

16:49 <warpme_> any way - this is very promising work!

16:50 <jernej> warpme_: driver is loaded based on SDIO VID & PID

16:50 <jernej> hm... I have it build in, I didn't try it as module, because my setup won't allow it

16:51 <machinehum> jernej: Like this? https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/sun8i-a33-olinuxino.dts#L85

16:51 <machinehum> Because that wasn't working

16:52 <jernej> machinehum: yes, is this your board or is only similar to olinuxino?

16:53 <machinehum> It's similar, I used the olinuxino as a ref. But I didn't use the AXP2* PMIC

16:53 <machinehum> So most of getting my board booting has been ripping out all the PMIC stuff

16:54 <jernej> warpme_: add "MODULE_DEVICE_TABLE(sdio, cw1200_sdio_ids);" to cw1200_sdio.c

16:55 <jernej> it should allow to auto load driver

16:57 <jernej> machinehum: include sunxi-common-regulators.dtsi in your DT and change that line to "vmmc-supply = <&reg_vcc3v3>;"

16:58 <warpme_> jernej: isn't be better to make L271 with of_device_id xradio_sdio_of_match_table which already has .compatible = "xradio,xr819" working?

16:59 <jernej> won't help - this driver is currently loaded based on SDIO IDs

16:59 <warpme_> ah ok.

16:59 <jernej> well, it would be possible

17:03 <warpme_> jernej: qll. driver autloads. let test some daily usage :-)

17:05 <jernej> warpme_: regarding PM, driver blocks suspend if there is something to do and if it isn't instructs kernel not to turn off power supply

17:05 <jernej> so this is a bit weak point

17:05 <fcas> I made a System on Module based on Allwinner H3 (pretty close to Orange pi pc plus), but I cant get it out of FEL Mode. Can someone help me please?

17:07 <fcas> I send uboot, and could use md.l 0x01c00024 1 (read the register that shows how is the FEL Mode GPIO, and can verify that the GPIO is working (reads 1 when it should be 1, 0 when shorted to ground)

17:07 <fcas> *I sent uboot using sunxi-fel

17:08 <warpme_> argh - random MAC kills me....

17:09 <jernej> warpme_: you know solution - add ethernet1 alias to DT and make sure it's in U-Boot DT too

17:09 <jernej> fcas: to be clear - does U-Boot over FEL work?

17:11 <jernej> fcas: write commands you're using

17:16 <jernej> apritzel, smaeul: I get warning on X96 (H616) at reboot: "r-apb2-rsb already disabled" and "r-apb2-rsb already unprepared"

17:17 <jernej> it's like sunxi_rsb_hw_exit() is called 2 times

17:20 <fcas> uboot over FEL works, I can even share MMC as UMC and write image there using tools on desktop

17:20 <fcas> *UMS

17:25 <fcas> command to share MMC: ums 0 mmc 1 (I'm using yocto and added UMS support to uboot, tested on orange pi pc plus and was able to write image on its mmc and boot)

17:26 <fcas> I even tried armbian and h3droid (both of them can boot orange pi, none can boot my SoM

17:26 <jernej> once you boot U-Boot, you're out of FEL mode

17:26 <fcas> yes, but I can only get out of it sending uboot via sunxi-fel tool

17:27 <jernej> but not from SD card?

17:27 <fcas> no, not from SD card nor MMC2

17:28 <fcas> I burned 4 different images to SD cards, all of them work on orange pi, none of them work on my SoM

17:28 <jernej> do you get any kind of output via UART when booting from SD card? at least something from SPL?

17:28 <fcas> if I send uboot via sunxi-fel, I can use ext4ls and fatls to see that the files are there

17:30 <fcas> I dont get any output if I just power up the board with the SD card inserted. I can check that the SoM is still in FEL mode using sunxi-fel version

17:30 <jernej> then bootrom for some reason doesn't detect SD card at all

17:30 <fcas> neither SD Card nor MMC2

17:31 <fcas> what should I read in SID if the Allwinner H3 is new?

17:32 <fcas> I was expecting 02c00081 00000000 00000000 00000000

17:32 <jernej> did you route SD card & eMMC signals & power supply same way as on OrangePi board?

17:32 <fcas> yes

17:33 <jernej> did you by any chance enable secure boot?

17:34 <fcas> I'm unsure, since I got all Allwinner H3 chips from Aliexpress

17:34 <fcas> can you help me check that?

17:35 <fcas> I tried using md.l 0x01c14248 1 , and got 00000000

17:36 <jernej> here you have collection of sid content in the wild: http://linux-sunxi.org/SID_Register_Guide#Currently_known_SID.27s

17:36 <jernej> scroll down a bit for H3

17:36 <fcas> i collected from orange pi pc plus and from 2 copies of my SoM

17:36 <fcas> orange pi: 02c00081 95604620 78a2c410 0c290b13

17:37 <fcas> SoM1: 02c00081 94004620 50354724 50290c8e

17:37 <jernej> ah, I think it's not secured, otherwise it wouldn't boot over FEL

17:37 <fcas> SoM2: 02c00081 14004620 50354224 0824078e

17:38 <jernej> looks ok

17:42 <jernej> fcas: how did you connect UBOOT pin (W6)?

17:43 <fcas> I pulled it up with 10kohms to VCC_3V3, and I can use a strap to short it to ground when I need it

17:44 <jernej> can you leave it floating (internal pull up should do) and test again?

17:45 <fcas> ok, i will try that

17:51 <fcas> didnt work, same behavior

17:52 <fcas> I could read the GPIO sending uboot via fel mode, it could be seen as 1 when the strap was open and 0 with the short circuit

18:32 <machinehum> jernej: Thanks

18:34 <jernej> fcas: then I'm out of ideas

18:35 <fcas> sadly, me too. Thanks anyway jernej

18:37 <jernej> fcas: ultimate debugging would be to connect JTAG and step over instructions in bootrom, but I never done this and it would be very tedious

18:54 <gamiee> fcas: so to sum it up, your H3 SoM everytime gets into fel, but after booting into u-boot (via fel) , you can probe the SD or eMMC and verify that everything is correct, right?

19:04 <fcas> yes, that is right gamiee. And the same SD Card can boot a orange pi pc plus (H3 based too)

19:19 <gamiee> fcas: uhhhh, well, this is kinda hard to debug. As jernej said, the best way is to debug bootrom via JTAG, but it's kinda really hard

19:19 <gamiee> But only Uboot pin should impact the boot flow

19:20 <gamiee> Well, did you tried to boot Android image? Or burn one to eMMC via fel?

19:21 <fcas> I tried h2driod image, armbian image, 2 yocto generated images (all of them work on Orange pi pc plus

19:21 <fcas> and shared MMC2 as UMS and burned one image to MMC2 using fel mode + uboot

19:22 <gamiee> I mean stock Allwinner images (h3droid should be it, but hmm)

19:22 <gamiee> Well there is way how to verify its really bootrom / Uboot pin problem

19:22 <gamiee> Do you have exposed SPI pins? (probably SPI0)

19:23 <fcas> I put spi0 and spi1 on headers

19:24 <fcas> with md.l 0x01c00024 1, I could read the status of the uboot pin

19:24 <gamiee> I would try mount SPI Flash to SPI0, and burn u-boot into it.

19:24 <fcas> and could verify that it follows the external circuit

19:25 <gamiee> SPI is simple, so you can even check if bootrom will try to read it (with signal analyzer)