<Esmil>
conchuod: i'm not a big fan of hardcoding cpu frequencies in drivers like this
<Esmil>
there are standard device tree entries for setting clock frequencies. i'd think it makes more sense to use those
<Esmil>
..but i think that's what he did in v5
<drmpeg>
Yes.
<drmpeg>
But then the concern was it didn't match u-boot.
<Esmil>
but the kernel is the upstream for device trees right?
<drmpeg>
There's this OF_UPSTREAM thing that seems to cloud the issue.
rlittl has joined #riscv
<davidlt>
Esmil, I think (but didn't check) OF_UPSTREAM is still WIP.
<davidlt>
Not to mention that most folks will probably not updated U-Boot with a new kernel (or at all).
<Esmil>
so that means we shouldn't worry about u-boot's copy of the device tree right?
<Esmil>
hence v5 should be fine
<davidlt>
That means you shouldn't expect U-Boot (on the SPI-NOR flashes with OF_UPSTREAM).
<davidlt>
I cannot talk for all the distros, but we don't really use DTB from firmware (i.e. U-Boot) to boot Linux. We always boot with DTB from the same kernel version.
<Esmil>
right. so that's why we'd want to encode the cpu frequency in the kernel device tree
<davidlt>
I kinda recall some emails mentioning that PLL0 has to stay 1.0GHz in U-Boot.
<Esmil>
sure, and then when the kernel boots it'll load its device tree and change the frequency
<davidlt>
yeah, but once OF_UPSTREAM work is done it's the same DTS for Linux and U-Boot.
<davidlt>
(+ U-Boot overlay bits)
<davidlt>
Back in May:
<davidlt>
It is not apply to U-Boot. In the U-Boot, the PLL0 rate should be 1GHz to for GMAC
<davidlt>
and PMIC to work. But now the PLL0 rate should be 1.5GHz in the Linux.
<Esmil>
..but then they should fix their drivers before importing the new device tree
<davidlt>
They are doing that (OF_UPSTREAM support)
<Esmil>
ok, then there is no problem then
<davidlt>
I didn't check, but if the same DTS nodes are used for PLL0 on U-Boot and Linux side there has to be a hack in Linux or U-Boot to set to 1.0GHz or 1.5GHz.
<davidlt>
If it's not in Linux, then it's in U-Boot to keep that 1.0GHz for PMIC and GMAC to work.
<davidlt>
Just an assumption.
<Esmil>
..or they could fix their drivers to work with 1GHz as you said they would
<Esmil>
*1.5GHz
<davidlt>
Well, that basically means the same hack 1.5GHz -> 1.0GHz on U-Boot side.
<Esmil>
that doesn't make sense. if linux can drive ethernet with 1.5GHz why can't u-boot?
<davidlt>
They said it has to be 1.0GHz (don't know why) for PMIC and GMAC work. So if OF_UPSTREAM is used, and PLL0 is set to 1.5GHz, then U-Boot driver must detect and force that to 1.0GHz.
<Esmil>
right, and that's probably because they don't have a working clock driver and just hardcodes certain frequencies
<Esmil>
..which they should fix
<davidlt>
I don't know. I am just working on with their statement with no details.
<Esmil>
before importing the device tree
<davidlt>
Esmil, you are a better expert here, but they are waiting for your reply :)
<davidlt>
This probably needs a bit more details/clarification from their side.
<davidlt>
Esmil, I chatted with them on July 4th, and they said they are waiting for you reply on that patch.
<conchuod>
Ah I forgot they were working on the U-Boot side of it too.
<conchuod>
Is the crpyto driver still not in good shape?
<Esmil>
it completely crashed the kernel when i wrote that patch, but maybe it's time to try again
<Esmil>
there was a thread with a bug report, but now I can't seem to find it
<davidlt>
I don't think we enabled crypto on JH7110 since it was causing kernel crash a long time ago
<davidlt>
I pinged aurel32 on debian-riscv (OFTC) to see if they enabled it since then
<Tenkawa>
I'm going to be working on a VF2 1.3B today so it will be interesting to see
<Tenkawa>
a Mars CM too but I think it still needs work
<mps>
iirc jh7110_crypto works if it loaded later when machine boot or at least doesn't crash kernel
<Tenkawa>
mpe: what about in an initram?
<Tenkawa>
er mps
<mps>
Tenkawa: didn't checked but even if it loaded later initram is read it crash. Alpine have hwdrivers load init script and also with it it crash
<mps>
I noticed only loading 'by hand' is safe
<Tenkawa>
ouch... yeah that is a toughy to track
<mps>
though I didn't tested this exhaustively
<Tenkawa>
I'm still hoping to see the Spacemit-K1 supported down the road then I can start throwing more debugging in.... I am a bit out of date on the JH7110 currently
<Tenkawa>
(Losing my VF2 to dead board for a few months slowed me down a lot)
<Tenkawa>
I have a new one now but playing catchup now
<davidlt>
There was a video 3-4 days ago from Framework showing and talking about mainboard with JH7110.
<davidlt>
Spacemit K1 and M1 are quite popular because of their ISA extensions.
<davidlt>
If you are working on anything ISA related (kernel, glibc, toolchains, etc.) you kinda want it.
<davidlt>
MilkV Jupiter is kinda cool (mini-ITX, M1, M.2, 16GB of RAM).
<davidlt>
At it comes at a similar price point of VF2 IIRC.
<davidlt>
Yeah, this one gonna be used for a years for sure.
<davidlt>
Btw, to my understanding K1 vs M1 is 200MHz difference. I was surprised that M1 has different SoC packaging. It has a metal heat-spreader like SiFive/StarFive SoCs.
<davidlt>
Tenkawa, confirmed, Debian also has it disabled.
<Esmil>
it's definitely popular because of the extensions, but i don't know about used for years. it's not faster than the vf2 that is already used for years
<davidlt>
Yeah, ST is the same running RV64GC, but it's double the cores and memory.
<davidlt>
You have to assume price too. For this price it's gonna stay here a long time.
<davidlt>
Oasis/SG2380 will not be cheap.
<Tenkawa>
I do like the 8 core speed of this Banana PI F3
<Tenkawa>
Its actually fairly speedy
<Tenkawa>
(for a low end board)
<Tenkawa>
Mine is a bit short on ram (I only ended up with the 4gb version)
<conchuod>
The spacemit soc means noone is gonna care for the k230 at all, doesn't it?
<davidlt>
I don't care about K230
<Tenkawa>
conchuod: problem is the spacemit needs a lot more documentation... it is "lacking" so far (at least from what I have access to)
Noisytoot has quit [Ping timeout: 252 seconds]
Noisytoot has joined #riscv
<drmpeg>
I turned the crypto unit back on. It doesn't bomb, but I do get an error.
<Tenkawa>
er yep... will I need to switch out u-boot?
<drmpeg>
I didn't.
<Tenkawa>
I'm still running Canonical's u-boot
<Tenkawa>
ok
<drmpeg>
Esmil, yes those configs are enabled.
<Tenkawa>
Time to compile (here's where I like my fast compiler)
<Tenkawa>
lol
heat has joined #riscv
<davidlt>
aurel32, mentioned that the last time he tried: iirc no crash on load anymore, but hanging in the kernel tests
<conchuod>
Tenkawa: If you think spacemit is bad, the k230 is worse :)
<conchuod>
Certainly for non-Chinese speakers.
<Tenkawa>
conchuod: heheh... yeah my Chinese speaking contact tells me though these docs are quite.... sparse
gnarchie has quit [Ping timeout: 260 seconds]
<davidlt>
conchuod, bad in what way?
<Tenkawa>
Fortunately not bad.... just sparse/lacking
lagash has quit [Ping timeout: 248 seconds]
<conchuod>
davidlt: I tried looking for a register map and a clock tree, but I could not find it.
<davidlt>
conchuod, ah, documentation, in that case nothing new :)
<davidlt>
I thought there was some silicon issues found :)
<conchuod>
davidlt: ye the message I was replying to was about documentation.
klb73 has quit [Ping timeout: 260 seconds]
Andre_Z has quit [Ping timeout: 276 seconds]
gnarchie has joined #riscv
memset has quit [Remote host closed the connection]
memset has joined #riscv
BootLayer has joined #riscv
memset has quit [Remote host closed the connection]
memset has joined #riscv
<Tenkawa>
yikes....that created a big build output
<Tenkawa>
transferring it over now to see if it runs
stolen has joined #riscv
Stat_headcrabed has joined #riscv
lagash has joined #riscv
vagrantc has joined #riscv
<courmisch>
conchuod: does anyone care about K230 for anything other than benchmarking vector code in the first place?
<conchuod>
courmisch: They must have customers, right?
<conchuod>
Right???
<courmisch>
do customers care about upstream?
<conchuod>
Very few people's customers do :(
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<courmisch>
vendor only uses Linux for management, pitching their RTOS for the real work
<conchuod>
courmisch: but ye, I don't know what other use case it has for the "enthusiast" crowd that would be likely to work on kernel support for a board like that than benching.
<courmisch>
hard to say. I got a grand total of zero patches to my stuff, but it could just be because of the antispam on code.videolan.org or the vendor undercutting me
coldfeet has joined #riscv
<conchuod>
I made some changes to your stuff, but nothing capable of being contributed back. Was to test Yangyu's patchset with mainline OpenSBI/Linux.
<courmisch>
at minimum, we need serial, Ethernet and TF to work, yes
<conchuod>
I think the upstream linux/OpenSBI "support" for it is likely to waste away on branches in my and Yangyu's trees, which is kinda a shame cos they got Svpbmt working instead of te MAEE stuff.
<courmisch>
graphics and WiFi don't work anyway already
<courmisch>
yeah well, I'd love to spend more time on it but nobody is going to fund that
<conchuod>
yah, and I need the first two to work if I have any hope of testing it, so the lack of any real interest that'd get people working on that was a turnoff for me sending it to Arnd.
<courmisch>
already took 2-3 weeks of free time
<courmisch>
conchuod: sounds like a vicious circle
<conchuod>
Yeah, I suppose it does.
<conchuod>
But if noones cares, it is not worth the effort. Any board I sign up to look after is less time for other things.
<courmisch>
I'd do it if I believed it could make me more visible and land me a job, but I don't
memset has quit [Remote host closed the connection]
memset has joined #riscv
BootLayer has quit [Quit: Leaving]
coldfeet has quit [Remote host closed the connection]
psydroid|2 has joined #riscv
prabhakalad has quit [Quit: Konversation terminated!]