01:48 <MoeIcenowy> swiftgeek: of course I have the shit T-head PDF

01:49 <MoeIcenowy> want me to mail you?

01:49 <swiftgeek> got it from sb else already, thanks :D

01:50 <swiftgeek> unless there is an _en variant ;D

01:51 <MoeIcenowy> apritzel: sounds interesting that it's worth try

01:58 <MoeIcenowy> smaeul: is it possible to just implement these instructions with basical instructions in RV to make a Xthead-less binary?

02:06 <MoeIcenowy> apritzel: does `b 0x67` mean branch to 0x1a4 aka ((0x67 + 2) * 0x4) ?

02:07 <MoeIcenowy> ooops jalr x0, 0xea0(x0) is jumping to absolute address 0xea0

02:07 <MoeIcenowy> which is inside BROM

02:09 <smaeul> MoeIcenowy: yes, but you would have to figure out the register allocation. it would probably be easier to decompile the Xthead version to C and recompile from there

02:19 <MoeIcenowy> maybe we can consider compressed instruction set?

02:19 <MoeIcenowy> then we can put 2 instructions in 4 bytes

02:20 <MoeIcenowy> and 0xea00 is `sd      s0,16(a2)` (well, if the other part is a jump, this shouldn't get executed at all)

02:22 <cyrozap> MoeIcenowy: What are you trying to do? If you just want to be able to run the binary on a different chip that doesn't support the instructions, you could add an illegal instruction handler so those instructions can be emulated by software when the CPU tries executing them.

02:23 <MoeIcenowy> although the RVC C.J instruction is 0xa001 | imm

02:24 <MoeIcenowy> thus considering the ARM b does *4, it's then spreaded to a very high location

02:25 <cyrozap> Or, if you really need to edit the instruction in-place, you can replace it with a jump-with-link to a subroutine that performs the same function with standard instructions.

13:39 <warpme_> can't find what is missing. Is there any 2nd pair of eyes wiling to look on problem with me?

13:39 <warpme_> guys: i'm hacking with getting working crust on 5.13-rc6 kernel (i'm adapting LE crust kernel patches to 5.13 kernel) and got it working. Only thing not 100% working are DT changes. Porting 5.12 crust DT changes (h6.dtsi + box .dts) to 5.13 makes box non-booting. But porting 5.12 crust .dts changes to 5.13 & using in 5.13 h6.dtsi from 5.12 gives working crust on 5.13 but with DT warnings. Definitely i miss something - but

13:44 <obbardc> orangepi pc2 booting from spiflash hangs at "Trying to boot from sunxi SPI" with uboot 2021.04 and latest HEAD, any tips ?

13:45 <smaeul> warpme_: I pushed the crust and crust-minimal branches rebased on 5.13-rc1. hopefully that helps. some of the patches were merged during 5.13

13:46 <warpme_> oh great!

13:55 <warpme_> smaeul: hmm - so after looking on your code i see some things are unclear for me. to get box booting with crust working on 5.13 i'm using this patch on h6.dtsi: https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-5.13/files/0552-arm64-dts-ARM-dts-allwinnerh6-enable-crust.patch For sure this patch is not fully correct! iirc L81 was very suspicious as without it (iirc) box is not-booting. Maybe you have some

13:55 <warpme_> hints here?

13:56 <warpme_> there is some junk in this patch so pls don't shut me. it is just wip

14:03 <apritzel> obbardc: when was this last time working for you? 2021.01?

14:03 <obbardc> apritzel: untested yet, i will try an older build

14:03 <jernej> smaeul: are "PM / devfreq" patches in your crust branch just cleanup or they help with something on sunxi platform?

14:04 <apritzel> obbardc: I will have a closer look tonight (unless you beat me to it), thanks for the heads up anyway

14:04 <jernej> ah, I guess it's for mbus driver

14:06 <obbardc> apritzel: 2020.07 broken, maybe its how i am flashing. sunxi-fel -p spiflash-write 0 u-boot-sunxi-with-spl.bin

14:08 <warpme_> smaeul: ok. pls not waste your time on my patch. i'll go with all your patches on 5.13 and will report how it goes. thx for rebasing your nice work on 5.13!

