09:03 <apritzel> montjoie: so it worked for me, with the a523-beta branch from my github, and jernej's a523 TF-A branch, on my Radxa v1.1 booted via FEL

14:36 <dlan> hi

14:37 <dlan> I didn't notice that I was able to talk ..

14:37 <dlan> apritzel: montjoie: FYI, you might also be interested in ethernet, I've got EMAC0 up - https://github.com/dlan17/linux/tree/allwinner/A523

14:38 <dlan> s/able/unable/

14:45 <zamon> Sorry, I just want to make sure I can send msg

14:54 <zamon> I had trouble to use sunxi-fel for burning image into broad (t527 orangepi 4A). At U-boot stage, entering command `efex`, I saw message "HELLO! BOOT0 is starting! ..." But at pc side, command `sunxi-fel version’ turned out "ERROR: Allwinner USB FEI device not found!" I am sure I plugged usB to 0TG port on orangepi 4A board. Could any body help? I will be appreciate

14:56 <apritzel> dlan: oh wow, good, so it does indeed work without big changes. Thanks for doing this!

14:59 <apritzel> zamon: why do you want to go via the vendor U-Boot? Can't you just hold down the "BOOT" key, press the "RESET" key briefly, wait for a bit, then release the "BOOT" key. That should enter FEL mode more reliably

15:05 <apritzel> dlan: so for Ethernet it's really just the default syscon value that's different? I never really understood what this was for, can't we just drop this?

15:05 <dlan> zamon: use lsusb to check if FEL usb device recognized

15:05 <apritzel> because then it would work with the existing A64 compatible, on today's kernel

15:05 <dlan> you will like got something like:

15:05 <dlan> Bus 001 Device 123: ID 1f3a:efe8 Allwinner Technology sunxi SoC OTG connector in FEL/flashing mode

15:07 <apritzel> dlan: but then sunxi-fel would also see it, so I guess entering FEL mode didn't work

15:07 <dlan> for default_syscon_value, no, can't drop, it fail to work as I tested

15:07 <jernej> apritzel: yes, that default value should be dropped. Patches welcome :)

15:08 <apritzel> I more meant to drop that whole default syscon value at all

15:08 <dlan> not sure if need to use more recent sunxi-tool from git repo

15:08 <apritzel> jernej: ah, great, will have a look!

15:08 <dlan> zamon: can you check with "fel version" first

15:09 <dlan> apritzel: i haven't spent much to investigate, only check vendor code and adjust to mainline

15:09 <apritzel> dlan: for the SRAM controller: you don't need the changes, you can use the A64 fallback compatible string, as the H6 does (check sun50i-h6.dtsi)

15:10 <dlan> right, I just rush to make it work, to use fallback compatible, need to know a lot history..

15:10 <dlan> actually know their have same IP, but thanks for the hint

15:11 <dlan> apritzel: btw, do you know how to check cpu freq it's currently running? I wasn't sure if it run at decent speed, just feel it's extremely slow..

15:12 <dlan> I assume we can problem some clock?

15:12 <dlan> just wasn't sure which one

15:15 <dlan> apritzel: btw, the eMMC also works on radxa A5E, simply copy & populate the dts node

15:22 <apritzel> dlan: eMMC: interesting, I think I briefly tried that and saw the same issues as on the X96QPro+

15:23 <apritzel> dlan: speed-wise: yes, it's bad, we run at 800 MHz for the first cluster, don't even know what's the default for the second one, might be 408 MHz

15:24 <apritzel> I think junari was working on DVFS, and made some progress there

15:24 <dlan> which issue, I occasionally got weird signal kill

15:25 <dlan> DVFS, that's good, but I wonder it possible to raise speed a little, still fixed & safe rate

15:28 <apritzel> well, for the PMIC DCDC1 reset voltage (0.9V, I think) 792 MHz is the only safe option. But you can raise that in U-Boot (CONFIG_SYS_CLK_FREQ), if you also set CONFIG_AXP_DCDC1_VOLT to a higher value

15:28 <apritzel> dlan: but please double check the names and numbers, you don't want that to become unstable

15:29 <apritzel> or even fry the chip, if VDD_CPU gets too high

15:30 <dlan> aha, right

15:30 <apritzel> dlan: for eMMC: the driver probes and finds the eMMC chip, but then times out or something, don't remember exactly. Definitely the block device is not usable

15:31 <dlan> well, here I have no problem to fully bootup linux system

15:31 <dlan> but not do much test

15:31 <apritzel> that's .. interesting, I definitely wasn't even able to read the partition table, I think

15:32 <dlan> well, may it's kind of picky for eMMC chip

15:33 <zamon> dlan: `lsusb` has no such an output unluckily, and fel version is "sunxi-fel v1.4.2-195". I have tested the method provided by apritzel, but still don't work.

15:34 <dlan> zamon: are you sure connecting to right usb port?

15:35 <apritzel> zamon: something boards can be tricky to get into FEL, especially if serial is connected. So you could try to remove all cables, press and hold the FEL button, connect power, then USB (if not the same cable)

15:35 <apritzel> then check with "sunxi-fel ver"

15:35 <apritzel> if that shows up, you can connect the serial

15:36 <zamon> dlan: Yes, I connected the USB to OTG port on board. Maybe I should better ask orangepi vendor for some suggestion.

15:36 <dlan> orangepi usually provide quite detail usermanual, you can check first

15:39 <zamon> dlan: But I couldn't find the description of FEL part, I will double check it

15:39 <apritzel> I cannot access the schematic at the moment, but it's pretty likely that the USB-C port is the OTG one, so if you hook this up to your host, it should show up

15:39 <apritzel> zamon: look out for USB0 or similar

15:40 <jernej> apritzel: is it possible that h616 emmc fix helped with a523 too?

15:40 <zamon> apritzel: thanks, I'll try

15:41 <apritzel> jernej: pretty sure it did, I think eMMC worked then, but only in U-Boot. I didn't work for me in Linux, and it wouldn't be really relevant anyway, since Linux is using DMA

15:42 <jernej> ah, ok

15:56 <montjoie> apritzel: your branch worked yesterday without change, I will retry more extensively when back home

15:57 <montjoie> dlan: I will test ethernet thanks, I need it to setup my board in kernelCI (for TFTP)

15:58 <montjoie> ah patchs for linux I need it in uboot, but seems simple

15:59 <dlan> let me know if you make tftp work (in uboot)

18:22 <MasterR3C0RD> apritzel, tvc: Busy times IRL is the sole reason momentum dropped for me; haven't had time the last few days to get back into digging around. I might be able to sneak in some time this weekend to take a look at remaining work

18:25 <MasterR3C0RD> There was someone else (parthiban) who was working on bringing up the DE but I haven't seen anything in my inbox since he posted his initial series. GPU isn't really supported by Mesa or mainline drivers yet

18:28 <MasterR3C0RD> I was working off a Sonic Pad, but the regulator setup is strange so I'm cautious about mainlining that in the current state

18:30 <MasterR3C0RD> Trimui Smart Brick uses the A133P; that usually means a second regulator that isn't supported yet by mainline. Also has different OPP tables that need to be added/handled by cpufreq to allow for clocking higher

18:30 <MasterR3C0RD> And last I remember TF-A worked enough to boot but isn't in a state where it can spin up the other cores

18:33 <MasterR3C0RD> Had a series in progress to enable Ethernet and RTC clock control (which would also enable SDIO wifi clocked by fanout, like it is on some XR819 modules, though that requires the out-of-tree xradio driver)

19:01 <jernej> MasterR3C0RD: I have patches for XR819 mainline driver: https://github.com/jernejsk/linux-1/commits/h616-test/

23:03 <Lightsword> anyone know where the PA pins on the h616 are documented in the manual?