ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
<apritzel> tokyovigilante: regarding the U-Boot AXP717 driver: you did report that the AXP717 version check didn't work, do you remember which value the register 0x3 read as?
<apritzel> I am trying to work out if the mask and comparison value were just wrong, or whether the register doesn't actually exist at all
<tokyovigilante> I don't recall, but can check this evening. I couldn't find it in the datasheet, whereas it is mentioned in some of the other AXP chips
<tokyovigilante> Obviously from my driver the call to read that register succeeds, but I never check the value
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
<apritzel> thanks! I wanted to post the two drivers to the U-Boot list
Schimsalabim has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]
paulk has joined #linux-sunxi
paulk-ter has quit [Ping timeout: 480 seconds]
paulk-bis has joined #linux-sunxi
paulk has quit [Ping timeout: 480 seconds]
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
<acmeplus> tokyovigilante: do you get the wifi detected during boot? I've not managed to get it recognized, I compiled rtw88_8821cs driver but there are no traces in dmesg or when I modprobe the module
<acmeplus> here are the dmesg from batocera: https://gist.github.com/acmeplus/d8a989449ed27e23029e5d0a2d7a5847 I know you mentioned you were using fedora13, so maybe that's the reason
<tokyovigilante> detected and working, you need the firmware too, but you should at least see a firmware failed to upload message
<acmeplus> Yeah, that's really puzzled. I was using your repo, so I assumed it should show up in dmesg. I may be missing something in the kernel.
<acmeplus> I've posted my modified dts and dtsi here: but I don't think they add anything at this point. https://gist.github.com/acmeplus/14f5d458ae93242e68aefb8dd4afcbf4
<tokyovigilante> I needed the rfkill modules etc as well, are you sure you've copied all the modules? I like to delete all the old ones too in case you've got stale ones that aren't overwritten
<tokyovigilante> they should be selected automatically when you enable wlan in the kernel config though
<acmeplus> Yeah, I used either my compiled batocera rootfs or the orange pi ubuntu. In both cases I copied al the exported modules to the corresponding folder. I know it's working because panfrost and others are automatically being picked up
<acmeplus> I noticed rfkill module being loaded, but I may be missing another one
<tokyovigilante> you can uncomment the 32mhz pin control in the mmc_pwrseq section if you add the h616 dtsi change I pushed, but that just helped stability, not detection
<acmeplus> Thanks, I'll give it a try
<tokyovigilante> will steal your HDMI bits as well and update the DTS this evening, but what I have in there should give you working wifi if your kernel is ok
<tokyovigilante> will do a kernel config diff as well
apritzel has quit [Ping timeout: 480 seconds]
<acmeplus> Thanks, I will also push my changes to a proper repo so it's easier to compare
<acmeplus> for the hdmi, I get the dw_hdmi, sun8i_drm_hdmi and cec auto loaded, so I guess those are correct
<acmeplus> All those have been merged from the orangepi zero3 as is
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
vagrantc has joined #linux-sunxi
sunshavi has quit [Ping timeout: 480 seconds]
acmeplus has quit [Ping timeout: 480 seconds]
sunshavi has joined #linux-sunxi
sunshavi_ has joined #linux-sunxi
sunshavi has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
NekoMay2 has quit [Ping timeout: 480 seconds]
tolthoff has joined #linux-sunxi
<tolthoff> apritzel: That's nice to hear. As I am totally new to the community, how would one submit a patch?
apritzel has joined #linux-sunxi
acmeplus has joined #linux-sunxi
<tokyovigilante> apritzel: pmic_bus_init: ok
<tokyovigilante> chip version: 0xff, ret = 0
<tokyovigilante> Same result as macromorgan, so may not actually be anything there
<tokyovigilante> Seems to be no downside to just returning 0 though, the subsequent DCDC2/3-setting calls seem fine
<tokyovigilante> DCDC2: writing 0x2c to reg 0x84
<tokyovigilante> DCDC3: writing 0x3c to reg 0x85
<tokyovigilante> i2c_begin send status 0
<tokyovigilante> ptr: 327680
<tokyovigilante> spl_relocate_stack_gd
<tokyovigilante> DRAM: 1024 MiB
<tokyovigilante> ptr: 327248
<tokyovigilante> board_init_r
<tokyovigilante> and so on
acmeplus has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
<tokyovigilante> acmeplus: [ 11.635357] rtw_8821cs mmc2:0001:1: Firmware version 24.11.0, H2C version 12
<tokyovigilante> is the first line I get for wifi
Daanct12 has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
<tokyovigilante> and here's my kernel config diff
warpme has joined #linux-sunxi
acmeplus has joined #linux-sunxi
chewitt has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
NekoMay has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
<tokyovigilante> ok, I'm back to fiddling with DRAM timings, is there any documentation for this at all?
warpme has joined #linux-sunxi
warpme has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
<tokyovigilante> I'm trying to remember how I dumped the timings from the vendor BSP
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
acmeplus has joined #linux-sunxi
<tokyovigilante> Found them from macromorgan's gist... so definitely doesn't like a TPR11 of 0x0, has to be 0x1a1e1e1b
<tokyovigilante> doesn't seem to matter setting TPR6 to either 0x40808080 or 0x42808080
<tokyovigilante> And it will boot with TPR12 either unset or 0x06060706
acmeplus has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
acmeplus has joined #linux-sunxi
NekoMay has quit [Ping timeout: 480 seconds]
acmeplus has quit [Ping timeout: 480 seconds]
NekoMay has joined #linux-sunxi
acmeplus has joined #linux-sunxi
apritzel has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.2.1]
acmeplus has quit [Ping timeout: 480 seconds]
<apritzel> tokyovigilante: there is no documentation about DRAM parameters other than the code
<apritzel> and this code was mostly gained by jernej reverse engineering the BSP code
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<apritzel> tolthoff: you would need a git patch against the current master branch, with a good explanatory commit message and a: Signed-off-by: Your real name <your.email@provider.com>
<tokyovigilante> apritzel: Ok, ta. I've tweaked the params a wee bit and seem to be reliably getting 1GB DRAM reported every boot now (mainly just by re-enabling the TPR12 param and using the alternate TPR6
acmeplus has joined #linux-sunxi
<apritzel> tolthoff: then do: "git format-patch -1", then: "scripts/checkpatch.pl 0001-*.patch" and "scripts/get_maintainer.pl 0001-*.patch"
<tokyovigilante> Have disabled power-saving on the RTL8821 and BT is much more stable, Wifi still fairly slow.
<apritzel> tokyovigilante: fairly slow as in 2MByte/s?
<tokyovigilante> yup
<tolthoff> apritzel: I already send it according to the kernel patch submitting guidelines. Took the corresponding maintainers and list form the file. But thanks a lot for the info. Will refer to this if it happens again.
<apritzel> tolthoff: ah, good to hear, thanks for jumping through the hoops and submitting it!
acmeplus has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
Hypfer has joined #linux-sunxi
acmeplus has joined #linux-sunxi
Hypfer1 has quit [Ping timeout: 480 seconds]
Hypfer is now known as Hypfer1
<tokyovigilante> finally got some action on the SD card front
<tokyovigilante> U-Boot SPL 2024.04-rc3-00021-g62d25bac7a-dirty (Mar 15 2024 - 22:46:23 +1300)
<tokyovigilante> DRAM: 1024 MiB
<tokyovigilante> Trying to boot from MMC1
<tokyovigilante> Interestingly that's at the 8k offset, not 128k (well in both, but only started boot after I put it at 8k, and now it refuses to go to FEL mode with that SD card in on plugging in the USB
<apritzel> tokyovigilante: sure: FEL mode is only entered when there is no other boot source, and since the BROM found the eGON header on the SD card, it started that
acmeplus has quit [Ping timeout: 480 seconds]
<tokyovigilante> yup understood, just curious that it didn't seem to find it at 128k as I had expected
<tokyovigilante> have just erased it at both locations for now, I think macromorgan is further ahead with solving the SD issues, I can't really see that they are DRAM related given I can boot a kernel and run linux off the SD
Daanct12 has quit [Quit: WeeChat 4.2.1]
acmeplus has joined #linux-sunxi
<apritzel> tokyovigilante: can you post the output of "sunxi-fel sid-dump" somewhere? The boot order can be influenced by fuses, though we see this rarely used
Daanct12 has joined #linux-sunxi
<apritzel> tokyovigilante: thanks, though I just realised that the manual doesn't tell the offsets of the registers it mentions
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
tolthoff has quit [Remote host closed the connection]
acmeplus has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest2834
dsimic has joined #linux-sunxi
acmeplus has joined #linux-sunxi
Guest2834 has quit [Ping timeout: 480 seconds]
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
smaeul has quit [Quit: Down for maintenance...]
bauen1 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.2.1]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
bauen1 has joined #linux-sunxi
<acmeplus> tokyovigilante: thanks for the config, the issue is I was using mainline directly and not apritzel's axp717 branch.
acmeplus has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
junari has joined #linux-sunxi
evadot_ has quit [Remote host closed the connection]
evadot has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
<acmeplus> Is there a sunxi_v2 in 6.8.x or does it need to be ported? Audio works on the H700 with sunxi_v2 and sun50iw9-codec from orangepi 6.1.x
<apritzel> acmeplus: oh oh, please rush and wash you hands, since you touched BSP code ...
<acmeplus> ok.... thanks :)
<apritzel> I don't know about this particular code, but typically BSP is "beyond porting"
<apritzel> meaning it's mostly so out of touch with how Linux really works, that all you can do is to extract information from it
<acmeplus> yeah, I can only imagine. I saw that as part of 6.1 in batocera and then I tested and was detected correctly. At least we know the DT is correct
<apritzel> that got better in the recent past, but the H616 BSP is pretty much still in this category
<apritzel> also the BSP DT is wildly wron^Wdifferent most of the time
<apritzel> acmeplus: if you are looking for code that is not yet upstream, go to jernej's repo, that's typically a drawer full of goodies
<acmeplus> Will do
<apritzel> but also be aware that there is typically a reason for something not being upstream
<apritzel> if you are lucky, that's just lack of time, but mostly there are hacks somewhere, that need to be reworked
<acmeplus> Understood, makes sense.
<apritzel> the display engine / HDMI code is in this category: while it may work (TM), it is not ready yet for an upstream submission
<apritzel> also regarding the DT: only devices we got officially accepted DT bindings for can go into a mainline DT
<apritzel> and DT bindings typically go along with the drivers (although they are conceptually independent)
<apritzel> so when you create a DT with graphics nodes in there, this cannot go upstream yet, until we know exactly what we need on the binding side
<acmeplus> Ok. For the audio I don't think there were any major changes. For hdmi and the internal I'm sure there will be some required.
<apritzel> so the initial DT submission would need to be restricted to what's in the tree already (MMC, serial, USB, WiFi, BT)
<acmeplus> changes to DT I mean
<apritzel> Ideally the regulator makes it in this cycle (for 6.10), that means we can submit the basic DT as well (without display & sound)
<apritzel> cut-off date for acceptance is about end of April (typically at v6.9-rc6)
<acmeplus> Sounds good, thanks a lot for the insight. learning new things :) I always stay with old legacy kernels to try to get these devices to work, but definitely mainline is the way to go
<apritzel> unfortunately those vendor kernels are really awful, and IMHO playing around with them takes away resources (time&people) from mainline work
<acmeplus> Side question, what's the status for A133 devices? I have a couple of them in my drawer and was just wondering how well that soc is supported
vagrantc has joined #linux-sunxi
<apritzel> from what we know the A133 is the better bin of the A100, before the latter vanished completely from the face of the earth
<apritzel> there is some basic support upstream in the kernel, courtesy of some AW employees submitting this years ago, apparently more on their own initiative
<apritzel> but there is no support in U-Boot or TF-A
<apritzel> there is a series on the list adding some more kernel support, but this is when those people dropped off, so it sits there for years now and bitrots
<acmeplus> Thanks. It's a pity, but not surprising
<apritzel> I have one A133 tablet, but have trouble getting this to run the SPL. I rebased this second series a while ago, but without U-Boot there is little point in pushing this
<apritzel> (and there are more useful things to spend my time on atm)
<acmeplus> agree
<apritzel> acmeplus: is there some BSP code available from Anbernic? Or do they use some tree published by OrangePi?
<apritzel> I am looking at the cpufreq speedbin value: it's 0x6c00 for tokyovigilante's and yours, which is not listed in the list of known values
<acmeplus> I don't know anything about the RG35XX plus/h from them. They sent me a couple of units, but they said they didn't want to share anything of "their" BSP.
<apritzel> well, they actually have to, courtesy of the GPL and you being a customer
<acmeplus> I know... ...
<apritzel> just tell them you don't need the ROMs ;-)
<acmeplus> lol
<acmeplus> funny thing is when I added support for the GPU on the original rg35xx (actions semi) they were suspicious, and I pointed them to the actual cubieboard6 sources that did the trick
<apritzel> oh, I see that in the official OPi github there is branch called orange-pi-6.6-rk35xx
<acmeplus> So now I try to stay away from anything they can provide
<acmeplus> isn't that for a rockchip device?
<apritzel> ah, right, more wishful thinking on my side, I guess ....
<apritzel> what is one letter among friends ...
<acmeplus> lol
<acmeplus> yup, rk/rg...
<apritzel> btw, that's another sign of them (AW and BSP copying people) not getting it: there is no point in having different branches for different devices
<apritzel> ("BSP copying people" means device vendors handing through a BSP)
<apritzel> ah, and in the 6.1-sun50iw9 branch they have this completely broken speedbin detection ...
<Jookia> the - 1 ?
bauen1_ has joined #linux-sunxi
<apritzel> no, that's correctly copied from the H6 version
<jernej> tokyovigilante: can you provide first 1 MiB from BSP image? I just want to check why you have so many troubles with DRAM init.
bauen1 has quit [Ping timeout: 480 seconds]
<jernej> I'm pretty sure that current mainline code works correctly, but you might have newer or at least different version.
<apritzel> jernej: btw: I got the H616 cpufreq support in a good shape, only need to fix one more thing that broke the H6 (details, I know ...)
<apritzel> I am using opp-supported-hw, and un-suffixed opp-microvolt properties
<apritzel> will try to post that on the weekend
<jernej> that's great to hear!
<acmeplus> jernej: this is a dump from the batocera image that boots with the stock boot0/bootloader. https://filetransfer.io/data-package/OQfVmBH6#link
<acmeplus> it should be identical, other than the partition table, etc. I can also upload the boot0 and boot_package if you want
<acmeplus> apritzel: is the error on that bitwise shift?
<jernej> do you have plain boot0 binary? that would be even better
<acmeplus> yeah, wait a second
<apritzel> acmeplus: getting close, though it's not the shift ...
<acmeplus> jernej: should be in the same link
<jernej> thanks!
<jernej> it's the same version, 0.651
<apritzel> jernej: I think we figured already that the DRAM parameters from the boot0 header didn't make much sense in the mainline code
<apritzel> as in: TPR10 and TPR11/12 were not consistent
<jernej> I suggest to take them from /sys/firmware/fdt
<apritzel> which one of the 15 sets in there is it?
<jernej> I think there is one without number
<jernej> which should represent currently in use configuration
<jernej> but others are often nonsensical
<apritzel> ah, the one in the plain "/dram" node. But I think those are the values they are already working with
<apritzel> but they suffer from the same problem: bit 18 in TPR10 is set, but TPR11 and TPR12 are zero
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<jernej> acmeplus: is there a log from serial console, which includes complete boot0 output?
<jernej> I have one suspicion
<acmeplus> Sure, let me boot and copy
<apritzel> jernej: I put this in the Wiki
<jernej> ah, yes
<jernej> boot0 tweaks tpr6, tpr11 and tpr12 values
<jernej> which values are you using currently?
<jernej> ok, so check vendor boot log again
<acmeplus> This is the one from my board, there may be sligh differences since it's based on the RG35XX H stock: https://gist.github.com/acmeplus/03cfd0908caf6d103c0a57d851beb723
<jernej> and boot log spells out adjusted tpr6, tpr11 and tpr12 values
<jernej> I suggest to use those
<apritzel> ah, so does boot0 then somewhat measures those values, at runtime?
<jernej> I think boot0 bruteforces them
<jernej> I haven't study that part of the code too much, but if it's deemed necessary, I can implement that
bauen1_ has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<jernej> apritzel: regarding your quiz, so mask is a bit weird, if you want values between 1 and 3, right?
<apritzel> exactly!
<apritzel> and that's just the visible bug
<jernej> is there invisible?
<apritzel> one thing is that the values it uses look like 0x6c00, so the lower 9 or 10 bits all zero
<apritzel> so even if you fix the mask, the bits wouldn't make sense
<apritzel> and then it says: fall back to 0 (worst die) if outside of the range, which is fair enough, only that the OPPs put the best values in slot 0
<apritzel> so long story short: this code basically ignores the actually encoded bin, and gives you the highest freq/lowest voltage pairs, even on a sub-par die
<jernej> oh, fun
<jernej> so how do you determine proper bin?
<apritzel> there are other BSP drops (5.4, I believe), which have much more reasonable values
<apritzel> for instance my OPi Zero3 doesn't reach 1.5GHz in there, the highest OPP is 1416 MHz :-(
<jernej> I found h618 bsp more reasonable
<apritzel> any pointers? I tend to go to the OPi github
<jernej> I don't remember where I found it
<jernej> let me check
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.0, revision: 5.2.0+git-7558-9b8fa92ef, build type: debug, sources date: 20160102, built on: 2024-02-17 21:13:17 UTC 5.2.0+git-7558-]
bauen1 has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
acmeplus has joined #linux-sunxi
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
<macromorgan> I don't know assembly, is `mov x1, #0x5000000; mov w0, #'1'; str w0, [x1]`the proper code to drop in bl31/aarch64/bl31_entrypoint.S?
acmeplus has quit [Ping timeout: 480 seconds]
<apritzel> macromorgan: yes, anywhere, really, just make sure that x0 and x1 don't contain anything valuable. You probably need to use other registers
acmeplus has joined #linux-sunxi
mripard has quit [Quit: mripard]
<macromorgan> hey dumbass... (that's me, I'm the dumbass)... make sure you RTFM next time.
<macromorgan> I got U-Boot to the main prompt
<macromorgan> still not working, but even further than it was
<macromorgan> turns out unlike Rockchip, you need to use the bl31.bin (whereas Rockchip uses the bl31.elf).
<macromorgan> also though, even with the memory barrier present we talked about yesterday I got a 2048MB read which froze me up during the boot process. So something's still wonky...
<apritzel> ah, yeah, never got why RK used the .elf file, it's a self contained binary, living in a separate memory region, but well
<apritzel> macromorgan: so did you try with the other TPR parameters, from the boot0 bootlog? for TPR{6,11,12}
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
smaeul has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
<macromorgan> not yet, I'll probably try to mess with it more this weekend
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
acmeplus has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
hramrach has quit [Ping timeout: 480 seconds]
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
hramrach has joined #linux-sunxi