14:08 <apritzel> obbardc: if 2020.01 works, but 2020.04 doesn't, then it's me to blame ;-)

14:12 <jernej> smaeul: does mbus driver bring some performance improvements or just power savings?

14:23 <obbardc> apritzel: 2020.01 doesnt work, so i don't think you are to blame :p

14:24 <apritzel> obbardc: how do you populate the flash?

14:25 <obbardc> literally just flash directly using: "sunxi-fel -p spiflash-write 0 u-boot-sunxi-with-spl.bin"

14:26 <apritzel> right, that's the best working option

14:26 <apritzel> (even though a bit cumbersome, since it requires FEL)

14:27 <apritzel> obbardc: does that same image work from an SD card?

14:27 <apritzel> (because that message would be the last to see if Trusted-Firmware was missing or wrong as well)

14:28 <warpme_> guys: quick q: dmesg on h616 no matter what not shows me anything about mmc2 (wifi). Is this possible because wifi chip not receiving power so mmc2 will not appear on dmesg?

14:30 <apritzel> warpme_: do you have the WiFi in your DT? And also the number in mmc<x> can vary across boots

14:30 <obbardc> apritzel: looks like you are right, with SD card it hangs at "Trying to boot from MMC1", ATF is HEAD from https://github.com/ARM-software/arm-trusted-firmware

14:34 <warpme_> apritzel: re dt: yes. and indeed mmc numbering isn't consistent (i'm talking about 3rd mmc; 1st is boot. 2nd is eMMC) in dmesg i see mmc with SD card, mmc with eMMC and that's all. no 3rd mmc device. trying understand: is this because dt wifi fragment is wrong or is this because issue is within kernel....

14:38 <apritzel> obbardc: since you have a working FEL setup: try booting the whole thing via FEL: build latest U-Boot master, then just use "sunxi-fel -v -p uboot u-boot-sunxi-with-spl.bin" (with some recent sunxi-fel version)

14:44 <apritzel> warpme_: I think you should see some attempts from the kernel to bring up the MMC, if the DT node is enabled

14:45 <apritzel> warpme_: but what are you expecting anyways? AFAIK most (if not all?) H616 use this totally unsupported AW WiFi chip?

14:45 <warpme_> exactly. this was also my feeling.... re: aw chip: i already ported it to 5.13 (i mean all kernel api calls so it builds clean).

14:46 <warpme_> but i have also 2nd h616 box with famous xr819 (where we have driver)

14:48 <apritzel> warpme_: you are way too off-tree for my taste (both for the XR819 and the AW859A)

14:51 <warpme_> for sure getting aw chip will be not easy as in code i see they have conditionals to use direct gpio mangling for aw/rk/hisi/aml. but code alternative path seems to mangle with sdio operations quite similar like in other sdio chips so maybe there is chance?. Maybe - at some point in time - somebody in community knowing way better than me sdio will co-work to get aw859a working on mainline?

14:53 <obbardc> apritzel: boot from spi all working fine on u-boot HEAD now; turns out i was using the wrong ATF target ! doh! thanks for the help

14:55 <apritzel> obbardc: happens to me all of the time! ;-) I now use a build.sh which automatically picks the right bl31.bin file

14:55 <warpme_> driver already seems to abstract to hw in quite similar way how rt drivers are doing. somebody good in sdio can read aw-speciffic gpio code and translate it to mainline infra (at least i'm naive enough to imagine this ;-\ )

15:00 <apritzel> warpme_: are you talking about this uwe5622 driver from the BSP?

15:01 <warpme_> yes

15:01 <apritzel> most of those BSP/vendor drivers are complete crap and light years away from being mainlined

15:02 <warpme_> ough....

15:10 <warpme_> smaeul: fyi: 5.13-rc6 with your crust code builds clean & works nicely (so far tested on single h6 box). great work!

15:16 <warpme_> smaeul: fyi2: on gs1 crust (probably?) gives me kernel trap like this: https://pastebin.com/phyfsF48

15:16 <warpme_> i remember i had this also with my crust hacking on 5.13 - so mabye this is gs1 DT issue?

15:18 <warpme_> (infact this trap was exact reason why i poped here with my crust 5.13 hacking topic)

15:45 <jernej> apritzel, smaeul: RSB also uses open-drain driver, right?

15:45 <jernej> not sure why RSB wouldn't work on GS1

15:47 <apritzel> jernej: the manual mentions "supports push-pull bus", not sure what that means exactly, though

15:48 <apritzel> jernej: is there some I2C device on the bus, as on the Pine H64?

15:50 <jernej> apritzel: from what I know, there is no additional devices on the bus and two pull ups are on the SCK and SDA line

15:50 <jernej> so, pretty much same as OPi3, for example

15:51 <karlp> pretty happy with getting only 50usecs back to back from userspace spidev transactions on H3 :) https://bin.jvnv.net/file/CD8pI.png

