ftg has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
<apritzel>
loki666: if you just drop "dump_stack();" in the GPU pd driver's sun50i_h6_ppu_pd_set_power() function, you should see where the requests are coming from
apritzel has quit [Ping timeout: 480 seconds]
radxanaoki has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
cnxsoft has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
dsimic is now known as Guest11077
dsimic has joined #linux-sunxi
Guest11077 has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.5.2]
Daanct12 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
Robot_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
Robot_ has quit [Ping timeout: 480 seconds]
warpme has quit []
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
Robot_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme has quit []
<loki666>
apritzel: thanks it seems the pd power off is comming from the core gendpd
<loki666>
probably because GPU went idle
<loki666>
there are two sets of callback in panfrost, a set for system suspend/resume and a set for the device dynmic pm suspend/resume
<loki666>
trying to hack the runtime
<loki666>
but I'm wondering if the arm bifrost driver is even trying to do runtim pm
warpme has joined #linux-sunxi
Daaanct12 has joined #linux-sunxi
Daanct12 has quit [Read error: Connection reset by peer]
<apritzel>
if that doesn't work, it's probably worth to check the rest of the file for differences
system64 has joined #linux-sunxi
<loki666>
apritzel: got it !
<loki666>
cleaning up patch
<system64>
Hello! I've got an H700 device (Anbernic RG35xx SP) running mainline linux (6.13.5) with a few patches from the rocknix cfw's repo, I'm trying to get a general linux distro working on this and the last thing that i'm missing right now is audio, I've copied over the alsa UCM files and the audio device shows up fine in /proc/asound/cards and pavucontrol but i can't seem to play audio? Any help would be appreciated
<apritzel>
system64: is the playback failing with an error or do you just not hear anything?
<loki666>
system64: you might need to tweak some mixer settings, don't remember exectly which one... try to play with the switch/volumes in alsamixer
<system64>
I get aplay: main:850: audio open error: Host is down, Audio works fine in rocknix, I've tried reaching out to them to understand how they did it but i basically got told off.. (I don't use discord and they didn't want to provide support in github issues)
<system64>
alsa mixer says: cannot open mixer: Host is down
<loki666>
well all the patches are in ROCKNIX, maybe you missed one...
<loki666>
did you enable the KConfig ?
<system64>
I cloned the repo, cloned the specific version of linux used there, Applied the patches, copied the kernel config from rocknix, built it, copied alsa ucm stuff (the config and hifi thing) then booted
<system64>
Any specific config i should look for?
<loki666>
alsa ucm is not strickly required i think, it's mostly to handle switch between hp and speaker properly
<system64>
Yeah it acted the same with/out the alsa configs, Still thought i should have it just in case
<apritzel>
system64: is there something in dmesg that suggests something is failing during boot?
<loki666>
not that I can think of, audio is already mainlined, only the headphone detection is not yet
<system64>
Nope dmesg makes no mention of anything audio related that's failed, all looks good
ity has quit [Quit: WeeChat 4.5.1]
ity has joined #linux-sunxi
<system64>
To be clear i've tried the same config used in rocknix (6.12) and that also didn't have audio working when booted externally (On another distro (ARMtix if that matters)), Anything i can test or debug as a sanity check? any specific modules i should look for?
<system64>
I'm like pretty sure i'm missing something somewhere when initializing the audio stack, probably..?
<system64>
If i start pipewire & wireplumber up and do things as a regular user (non root) then aplay tries to play but i can't hear anything and aplay seems to be stuck, same with any other media player
<jernej>
loki666: by "got it" you mean you fixed gpu pd issue?
<loki666>
Yes it's working by doing the clock/reset dance in the runtime callbacks
<loki666>
I'll add the reset bit flag and post my patch here for discussion later today
<loki666>
Still need to check if the order matter in _init/fini
<jernej>
great, I almost pulled things together to start poking around, but I'm glad that you solved it beforehand :)
warpme has quit []
<kuba2k2>
apritzel: I noticed that auto_scan_dram_size() incorrectly detected 128M instead of 64M, copying this function from SyterKit fixed the issue :)
<apritzel>
kuba2k2: jernej had quite some success with fixing wrong size detection lately, for other SoCs, I guess we should rather copy from there
<kuba2k2>
but I don't know what exactly caused it. I also copied the mr0/1/2, tpr0/1/2 parameters from boot0 because they were different in Samuel's driver (in fact, TPR0 was hardcoded instead of using the CONFIG_ value)
<kuba2k2>
there are like three different "WIP" u-boot repos for D1/D1s right now, and none of it is mainlined anyway. So I only needed something that works. Keeping a local patch will be fine for my usecase
<jernej>
apritzel: looking at H6 code, fixes are needed there too. So soon after patches are merged, I plan to extract the code and use it for H6 and later on A523 too.
<jernej>
kuba2k2: can you link DRAM driver source?
<kuba2k2>
this is the "fixed" driver that at goes past the SPL at least, on F133-B
warpme has joined #linux-sunxi
<apritzel>
kuba2k2: what's in smaeul's WIP branch seems to be mainline with a very small RISC-V twist, but your post has quite some changes. Some are just debug nature, but many others are not
<jernej>
hm... this driver is pretty different than others that we have
<kuba2k2>
I only modified the auto_scan_dram_size() function and the dram_para, nothing else
<kuba2k2>
ah, nice! this does still need the other D1/risc-v patches from d1-wip, doesn't it?
<smaeul>
yeah, this just replaces the DRAM controller driver patches
<smaeul>
and you still need to update the DRAM parameters -- this is where I got stuck, refactoring CONFIG_DRAM_CLK and CONFIG_DRAM_ZQ to not depend on ARM
<smaeul>
(I _also_ have a branch somewhere that moves all of the DRAM drivers to drivers/ram/sunxi to do this, but hit some design error there and didn't finish it)
<apritzel>
jernej: which reminds me: we should probably do this ^^^^ for the A523 driver: have it in drivers/ram/sunxi
<jernej>
apritzel: sure, and also go away with struct type registers and use macros instead. There is one struct that already doesn't make much more sense.
<apritzel>
as you probably know: I am all for that! ;-)
<jernej>
and what I've learned from hacking DDR4 on H616, dram controller struct should be 1/4 of the size. There are actually 4 sets of same registers.
<jernej>
which, except rare exceptions, are used only for DDR4
<kuba2k2>
smaeul: before I try this - do you think it could be the reason why OpenSBI gets stuck? or have you perhaps had success with getting it working with mainline repos?
<kuba2k2>
(mainline-ish, I mean non-BSP, such as yours d1 u-boot and mainline opensbi with generic platform)
ftg has joined #linux-sunxi
<system64>
loki666 I've been fiddling with this for a bit and i've gotten basically nowhere, Using the 6.12 kernel from rocknix to boot my other rootfs i log into the root account, Start pipewire with the root runtime dir and dbus session bus addr set, start wireplumber, play audio via mpg123 or aplay, It *says* it's playing but i don't hear anything from the speakers nor do i feel like it's working..
<system64>
Doing the exact same steps in rocknix yields working sound.. What am i doing wrong? Same kernel, Same configs, Same everything basically, Just diff rootfs
<system64>
And i know that my regular audio setup works on this because i've tested BT audio and it works fine so it's not that.. Is audio this fiddly on H616/618/700?
<system64>
Could someone kindly point me to a regular rootfs for H700 that i can reference? Unless any H616 rootfs would work, In that case i can just use orange pi's rootfs
<apritzel>
system64: if you just don't hear anything, it's really worth to check the mixer controls, as loki666 said. I dimly remember having to set like three controls for the sound to be audible
<apritzel>
system64: I could play sound on a very minimal busybox based rootfs, with some very simple statically compiled player and mixer tools
<system64>
The mixer stuff is the same as rocknix..
<system64>
Could you provide me said minimal busybox rootfs? i need to sanity check this..
<kuba2k2>
kuba2k2: actually nevermind, U-Boot was missing the CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x43e00000 line, it now boots just fine into u-boot :)
<apritzel>
system64: can do, but only in a few hours
<system64>
Sure take your time, It's getting late for me anyways so i'll check it when i wake up, I don't use irc so in case my pc disconnects for whatever reason just shoot me an email (system64fumo@protonmail.com), thank you and sorry for troubling you..
vagrantc has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
ungeskriptet_ has joined #linux-sunxi
ungeskriptet__ has joined #linux-sunxi
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet_ has quit [Ping timeout: 480 seconds]
<loki666>
jernej: you there to discuss about the gpu patch
<jernej>
loki666: ideally, patch should be combined with dt bindings and possible other patches that are needed, namely PPU. Also, it should be split in two, one for new flags and other for adding AW compatible and quirks. Last but not least, run checkpatch.pl --strict on them before sending.
<loki666>
since apritzel posted PPU patch... how do we proceed, I'm fine with taking the panfrost bits in its PPU patch serie, or the other way around
<apritzel>
jernej: RobH took the DT binding patch that adds the H616 Mali compatible string already (in his tree, I think)
<jernej>
ah, then it can be added separately
<apritzel>
loki666: and I think you can pitch it less as a quirk or hack, I really think it's more a deficiency of panfrost. I even wonder if this can be applied more universally
<loki666>
Ok I'll split the patch work on cover tomorrow
<apritzel>
loki666: you can cherry-pick the binding patch into your branch, but don't create an email for it. Then use --base with format-patch, that should put the patch ID (not commit ID) into the cover-letter
<sdfgsdfs>
the new revision of instructions are contradictory and can't possibly work. they direct you to overwrite partition data, placing uboot with the spl in a strange place, presumably for EFI booting. but sunxi doesn't have EFI firmware, the bootrom has the eGON loader
<sdfgsdfs>
also, the resulting uboot image from following that totals to 767 KB, which is too large for the 32k SPL limit and the 512k uboot limit
<apritzel>
sdfgsdfs: it might surprise you, but that looks actually correct
<sdfgsdfs>
wha
<sdfgsdfs>
can you help me unpack misconceptions, then?
<apritzel>
modern Allwinner SoCs (since the H3) can also be loaded from 128KB, the BROM checks that location if it doesn't find an eGON signature at 8KB
<apritzel>
that is indeed to not collide with a GPT partition table
<sdfgsdfs>
so the H5 (which should be A64 since it's based on Cortex-A53) should work doing that?!?
<apritzel>
EFI (even though loosely connected to the GPT) is an orthogonal thing then
<sdfgsdfs>
also another thing
<apritzel>
U-Boot implements the UEFI spec, and is able to execute UEFI apps, like grub, or the FreeBSD loader
<sdfgsdfs>
why does mkimage -l tell me that my uboot is "truncated" and only gives information about the SPL??
<apritzel>
because mkimage only checks for the first instance of image formats it knows about, then stops
<apritzel>
regarding limits: starting with the H6 (so not the H5, I think) the BROM can load more than 32KB into SRAM
<sdfgsdfs>
i am doing an H616 next
<apritzel>
and there is no real 512KB limit for U-Boot. There was some arbitrary limit in the past, but we lifted this years ago
<apritzel>
sdfgsdfs: FreeBSD? I was looking into that (clocks + pinctrl) as a procrastination project
<sdfgsdfs>
BTW, somebody from #uboot told me to talk to andre przywara who is supposed to be the sunxi uboot maintainer
<apritzel>
speaking ;-)
<sdfgsdfs>
:O
<sdfgsdfs>
nice work !
<apritzel>
sdfgsdfs: so do you have any H616 FreeBSD code yet?
<sdfgsdfs>
no, i wanna do this one first
<sdfgsdfs>
which is theoretically fully working
<apritzel>
I tested the FreeBSD installer with U-Boot's UEFI implementation years ago, and that seemed to work, as far as the UEFI bits are concerned
<sdfgsdfs>
actually to be honest I never got a known good Linux image working on the H616 board
<apritzel>
sdfgsdfs: which board, exactly?
<sdfgsdfs>
it wouldn't print out anything to console until it was done booting, so i was trying to debug earlyprintk console
<sdfgsdfs>
orangepi zero 3
<sdfgsdfs>
but I couldn't find any issue with the devicetree chosen params
<apritzel>
there is no earlyprintk on arm64, only earlycon. You would just need to say "earlycon" on the Linux command line, and it should pick the right console from stdout-path in the DT
<sdfgsdfs>
i gotta get back to you about this
<apritzel>
I am not in business of making images, but OPi Zero3 should be working well: upstream U-Boot, mainline kernel, any aarch64 userland
<sdfgsdfs>
yeah it shipped with some hacked together Android image on the on-board spi nor rom
<sdfgsdfs>
i wanna get mainline everything running on it
<apritzel>
yeah, eek, remove that crap ...
<apritzel>
should be straight-forward to flash mainline U-Boot to the SPI flash
<sdfgsdfs>
btw, maybe it's just me, but I found linux's command line docs to be confusing
<sdfgsdfs>
it was never really clear which parameters applied to which architectures
<sdfgsdfs>
which pushes me to read code instead which is its own nightmare
<apritzel>
you can write to the SPI flash using sunxi-fel, no need to boot anything beforehand. In your case you just need to erase the SPI flash first, or sabotage it to not load the vendor code
<sdfgsdfs>
i gave up on the orangepi a while ago, but i think i might've tried messing around with earlycon as well, now i regret not keeping track of what i attempted
<apritzel>
in general you should not need to mess much with the Linux command line, it's really mostly for debugging and special quirks
<sdfgsdfs>
yeah fel mode is nice, not strictly necessary for me since i have physical access to the rom
<sdfgsdfs>
i've been reprogramming things with a ch341a