13:56 <macromorgan> yay, I'm not seeing any major regressions for the PX30 in the 5.16 kernel (5.15 and 5.14 both broke the DSI panel while in RC status)!

14:08 <macc24> macromorgan: o/

14:11 <mort> macromorgan: you're playing with a px30? I have one of those too which I would reeeeally like to be on a newer kernel than rockchip's official 4.4 kernel

14:11 <macc24> mort: odroid go advance/super?

14:11 <mort> nah, this is some custom board

14:12 <macc24> 21th december i'll make a release for rk3326 handhelds that uses a kernel with more-or-less complete hardware support

14:12 <mort> ...which, yes, does provide challenges when there are kernel patches to add support for other pieces of hardware on the board

14:12 <macc24> EXCEPT esp8089

14:13 <mort> how big are the differences between the rk3326 and the px30?

14:14 <macc24> one missing vop and frequency

14:28 <robmur01> also missing ethernet IIRC

14:32 <macc24> right

14:33 <macc24> arch/arm64/boot/dts/rockchip/rk3326.dtsi

14:33 <macc24> i don't see it disabled there

14:33 <macc24> s/disabled/deleted/

14:37 <robmur01> feel free to send a patch ;)

14:43 <macc24> not my job™

14:44 <mmind00> macc24: there is always the "patches welcome" mantra :-P

14:58 <mmind00> interesting rk3326 really doesn't seem to have ethernet - never realized that

15:01 <macc24> mmind00: ever seen rk3326 device with ethernet? :{

15:01 <macc24> :P

15:01 <mmind00> macc24: the only rk3326-device I have is that Odroid Go ;-)

15:01 <macc24> mmind00: well i mean... *looks at her rk3326 devices* those seem popular

15:02 <mmind00> :-D

15:05 <mort> you could presumably find (or at least make) an rk3336 device with ethernet

15:05 <mort> I mean the raspberry pi had ethernet well before they used a soc with ethernet support

15:20 <mmind00> mort: the point here was that the px30 does have a gmac controller on the soc, where its rk3326 cousin does not

15:20 <mmind00> mort: with my just now realizing that this is another of the differences they have

16:25 <dvergatal> mmind00: i have 3.15.0 up and running

16:25 <mmind00> dvergatal: hee, congrats

16:25 <dvergatal> mmind00: guess what was the proble? you won't believe it

16:25 <dvergatal> problem*

16:26 <dvergatal> u-boot 2022.1-r2

16:26 <dvergatal> i have switched to 2020.1 and everything is ok and turned off ASNR in OPTEE

16:26 <dvergatal> something wrong is with the serial

16:28 <dvergatal> in newest u-boot because i'm using uart for debbuging my rk3399 board and the outpu sometimes was and sometimes not it was really random

16:29 <dvergatal> mmind00: thx

16:35 <dvergatal> btw. i wonder is it the problem with make_fit_atf.py script or with the uboot itself

16:36 <dvergatal> because there are two changes between master and 2020.1 tag yours and Heinrich

16:37 <dvergatal> i need to investigate it

17:13 <as2334> I completely erased the nand flash of my rk3126 device but rkdeveloptool still lists it as "loader" - does that make sense?

17:23 <robmur01> IIRC if you do an "erase" from the USB tools it refuses to actually touch the loader

17:24 <robmur01> same way you can't just flash it directly and have to faff around with the "ul" command and packing images with magic headers

18:13 <as2334> robmur01 ahh, that sounds possible. So the write-lba and read-lba functions are somehow lying? Because the flash reads as empty. On a related note, I haven't been able to find the IDBlock (the 512 bytes rc4 encrypted chunk that the boot rom supposedly searches for in flash/sd/spi)

18:15 <as2334> (and eMMC)

18:17 <robmur01> indeed - http://opensource.rock-chips.com/wiki_Rockusb#Miniloader_Rockusb.C2.A0mode

18:23 <as2334> robmur01 thanks, have to take a look at that, although I've found their docs to be somewhat cryptic

18:25 <robmur01> key point being that sometimes "0" is actually 0x2000

18:27 <robmur01> once your setup gets to the point where you can reliably "recover" as far as booting to U-Boot with UMS or Linux with dd, life gets easier :)

19:03 <as2334> robmur01 ah, I have to try that. I tried to run boot code that I put at sectors 0 and 64 of the flash and it didn't work. I managed to get into maskrom mode by shorting the CE of the flash chip, but then reading/writing to flash didn't work (yes I did remove the short after it booted). I didn't experiment too much with that cause I think I'm likely to fry the nand chip.

19:21 <robmur01> yeah, if you have to work with the miniloader and downstream U-Boot, I reckon on-board eMMC/NAND is safest either completely blank, or with just the loader and a U-Boot SPL configured to prefer loading 2nd-stage U-Boot from SD (AFAIK the downstream configs do tend to default to that, at least that's what I remember from my earliest adventures with RK3288)

19:27 <robmur01> oh, the cycle of "short eMMC pins to get back to maskrom, reflash vendor Android image to get usable U-Boot and kernel back, reboot, re-copy and dd upstream U-Boot image, reboot again and hope..." :)

19:27 <as2334> robmur01 just to see if got this right. If the board is in "loader" mode that means the bootrom is running firmware it read off the nand flash, although even though the nand flash appears empty.

19:32 <robmur01> yup, AFAIK if it's not in maskrom mode, then it presumably must have found enough of the idbloader and U-Boot to run and get into rockusb mode, at which point it tends to do the sneaky offset trick to prevent itself being replaced without a properly packed "firmware" image

19:33 <as2334> ahhh ok

19:33 <as2334> so now I have something new to test. Thanks a lot =)