17:03 <gamiee> karlp: that's amazing!!!

17:04 <karlp> that's python spidev too,

17:05 <karlp> little curious about why CS stays asserted for "a while" after the clock finishes, but, more than sufficient for my use cases

17:07 <tuxd3v> hello guys , I have i2c0, and i2c2 on gpio SoC H3, if I do a i2cdetect on 2 its ok, but if I do it on 0, it says clobk blocked :/

17:08 <tuxd3v> https://paste.debian.net/hidden/8014493c/

17:08 <tuxd3v> I was looking at sunxi-h3-h5.dtsi, and I don't find what is provoking this..

17:08 <tuxd3v> both i2c signals should be on gpio

17:09 <tuxd3v> mv64xxx: I2C bus locked

17:24 <tuxd3v> what you guys think would be the problem?

17:31 <apritzel> tuxd3v: your usage of "GPIO" is confusing: by definition it's a pin which level can be set by software (bit-banged)

17:31 <apritzel> tuxd3v: which can also be used to drive an I2C bus, "manually"

17:32 <tuxd3v> apritzel, yes the i2c bus works nicely on i2c2, but not on i2c0 :/

17:32 <apritzel> but when you use the I2C controllers in the SoC, which can be connected to certain pins, it's not "GPIO" anymore

17:32 <tuxd3v> I mean the Board GPIO :)

17:32 <tuxd3v> not the pins GPIO :)

17:33 <apritzel> no, you mean the board pins or headers

17:33 <tuxd3v> not the Soc gpio pins :)

17:33 <tuxd3v> apritzel, yes that is another way of saying that :)

17:33 <tuxd3v> but the problem is that i2c0 doesn't work when I try i2cdetect on him :(

17:33 <apritzel> ... a confusing way which you should avoid

17:34 <apritzel> pull ups are something you could try

17:35 <tuxd3v> the board has no pull ups in its design nor i2c0 nor i2c2

17:35 <tuxd3v> but i2c2 works..

17:36 <apritzel> is there something that incluences the I2C0 pins (always pulling low or high)?

17:37 <apritzel> and please double check this, because many boards *have* external pull up resistors on header pins that are meant for I2C

17:37 <tuxd3v> nope everything conected straight to the SoC

17:38 <apritzel> sure, but also to some VCC?

17:38 <tuxd3v> I mean I am only looking for the schematics, maybe my board is some revisions that has, I don't know about that.. they are not in the chematics..

17:39 <apritzel> the pull ups might be separate, on many schematics they just reference the net labels and group pull-ups in one place

17:40 <apritzel> so it's not immediately obvious if you just look at the "CPU" or "connector" page

17:40 <apritzel> and you could just measure it (with the board being off)

17:41 <apritzel> if there are no external pull-ups, you would need to activate the internal ones

17:43 <tuxd3v> ho.. how can I activate i2c0 internal ones?

17:47 <apritzel> try "bias-pull-up;" in the respective pinctrl DT node

17:48 <apritzel> tuxd3v: what board is this?

17:49 <tuxd3v> its nanopi neo air

23:46 <smaeul> jernej_: the mbus devfreq driver is just for power savings

23:51 <smaeul> warpme_: the bug is that you are replacing the mainline sun6i-r irqchip driver with an older version in https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-5.13/files/0551-allwinner-add-crust-support.patch

23:56 <smaeul> the older version had a different binding, so it is not compatible with your device tree