System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
franoosh has quit [Ping timeout: 244 seconds]
<mmind00>
diederik: the minute (after) I apply those rk3328 gpu patches, you send your Tested-by :-D
<diederik>
LOL
<mmind00>
but I picked those up now too
<diederik>
thanks :-)
<chewitt>
thanks both .. two more long-hoarded patches exorcised from our backlog :)
<diederik>
Thanks for upstreaming them :-D
<dsimic>
I'm happy to see those patches submitted and upstreamed... :) thanks everyone, and I'll pay attention to the field-tested GPU OPPs when I start butchering everything with the pcoming SoC binning :)
<dsimic>
I'm also very happy and excited to report that the Radxa's donation has arrived! :)
<dsimic>
the literal size of the projects has just hit me... hard :D
<dsimic>
thank you very much, Radxa! I really appreciate it, and I'll send some pictures later
<dsimic>
s/pcoming/upcoming/
<qschulz>
what are you planning to do :) ?
chewitt_ has joined #linux-rockchip
<dsimic>
implement SoC binning in the mainline, then RE the DRAM init blobs :)
<dsimic>
I've selected the donated SBCs very carefully to cover different SoCs and their variants
<dsimic>
together with different DRAM configurations
chewitt has quit [Ping timeout: 260 seconds]
<qschulz>
is the plan with this SoC binning to merge industrial, commercial and automative grade variants into one DT?
<dsimic>
yes, we'll lose the current per-variant .dtsi files
<dsimic>
actually, maybe some of them will be left, if that brings additional clarity... we'll see
franoosh has joined #linux-rockchip
<dsimic>
of course, I'll validate everything, to make sure we'll have no (unforeseen) regressions
<naoki>
Kwiboo: Thank you. By the way, is it correct that gmac doesn't work on U-Boot (EQOS_DMA_MODE_SWR stuck)?
<qschulz>
dsimic: that would be great, I'm looking forward to this :)
<qschulz>
good luck and have fun!
<dsimic>
thanks! :)
<naoki>
Kwiboo: I tried your U-Boot and Linux, but I still get "stmmac_hw_setup: DMA engine initialization failed"...
franoosh has quit [Ping timeout: 258 seconds]
<naoki>
By the way, if I try to read the dtb from the filesystem, the kernel panics during boot with the following error:
<dsimic>
hmm, when and how do you exactly try to read it?
<Kwiboo>
naoki: did you try with radxa-e24c-rk3528_defconfig u-boot target? I also used rk3528_ddr_1056MHz_v1.12.bin and rk3528_bl31_v1.20.elf for my testing yesterday, some Kconfig options that differs? my is arm64 defconfig + no modules and possible one or two options enabled that is missing in defconfig
<Kwiboo>
I probably used the DT from U-Boot during my test, and not the DT from kernel, will run more tests today
<Kwiboo>
DTs are very closly synced in the linked trees above, so I do not expect any diffrance related to storage and networking
<naoki>
rk3528_bl31_v1.20.elf, rk3528_ddr_1056MHz_v1.11.bin, and radxa-e24c-rk3528_defconfig
<dsimic>
dsimic: ah, I see, you referred to the .dtb in /boot... sorry for the noise
<dsimic>
oops... naoki ^^^
<dsimic>
(I'm a bit too excited :)
<naoki>
no kernel panic with DT from U-Boot, so U-Boot or Kernel may be broken somehow
<naoki>
It's probably unrelated to the gmac issue.
<dsimic>
perhaps it would be good to check the differences between those two DTs
<mmind00>
dsimic as for RE'ing the DRAM init blobs ... you might want to talk to CyReVolt to prevent double work
<CyReVolt>
oh totally, I'm not checking here as frequently tbh - will happily get in touch for exchange :)
<dsimic>
mmind00: thanks for the heads-up!
<mmind00>
dsimic: gladly ... just read the keywords of DDR and RE ... and that big lightbuld went on :-D
<dsimic>
CyReVolt: perhaps it would be good if you'd describe your DRAM init RE work so far, when you get a chance
<mmind00>
bulb
<dsimic>
mmind00: it's a large lightbulb indeed :)
<dsimic>
CyReVolt: I'd also like to discuss the legal side of the RE as well
<Ermine>
good luck with the project!
<dsimic>
CyReVolt: AFAICT, the "minimal cooperability" clause (or whatever it's called) should get us covered
<dsimic>
Ermine: thanks!
<dsimic>
CyReVolt: or would we need to take the clean room approach? that's also something to be discussed, if you agree
<dsimic>
do you happen to have an idea where or who to ask about a legal advice?
<dsimic>
the FSF's free legal service seems to be out of service, but I may be wrong there
<CyReVolt>
I am doing the RK3566 low-speed variant, rk3566_ddr_528MHz_ultra_v1.10.bin - and I skipped the loop that detects the DRAM type first. I am about 80% done, working on the other 80%. Took another break though, just having a look back into it right now.
<CyReVolt>
No idea regarding legal bla. I personally think that we'll be just fine in terms of European and, in my case, German law.
<CyReVolt>
My work is for oreboot, so it's all written in a new language anyway, and I just extract the facts from the vendor code. And oddly enough, it is 60% or more what you find in U-Boot already. Only the PHY is really different, the controller mostly the same as for other SoCs, and the remaining bits (haha) are mainly data, of which there is a good bunch, mainly to support 4 DRAM variants, i.e. DDR3/4 and the low-power
<dsimic>
perhaps it will also be possibe to get the common parts extracted into a "library", so to speak, and feed the parameters to it
<CyReVolt>
heh it's mainly because I somehow fell into oreboot for reasons (you know, like becoming a drug addict, you gotta know the right/wrong people...)
<CyReVolt>
and tbh Rust is just a ton easier than C so I stuck with it
<dsimic>
sorry, is it oreboot or Coreboot? :)
<CyReVolt>
oh yes the library approach totally works, once we extract the logic; it's very messy all over the place though ⚠️
<dsimic>
I'll make sure to read the slides
<CyReVolt>
It is oreboot, a downstream fork of coreboot, without C - get it? :D
<dsimic>
I actually expected it to be extremely messy :/
<dsimic>
ah, Roreboot! :)
<CyReVolt>
sometimes I mistype it as ireboot when I run into issues 😂
<dsimic>
or perhaps Rsoreboot :)
<CyReVolt>
Anyway, pleased to meet you! Feel free to also reach out via DM or whatever you prefer. I'm on Signal and such, too.
<dsimic>
thanks, I'm on IRC only
<dsimic>
I'll go through your work in the next few days, or perhaps in a week, and I'll get back to you with my further thoughts
<dsimic>
see also the user page on English Wikipedia :)
<CyReVolt>
Feel free to ask any questions. Most of my commits re RK356x are a bit funny, possibly, mainly because I do blind code translation without understanding much. But I did dig into U-Boot to find the counterparts where applicable and put the respective notes in the comments.
<CyReVolt>
A friend of mine looked into setting up a Ghidra server for collaborative work. I'll see how far they got. Maybe it'd help here. Annotating stuff was quite some work.
<CyReVolt>
dsimic: may I asked what you have done so far?
franoosh has joined #linux-rockchip
<dsimic>
I mostly looked around a bit, to get a bigger picture with no exact details, because the main question for me, before hitting it harder, :) was whether I'd get the aforementioned hardware donation from Radxa
<dsimic>
basically, to be able to submit any code upstream, we need it to be tested on different SoC variants, e.g. RK3566, RK3568, RK3566T and whatnot
<dsimic>
so I didn't want to dig deeper until I got the hardware, because I couldn't afford to buy the SBCs with the required SoC variants myself
<dsimic>
also, my first goal will be to implement support for SoC binning, which requires testing on even more SoC variants and even more different SBCs, because I should be able to produce upstreamable SoC binning code much faster -- there's no RE involved there
<dsimic>
with all that in mind, I hope you understand why I was sitting on the brake pedal until this hardware donation
<dsimic>
I'm so thankful to Radxa, and the donation includes some other stuff, such as the Radxa hexa SATA hat, to test and debug what's going on with the longstanding issue with that hat
<dsimic>
oh, and I read quite a lot about the DRAM background, so I should be able to fill in the gaps in understanding all the gory details
<dsimic>
which should help us with producing not just the blind translation, so to speak, but good code
<CyReVolt>
sorry if multiline broke IRC again, I just rememberd it
<dsimic>
no worries
<CyReVolt>
and sorry, I have no README for rk_boot just yet x)
<dsimic>
no worries again :)
<dsimic>
I'll go through the code, which may also force me to learn Rust a bit :)
<CyReVolt>
I'm currently doing other things though, fixing an issue in the Go runtime that affects 32-bit systems, futexes and year 2038 shenanigans... which I'll get back to now. Just ping me whenever. :)
<dsimic>
it's good to be busy like that :)
<CyReVolt>
ah yea that Rust code there should be dead simple to understand since it's really just 99% MMIO and function calls
<dsimic>
just to reiterate, my primary focus will be on the SoC binning for now, and on some other stuff that requires no RE
<CyReVolt>
it's a bit dirty in that regard, not really would std Rust would be (like hosted under Linux), so take it with a grain of salt 🧂
<CyReVolt>
alrighty, good luck! I in turn will happily look at the binning code at some point to create a Rust counterpart. 🦀
<dsimic>
while I'll also poke around to fill in the big DRAM init picture with some more details, and I'll get back to you with some comments
<dsimic>
thanks, good luck to you, too! :)
<CyReVolt>
Thank you! 🥰
<dsimic>
ah, I can't discern good Rust code from bad, so don't worry :)
<dsimic>
before I forget, regarding the legal things, I'm in https://en.wikipedia.org/wiki/Bosnia_and_Herzegovina which I think has no strict laws that may affect such RE work, but I'd still like to get that aspect covered properly
<dsimic>
I'll try to ask around a bit, and I'll let you know whatever I manage to learn or find out
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #linux-rockchip
<dsimic>
sorry, I've been disconnected for a few minutes
<qschulz>
CyReVolt: yet another tool for uploading binaries to Rockchip's BootROM 😭
<qschulz>
snagboot is gaining support for Rockchip (see MR) and labgrid also, with their own implementation as well
<naoki>
Kwiboo: Oh. After booting (after the message "stmmac_hw_setup: DMA engine initialization failed" appeared), I unloaded the dwmac_rk related modules and the rtl8365mb related modules, then loaded them again, and the error disappeared. I was able to set an IP address on wan and ping worked.
<naoki>
qschulz: I don't know how many programs there are (LOL)
<qschulz>
beauty and pain of open-source development :)
<CyReVolt>
qschulz: yes I've looked into the other tools for reference, also xboot's one and Collabora's
<qschulz>
CyReVolt: yeah I've listed those because I see the issue you opened on your GH with some listed there and got curious how many more I was aware of :)
<qschulz>
better too many than none
<CyReVolt>
haha yes... I mainly created mine because the other CLIs where either too confusing or not fitting my case. I've written a good bunch of such loaders, all under platform-system-interface
<dsimic>
it's almost time for the obligatory XKCD :)
<qschulz>
well... U-Boot doesn't have its own yet so there's room for another one dsimic ;)
<dsimic>
haha, there's always an nice place for yet another one :)
<dsimic>
s/an/a/
<dsimic>
actually, s/XKCD/xkcd/, the all-uppsercase variant seems to be uncommon
<naoki>
I first created tools for Rockchip in 2010, and at the time there was no source, so RE was my main source of food ;)
<dsimic>
nice, sometimes RE is the only option
chewitt_ is now known as chewitt
f_ has joined #linux-rockchip
franoosh has quit [Ping timeout: 245 seconds]
Sario has joined #linux-rockchip
franoosh has joined #linux-rockchip
franoosh has quit [Ping timeout: 256 seconds]
naoki has quit [Quit: naoki]
_whitelogger has joined #linux-rockchip
chewitt has joined #linux-rockchip
chewitt has quit [Quit: Zzz..]
ldevulder has quit [Ping timeout: 256 seconds]
chewitt has joined #linux-rockchip
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-rockchip
chewitt has quit [Quit: Zzz..]
vagrantc has joined #linux-rockchip
<shoragan>
qschulz, in the medium term, I'd like to replace labgrid's drivers for existing usb loader tools with snagrecover
<shoragan>
labgrid doesn't implement the protocols itself, but calls existing tools as subprocesses.
<qschulz>
so that should cover Rockchip better than what we currently have
<qschulz>
as for using snagrecover instead of handling the protocols ourselves in labgrid, I think it's a good idea
<qschulz>
we could have a base SnagrecoverDriver that just calls snagrecover -s self.soc -F self.firmware self._more_opts
<qschulz>
and then you have RockchipSnagrecoverDriver that sets this self.soc, self.firmware based on config (possibly with defaults that works good enough)
<qschulz>
and we can set self._more_opts to e.g. --usb-path <whatever>
<qschulz>
and binding against an RKUSBLoader
<tlwoerner>
i have a bunch of rock-pi-s devices (rk3308) doing some jobs around my property which only have 256MB of RAM
<tlwoerner>
i recently upgraded them from 6.12 to 6.16
<tlwoerner>
on 6.12 they could run for weeks, months even, without issue
<tlwoerner>
after about a day or two with 6.16 they all started thrashing wildly and either rebooting or just crashing
<tlwoerner>
so i had to go back to 6.12 for them
<tlwoerner>
but it would be nice to try to figure out what happened and maybe find a fix?
<CounterPillow>
yes that would be nice to do
<CounterPillow>
I can't think, off the top of my head, if there's any rockchip driver specific changes that would be leaking memory like this
<qschulz>
tlwoerner: the best thing to start with would be to check if the master branch of linus still has the issue
<CounterPillow>
master is currently kinda busted due to the genpd thing, might still work though
<qschulz>
tlwoerner: the only noteworthy change I see in the DT for rk3308 would be 09b0a7b63a6cda138e2e47c6acb2aee80338624c where the pinctrl for pwm controller is finally taken into account. I vaguely remember you tried to do stuff with pwm a while ago?
raster has joined #linux-rockchip
<qschulz>
tlwoerner: are you sure it's only the kernel? I assume you're using Yocto, so not sure if it's really just the exact same image with linux-yocto 6.12/6.16 or if there are other userspace changes as well?
raster has quit [Quit: Gettin' stinky!]
raster has joined #linux-rockchip
ldevulder has quit [Ping timeout: 256 seconds]
<tlwoerner>
qschulz: true, i tend to do a "git pull" on all the repositories and build from there, so it's not just a kernel change but a whole bunch of userspace too. i tend to do this every 2 weeks or so, so that's a lot of changes for each update
<tlwoerner>
for the time-being i have the latest userspace with a 6.12 kernel, so that will be one data point
<shoragan>
<qschulz> we could have a base SnagrecoverDriver that just calls snagrecover -s self.soc -F self.firmware self._more_opts
<shoragan>
a single SnagrecoverDriver would be enough, on initialization it can see which resource it has bound to and configure itself correctly
<dsimic>
I pingd you a couple of times in the lalst few days
<tlwoerner>
dsimic: on irc?
<dsimic>
yes, in this channel
<tlwoerner>
dsimic: sorry, i don't always remember to check irc
<tlwoerner>
what's up?
<dsimic>
to sum it up, I've finally received a couple of Rock Pi S0 boards from Radxa, so I'll start working on the RK3308 thermal support soon
<dsimic>
the donation also includes the Radxa hexa SATA hat, to test and debug what's going on with the longstanding issue with that hat
<dsimic>
no worries
<tlwoerner>
dsimic: nice! i'm still carrying and using the thermal patch from... Jonas
<tlwoerner>
i had a SATA hat and used it on a rock-pi-4b for a while, but i stopped using it for some reason i can't remember
<tlwoerner>
i remember having some sort of problem with it (pcie stopped working?), but i think i also broke a connector on it too
<tlwoerner>
Jonas = Kwiboo (or visa versa)
<dsimic>
that hat has been reported as no longer working in newer kernel versions, so we'll hopefully see better what's going on
<dsimic>
I'm sorry to hear about the broken connector
* tlwoerner
still needs to get around to blogging about how i'm using my rockchips
<dsimic>
indeed, that would be great articles :)
<dsimic>
regarding the issues with your Rock Pi S boards on 6.16, it would be good to, if possible, see the kernel logs/oopses when they lock up or misbehave
<dsimic>
s/that/those/
beeble has joined #linux-rockchip
franoosh has quit [Ping timeout: 258 seconds]
nashpa has joined #linux-rockchip
dliviu has quit [Ping timeout: 256 seconds]
s1b1_ has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
s1b1 has joined #linux-rockchip
System_Error has quit [Ping timeout: 272 seconds]
System_Error has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
stikonas has quit [Remote host closed the connection]