<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
<jernej>
hm... I'm untangling xr819 hacks and I'm not sure which way to go
<jernej>
out of tree driver also does it in probe function
<jernej>
so I guess it is ok to do it in driver
<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
<arnd>
oh shit, is drivers/staging/wfx/ another copy of hte same driver? The file names look rather familiar
<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
<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
<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
<jernej>
warpme_: thanks!
<jernej>
arnd: seems reasonable, will do!
<arnd>
jernej: warpme_: I found jerome's driver repository, which has over 1500 commits
<arnd>
comparing those two initial imports should make it easier to figure out whether the two are compatible enough to consider merging
<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
<jernej>
hw_revision for wfx is 2 and for xr819 is 4, while cw1200 supports multiple
<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
<MoeIcenowy>
jernej: well I think the cw1x60 support in cw1200 driver is never complete, right?
<MoeIcenowy>
BTW wfx seems to have no bootloader firmware file, so it should be not so cw1x60
<jernej>
MoeIcenowy: yes, cw1200 doesn't support cw1x60, but it's easy to add, my hacks already make it work
<jernej>
I wonder if API version 1060 for xr819 actually means that x in 1x60 is 0 or might be just coincidence
<MoeIcenowy>
jernej: maybe coincidence
<MoeIcenowy>
what I read about on wayback machine says x is 1 or 2
<MoeIcenowy>
(meaning 2.4G only or dual band
<jernej>
oh, xr819 is supposedly dual band, caps 0x3 means both bands are supported (1 - 2.44 GHz, 2 - 5 GHz)
<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
<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
<arnd>
Jérôme only joined silabs in 2018, so he was not part of the original team
faruk has quit [Remote host closed the connection]
fcas has joined #linux-sunxi
cmeerw has joined #linux-sunxi
fcas has quit [Remote host closed the connection]
tnovotny has quit []
kmaincent has joined #linux-sunxi
choozy has joined #linux-sunxi
vagrantc has joined #linux-sunxi
fcas has joined #linux-sunxi
<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:
<jernej>
machinehum: yes, is this your board or is only similar to olinuxino?
<machinehum>
It's similar, I used the olinuxino as a ref. But I didn't use the AXP2* PMIC
<machinehum>
So most of getting my board booting has been ripping out all the PMIC stuff
<jernej>
warpme_: add "MODULE_DEVICE_TABLE(sdio, cw1200_sdio_ids);" to cw1200_sdio.c
<jernej>
it should allow to auto load driver
<jernej>
machinehum: include sunxi-common-regulators.dtsi in your DT and change that line to "vmmc-supply = <®_vcc3v3>;"
<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?
<jernej>
won't help - this driver is currently loaded based on SDIO IDs
<warpme_>
ah ok.
<jernej>
well, it would be possible
<warpme_>
jernej: qll. driver autloads. let test some daily usage :-)
<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
<jernej>
so this is a bit weak point
<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?
<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)
<fcas>
*I sent uboot using sunxi-fel
<warpme_>
argh - random MAC kills me....
<jernej>
warpme_: you know solution - add ethernet1 alias to DT and make sure it's in U-Boot DT too
<jernej>
fcas: to be clear - does U-Boot over FEL work?
<jernej>
fcas: write commands you're using
<jernej>
apritzel, smaeul: I get warning on X96 (H616) at reboot: "r-apb2-rsb already disabled" and "r-apb2-rsb already unprepared"
<jernej>
it's like sunxi_rsb_hw_exit() is called 2 times
<fcas>
uboot over FEL works, I can even share MMC as UMC and write image there using tools on desktop
<fcas>
*UMS
<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)
<fcas>
I even tried armbian and h3droid (both of them can boot orange pi, none can boot my SoM
<jernej>
once you boot U-Boot, you're out of FEL mode
<fcas>
yes, but I can only get out of it sending uboot via sunxi-fel tool
<jernej>
but not from SD card?
<fcas>
no, not from SD card nor MMC2
<fcas>
I burned 4 different images to SD cards, all of them work on orange pi, none of them work on my SoM
<jernej>
do you get any kind of output via UART when booting from SD card? at least something from SPL?
<fcas>
if I send uboot via sunxi-fel, I can use ext4ls and fatls to see that the files are there
<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
<jernej>
then bootrom for some reason doesn't detect SD card at all
<fcas>
neither SD Card nor MMC2
<fcas>
what should I read in SID if the Allwinner H3 is new?
<fcas>
I was expecting 02c00081 00000000 00000000 00000000
<jernej>
did you route SD card & eMMC signals & power supply same way as on OrangePi board?
<fcas>
yes
<jernej>
did you by any chance enable secure boot?
<fcas>
I'm unsure, since I got all Allwinner H3 chips from Aliexpress
<fcas>
can you help me check that?
<fcas>
I tried using md.l 0x01c14248 1 , and got 00000000
<jernej>
ah, I think it's not secured, otherwise it wouldn't boot over FEL
<fcas>
SoM2: 02c00081 14004620 50354224 0824078e
<jernej>
looks ok
<jernej>
fcas: how did you connect UBOOT pin (W6)?
<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
<jernej>
can you leave it floating (internal pull up should do) and test again?
<fcas>
ok, i will try that
<fcas>
didnt work, same behavior
<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
sunshavi has quit [Ping timeout: 480 seconds]
prefixcactus has quit [Ping timeout: 480 seconds]
<machinehum>
jernej: Thanks
<jernej>
fcas: then I'm out of ideas
<fcas>
sadly, me too. Thanks anyway jernej
<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
<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?
<fcas>
yes, that is right gamiee. And the same SD Card can boot a orange pi pc plus (H3 based too)
<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
<gamiee>
But only Uboot pin should impact the boot flow
<gamiee>
Well, did you tried to boot Android image? Or burn one to eMMC via fel?
<fcas>
I tried h2driod image, armbian image, 2 yocto generated images (all of them work on Orange pi pc plus
<fcas>
and shared MMC2 as UMS and burned one image to MMC2 using fel mode + uboot
<gamiee>
I mean stock Allwinner images (h3droid should be it, but hmm)
<gamiee>
Well there is way how to verify its really bootrom / Uboot pin problem
<gamiee>
Do you have exposed SPI pins? (probably SPI0)
<fcas>
I put spi0 and spi1 on headers
<fcas>
with md.l 0x01c00024 1, I could read the status of the uboot pin
<gamiee>
I would try mount SPI Flash to SPI0, and burn u-boot into it.
cmeerw has quit [Remote host closed the connection]
<fcas>
and could verify that it follows the external circuit
cmeerw has joined #linux-sunxi
<gamiee>
SPI is simple, so you can even check if bootrom will try to read it (with signal analyzer)
hlauer has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
fcas has quit [Quit: Page closed]
vagrantc has quit [Quit: leaving]
arnd has quit [Remote host closed the connection]
lvrp16 has quit [Remote host closed the connection]
lvrp16 has joined #linux-sunxi
arnd has joined #linux-sunxi
cmeerw has quit [Ping timeout: 480 seconds]
choozy has quit [Remote host closed the connection]
hlauer has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
Daanct12 has quit [Remote host closed the connection]