<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
<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
<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>
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>
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
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 ...
<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
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]