<adjtm>
smaeul, thanks, how is the rv 86 panel powered?
<adjtm>
I think that I undertand: usb 5v or 12v with the ethernet/power cable...
<adjtm>
I don't see the device tree in the github d1-wip branch, which repository are you pushing d1 changes to?
apritzel has quit [Ping timeout: 480 seconds]
sunshavi has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
cnxsoft has joined #linux-sunxi
sunshavi has joined #linux-sunxi
sunshavi has quit [Ping timeout: 480 seconds]
<smaeul>
adjtm: right, the 5V input can go to one of the headers exposing SYS_5V, or to any of the Type-C ports. So I am powering mine via the debug UART Type-C port.
<smaeul>
adjtm: the devicetree is in the U-Boot repo. I didn't bother adding it to the Linux repo, since it is the same contents either way.
<smaeul>
and since the devicetree gets patched by the firmware at runtime, I'm trying to encourage using the firmware's devicetree from RAM, and not loading a replacement from /boot
ftg has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
gnarface has quit [Quit: Leaving]
gnarface has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<bauen1>
smaeul: interesting, so they actually included it but didn't document it anywhere, seems about right for allwinner ...
<bauen1>
smaeul: perhaphs i will have some fun reverese engineering that sbrom then
<montjoie>
ok it seems to work, I successfully deployed a new uboot
<smaeul>
montjoie: yes, the wiki is still up to date
<montjoie>
my only problem is now DTB as my CI expect a DTB....
<montjoie>
smaeul: could you confirm what addresses do you use for loading kernel ? Mine are reoboting just after starting kernel
<smaeul>
$kernel_addr_r
<montjoie>
ok so 0x40040000
<smaeul>
my entire script is: load mmc 0:1 $kernel_addr_r boot/Image; booti $kernel_addr_r - $fdtcontroladdr
<smaeul>
usually the easiest way to debug is with earlycon=sbi
<montjoie>
smaeul: does the fact I provide DTB from linux source at $fdt_addr_r could be the problem ?
<montjoie>
ok my problem is INITRD: 0x41d8e000+0x01072000 is not a memory region - disabling initrd
<smaeul>
montjoie: yes. the board will not boot if you load a DTB from a file
<montjoie>
why ?
<smaeul>
the /memory node gets added by boot0, and U-Boot doesn't copy it to a DTB loaded later
<smaeul>
(and the OpenSBI memory reservation gets added by OpenSBI)
<montjoie>
so can I have a way to change dtb ? directly in uboot ?
<apritzel>
montjoie: for small changes try: fdt addr $fdtcontroladdr; fdt set ...
<apritzel>
for bigger changes you would need to copy the DTB first: => cp $fdtcontroladdr $fdt_control_addr 0x10000
<montjoie>
thanks, I skipped the dtb load via tftp and now it boots
<apritzel>
(of course I meant: => cp $fdtcontroladdr $fdt_addr_r 0x10000)
JohnDoe_71Rus has joined #linux-sunxi
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
vagrantc has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
bauen1_ has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
prefixcactus has quit [Ping timeout: 480 seconds]
tnovotny has quit [Quit: Leaving]
mirko has joined #linux-sunxi
<mirko>
gnah and yay: reactivated my opi3 and ethernet just didn't want to work. Infamous "mdio_bus stmmac-0: MDIO device at address 1 is missing.". i know that 2 voltage regulators need proper timing, etc. - however nothing helped. and since it was working ones back then but even with the exact checkouts of uboot and kernel it didn't anymore, I even just considered the HW damaged. turns out: i upgraded ATF.
<mirko>
going back to a rev from ~2 years ago, everything's working again with latest master/HEAD of uboot and linux kernel..
prefixcactus has joined #linux-sunxi
<apritzel>
mirko: good that I catch you here, saw your wiki post
<mirko>
hehe
<apritzel>
mirko: so can you just use: $ make ... SUNXI_SETUP_REGULATORS=0
<apritzel>
when building TF-A?
<apritzel>
I explicitly added this flag to help the OPI3
<mirko>
apritzel: i've seen a commit, mom
<jernej>
apritzel: speaking of TF-A and regulators, I have TX6 mini (H6) which doesn't have AXP805 and ATF just hangs after trying to find it
<mirko>
are we talking about 67412e4d7ae3defaac78ef5e351c63e06cfd907a within atf.git?
<apritzel>
yes, that's the one
<apritzel>
but it's default 1, so keeping the current behaviour, since otherwise we would break most other boards
<mirko>
I did see that one, and tried 67412e4d and 67412e4d~1
<mirko>
both /i believe/ with the same result
<mirko>
however if you wanna know, i can try again and tell for sure
<apritzel>
so you have to explicitly set this on make command line
<apritzel>
otherwise nothing will change
ftg has joined #linux-sunxi
<mirko>
ah, shoot - i see that from the commit now.. only read the message before and figured it automagically fixes the situation
<mirko>
well, apparently i didn't even read the commit msg properly, as it perfectly says SUNXI_SETUP_REGULATORS needs to be set to 0
<apritzel>
yeah, I dislike this being an explicit build feature for a single board as well, but we didn't find a better solution
<mirko>
will try and adjust the bullet point in the wiki accordingly
<apritzel>
eventually, when U-Boot learns setting up the PMIC itself, this =0 will become the default
<apritzel>
mirko: but you also mention mainline Linux: I still don't see Ethernet nodes in the DT, so it wouldn't work with mainline anyway?
<apritzel>
so I guess you mean: mainline with some patches from somewhere?
<mirko>
apritzel: i have some patches from libreelec applied - didn't think they would affect ethernet, but it seems they do
<mirko>
looking good with atf:master/HEAD and SUNXI_SETUP_REGULATORS=0
<mirko>
apritzel: v2.2 works without any mods, because i entirely doesn't yet have functionality for setting up regulators?
<apritzel>
mirko: I think we just didn't list aldo2 back then
<apritzel>
jernej: can you build with DEBUG=1 ;-) and check how far it comes?
<apritzel>
jernej: are the RSB pins connected to something else?
<apritzel>
there are some many steps in the PMIC bringup, I was hoping "no PMIC" would fail gracefully at at least one of them
<mirko>
i also had multichannel/surround sound working via HDMI on H6 already back then - currently not getting my amp recognised anything else than 2.0. using pulseaudio on top of alsa. any hint?
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
<mirko>
ah, pulse audio profile not being picked up, despite its name matching the card identifier.. anyway, forced it now being the default and things are working a again
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
<jernej>
apritzel: I did and it's the same as before
<jernej>
after trying to probe AXP805, next line is just "E:"
<jernej>
apritzel: commenting out sunxi_pmic_setup() helps - boot continues normally
<jernej>
I plan to do some debugging today, because reset also doesn't work
<jernej>
apritzel: this is all I get https://pastebin.com/raw/12FNBXYh with U-Boot v2022.01 and TF-A fdbbd59e9784 (yesterday's master)
<jernej>
and DEBUG=1 of course
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #linux-sunxi
sunshavi has quit []
sunshavi has joined #linux-sunxi
<ndufresne>
jernej: its a secret E..., E for ERROR I suppose
<jernej>
sure
sunshavi has quit [Ping timeout: 480 seconds]
<apritzel>
jernej: interesting, thanks!
sunshavi has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
the next ERROR message would be the timeout from drivers/allwinner/sunxi_rsb.c:rsb_wait_bit()
JohnDoe_71Rus has quit []
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
<apritzel>
but I still scratch my head why it would stop there
sunshavi has quit [Ping timeout: 480 seconds]
sunshavi has joined #linux-sunxi
<jernej>
apritzel: if I comment out rsb_* functions, it continues
<apritzel>
jernej: yeah, indeed, not sure why we didn't do this before
<apritzel>
mirko: thanks for the wiki update!
<mirko>
sure, thank you guys for all your great and still ongoing work!
<blathijs>
Anyone here familiar with the H3 I2S/PCM hardware? I'm a bit confused about whether it can or cannot generate MCK. The datasheet is mostly confusing: the pinout lists the generic PCM_CLK in one place and PCM_BCLK in another place, while the PCM section suggests that PCMx_CLK is MCLK, but then the following diagram only shows BCLK external, and shows an MCLK that stays internal
<blathijs>
(but I wouldn't know where it is routed to then, AFAICS the I2S module, lacking ADCs or DACs, does not really need an MCLK itself?). Then the register reference does show an MCLKO_EN to enable MCLK output (but to where, then?) and you can configure the BCLK and MCLK dividers separately. I'm afraid the datasheet is just wrong in places and/or copy-pasted together from e.g. the H5
<blathijs>
which does have PCMx_MCLK in the pin map, but still... Note that the DAC I'm looking at requires MCLK but has BCLK optional, so I would be happy if I could get MCLK *instead of* BCLK...
<jernej>
smaeul: crust fails to reboot H6 board (tx6 mini), but reboot works without crust
<jernej>
sadly I can't get any useful crust output on uart, it stops at "[ 35.300833] reboot: Restarting system"
<smaeul>
maybe R_TWD is broken on some H6 like the main watchdog
<jernej>
smaeul: why would reset via TF-A work then?
<smaeul>
it uses R_WDOG
<smaeul>
I wouldn't expect any UART output because there is no logging in those states (without a PMIC, there are no device core messages)
<jernej>
TWD is trusted watchdog?
<smaeul>
right
<jernej>
can I easily make hack to use R_WDG?
<smaeul>
sure, replace the call to watchdog_set_timeout() with a MMIO write and a udelay(1000000)
<smaeul>
the TWD is nice because its timeout is in clock cycles, so it makes rebooting 0.499999 seconds faster than using the other watchdogs :)
<jernej>
what MMIO write?
<smaeul>
equivalent to sunxi_system_reset from TF-A: #include <mmio.h>; #include <platform/devices.h>; mmio_write_32(DEV_R_WDOG + 0x0014, 1); mmio_write_32(DEV_R_WDOG + 0x0018, 1);
<jernej>
smaeul: sorry to bother you, but it works now that I used release version of TF-A v2.4
<jernej>
maybe debug overflowed over crust?
<smaeul>
hmm, that shouldn't be possible. that's why we set BL31_LIMIT
<smaeul>
I suppose it's possible for TF-A and crust to collide, depending on the offset within the MMC sector, since SPL reads whole sectors and then shifts the binary down
<smaeul>
but only if crust was read first, then TF-A... and crust's entry point is the very beginning of the binary, so if TF-A overwrote that, crust wouldn't work at all (e.g. you wouldn't get SMP)