<qCactus>
hm, renaming the pin in the defconfig was enough
<qCactus>
ah, no, sorry, it was me enabling CONFIG_MMC_BROKEN_CD in .config
<apritzel>
qCactus: I would recommend you copy the M2-Ultra .dts file, and go over every single node, checking whether it applies to your board or not, and if in doubt, removing it
elros1 has joined #linux-sunxi
ldevulder_ is now known as ldevulder
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
<apritzel>
qCactus: btw: if you need to know the GPIO names for those ball names, check the R40 *datasheet* (on the R40 wiki page)
<apritzel>
that's the one from MoeIcenowy which should add proper dual rank support for the R40 (click on the "diff" button in the top right corner to download)
<qCactus>
Sure, I'll try it.
<qCactus>
I wanna try booting something first, however
<apritzel>
pfft, booting ...
mmarc__ has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
<MoeIcenowy>
apritzel: what's CPUIDLE?
<apritzel>
MoeIcenowy: some hardware state machine in H6 and newer, which does the CPU power off sequence, without needing the ARISC
<apritzel>
smaeul discovered this recently
<apritzel>
so you put in some magics, then say with core you want to power off, and the hardware waits for that core to enter WFI
<apritzel>
then it (presumably) does the proper A53 power down sequence, which we did on the OpenRISC so far
lkcl has quit [Ping timeout: 264 seconds]
<ullbeking>
Are we basically at the end of the road for Allwinner SBC's? Will there ever be a time that I can create a proper NAS with one...
<ullbeking>
Or have USB3?
<ullbeking>
Or SATA? Or 2x NICs?
<ullbeking>
I've had a lot of use from my OPi +2E's, but for IO, forget it
<apritzel>
H6 has USB3.0
<ullbeking>
apritzel: ty
<apritzel>
and some SoCs have two MACs, though one is 100MBit/s only
<ullbeking>
Loading 2 NIC's and 2 SATA converters onto an H6's USB3 bus.... Is that feasible?
<apritzel>
but I think as we have discussed here before, it simply may not be a fit
<ullbeking>
Indeed. This conversation is happening all over the place by many folks
<apritzel>
Allwinner is clearly moving into specialising their SoCs (automotive, camera, smart speaker, tablet)
<ullbeking>
I'm getting deja vu
<apritzel>
the A20 was one-SoC-to-rule-them-all, with SATA, Gigabit-MAC, HDMI, and what not all in one chip
<apritzel>
but newer tablet chips for instance drop Ethernet and HDMI (b/c not needed in a tablet)
<ullbeking>
I tend to find that mini ITX Atom boards are the best value for me
<apritzel>
and to be honest: those SBCs (and especially those "I make a NAS out of it b/c I can't afford a real one") was always some kind of hack, if you like
<ullbeking>
I agreed
<ullbeking>
Agree*
tnovotny has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
<ullbeking>
I just can't wrap my head around NAND flash surviving any real use cases over time (firewall, etc) where the OS needs to read/write....
<ullbeking>
Before the nand flash dies
<ullbeking>
I've missed some bit of info along the way
<ullbeking>
I'll drop the topic now
lkcl has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
<qCactus>
apritzel: I applied the patch and now make complains at me that "Device Tree Source is not correctly specified."
<apritzel>
qCactus: you changed arch/arm/dts/Makefile, right? If yes, make sure you have the backslashes right at the end of the lines
<qCactus>
apritzel: I diffed it with the bananapi dts, and the only differences are a couple blocks commented out and the CD0 pin changed. There are no backslashes in either.
<apritzel>
I mean in the Makefile, you would need to add your file in there, also name it in the defconfig, as CONFIG_DEFAULT_DEVICE_TREE
<qCactus>
well, it says DRAM: 0 MiB :)
<apritzel>
well, good to know, at least
asdf28 has quit [Ping timeout: 246 seconds]
<qCactus>
apritzel: I figured it out now. It was due to my reverting to vanilla 2020.10 before applying the patch, with para.dual_rank hardcoded to 0. Now the patched branch works and boots to uboot console as before
reinforce has quit [Quit: Leaving.]
asdf28 has joined #linux-sunxi
<MoeIcenowy>
apritzel: BTW even w/o dual rank support I think the DRAM should still work (but with half capacity)
<MoeIcenowy>
qCactus: well yes my patch didn't drop the hardcode of dual_rank
JohnDoe_71Rus has joined #linux-sunxi
<qCactus>
MoeIcenowy: Seems like it should, but for some reason it doesn't with this board
<MoeIcenowy>
qCactus: then it's mysterious
<MoeIcenowy>
but with dual rank enabled the DRAM is initialized properly?
lurchi_ is now known as lurchi__
<apritzel>
MoeIcenowy: it even worked before, by just disabling the R40 dual rank panic bits
<MoeIcenowy>
apritzel: w/ the hardcode it should not trigger the dual rank panic bits, right?
<apritzel>
in this case all four chips are equal, so no special treatment needed for rank1
<MoeIcenowy>
apritzel: well yes
<MoeIcenowy>
my patch is only needed for the quirky situation
<qCactus>
MoeIcenowy: If you remove just the hardcode, then the panic bits *are* triggered. If you remove both, it works fine
<MoeIcenowy>
BTW I'm thinking about whether it's safe to just remove the panic
<qCactus>
at least fine enough to not get any errors reading/writing different patterns across the whole memory
<MoeIcenowy>
(because we may search dual rank configuration first, and if we're sure that it's single rank, enable A15 then
<MoeIcenowy>
(I think A15 is used by the DRAM chip of BPi M2U, right?
<MoeIcenowy>
if it is then we can do a regression test
<apritzel>
MoeIcenowy: looks like a good point, just checked the datasheet of the M2U DRAM, they have indeed 16 rows, and use A0-A15
elros1 has quit [Remote host closed the connection]
<apritzel>
I only have the M2 Berry, which uses 15 rows
warpme_ has joined #linux-sunxi
<MoeIcenowy>
apritzel: I have a M2U, but my storage is a mess that I need some time to find it
<apritzel>
MoeIcenowy: no worries, take your time
<apritzel>
so do I get this right that we would try dual rank first, which would configure A15 as CS1, so this would somehow work, but obviously isn't right?
<MoeIcenowy>
apritzel: I think so
<MoeIcenowy>
our detection routine is current:
<MoeIcenowy>
detect rank + DQ width by doing train, then detect bank, row, column
<MoeIcenowy>
detect rank+DQ is done by
<MoeIcenowy>
mctl_channel_init
<MoeIcenowy>
and the bank/row/col detection is done by mctl_auto_detect_dram_size
<MoeIcenowy>
when doing the rank+DQ detection, the bank/row/col values are just placeholders
<MoeIcenowy>
(BTW my patch is designed to do bank/row/col detection for both ranks
<apritzel>
MoeIcenowy: yeah, it's hard to guess what would happen, the DRAM controller would think there are more chips, so would issue more refresh commands, for instance
<MoeIcenowy>
bauen1: yes, you got it correctly
cmeerw has joined #linux-sunxi
<MoeIcenowy>
apritzel: we hope the DRAM controller can differienate a wire connected to A15 with it connected to CS1
<bauen1>
but details on the security side of the risc-v core are pretty non-existent over the web as far as i can find
<apritzel>
bauen1: but that's mostly an integration choice anyway, isn't it?
lurchi__ is now known as lurchi_
<bauen1>
true true, and allwinner doesn't just give out details for free :/
<apritzel>
and *Allwinner* integrating a RISC-V core doesn't change exactly nothing for the community, because the core is the least of our problems
<apritzel>
(it just saves *them* the license fees and royalties for the cores)
<mripard>
apritzel: I assume you took your ARM hat off to say that one ? :)
<apritzel>
mripard: I am certainly biased, but don't really understand the excitement about that, because the problems will be the same, we will just have new bugs ;-)
* karlp
does the peripherals, peripherals, peripherals dance wearing his ballmer outfit...
<mripard>
apritzel: yeah, I don't totally get the hype around risc-v either
<mripard>
I mean, sure, having a free ISA is nice
<mripard>
but at the end of the day, you'll still have to trust whatever entity has designed and produced the core
<mripard>
and it's not like you could do it in your home either
<bauen1>
a free ISA should make it easier, still not practical but easier
<apritzel>
yes, and nothing prevents people from using openly documented and well supported peripherals with ARM cores
<karlp>
do those exist? ;)
<apritzel>
karlp: that's my point: I don't see how RISC-V would change that
<karlp>
I'm on your side, I was just teasing abotu the quality of periphs in general.
<zumbi>
royalties story might change
<mripard>
bauen1: I don't really see how the "freeness" of the ISA changes things compared to a public one like the ARM ISA is
<apritzel>
that's the only point I see: it gets cheaper for Allwinner
<mripard>
(as a user I mean, for a CPU designer, I definitely see the appeal)
<apritzel>
I mean I get this stinginess was probably the reason they chose an OpenRISC core for the ARISC back then
<bauen1>
mripard: with a "free" ISA there is nothing legally preventing you from implementing your own CPU (or softcore) and there for also makes it easier (but a pipe dream probably) to open source the hardware, at least i think so
qCactus has quit [Ping timeout: 264 seconds]
<mripard>
yeah, I agree with that
<mripard>
what I don't really get is the general sentiment that it's going to be the norm, and it will "save" us like the free software did
<mripard>
I can recompile the software if I want to, it's going to be difficult to do for an ISA
<mripard>
(except if it's a softcore)
prefixcactus has joined #linux-sunxi
<apritzel>
plus I wonder how many companies would actually open source their *kick-ass* micro-arch
pCactus has quit [Ping timeout: 265 seconds]
<jernej>
I'm pretty sure there will be countless proprietary RV cores popping out all over the place, mostly because toolchain already exists and it's maintained
<jernej>
apritzel: smaeul: Is it possible R40 has CPUIDLE functionality? How can this be checked? It doesn't have ARISC core, so maybe they implemented some other way for standby
<smaeul>
jernej: dump R_CPUCFG registers, and look for the CPU power switch sequence at offset 0x150
<smaeul>
it's documented in the T3 and A40i manuals, so R40 most likely has it
<jernej>
yeah, it's same die as T3 afaik
<jernej>
smaeul: is this something we can use?
<smaeul>
oh, the sequence is at offset 0x160 on the 32-bit chips
<smaeul>
jernej: that's what I'm looking at. only the power-down function is documented, but obviously there is a power-up function as well
<smaeul>
and there are at least two idle states implemented
<jernej>
I assume wakeup is just interrupt based?
<apritzel>
we could get rid of the ugly secure IPI core-off implementation in U-Boot
<apritzel>
(but probably just for R40, so there would be little point)
<smaeul>
the other A33+ cores could use an ARISC shim like in TF-A
<smaeul>
so only A20 needs the IPI
<smaeul>
jernej: at least one idle state is, yes. since AW uses GICv2, the IRQ/FIQ signals are visible outside the cluster
<smaeul>
there are some GIC-related status/mask registers in CPU_SUBSYS_CFG, but AW doesn't use them, and they appear to do nothing
<smaeul>
if the CPUIDLE status allows the ARISC to see pending IRQs, then I can implement DRAM idle in crust as well (check IRQ status and resume DRAM before powering any cores back on)
<smaeul>
though I'm not sure how to check other MBUS master status
<jernej>
oh, if only we could peak into HDL :)
<apritzel>
jernej: even if that would be twice as good as their software, you probably *don't* want to have a look ;-)
<jernej>
oh, I'm quiet accustomed reading HDL for documentation purposes
<smaeul>
apritzel: while I'm still investigating, to answer "what bits does CLOSE_CORE[0:3] touch?", it is 1) DBGPWRDUP, 2) gating / output clamps, and 3) power switch
<smaeul>
so it doesn't touch any resets, but that should be fine as long as the resets are asserted during power-up (which they are)
<apritzel>
smaeul: the A53 TRM doesn't mention any resets on power down, so that seems to be fine
<smaeul>
its funny how we go through this effort to handle DBGPWRDUP when I doubt anyone (using mainline) has ever tried to use CoreSight on these SoCs :)
<apritzel>
smaeul: yeah, I guess just pulling the plug (remove power) would actually already work, as long as we do the powerup correctly
<apritzel>
I wonder if using the CPUIDLE h/w for U-Boot's PSCI implementation on the R40 would still make sense, as we don't pull other cores out of Linux, also allow core0 to be powered off
<apritzel>
and we seem to already have quite some #ifdef R40 in the code anyway
<smaeul>
core0 hotplug on 32-bit has never worked, because it requres the additional hotplug flag (... also which is broken on H3 at least)
<smaeul>
thankfully Linux inhibits it by default
<apritzel>
oh, it is like on the A64, where there is no separate "power switch" for core0?
<smaeul>
no, I'm meaning in the BROM -- if you don't set the CPU0 hotplug flag (like you do for return to FEL), CPU0 will run through the normal boot-up path
<smaeul>
I have an M2U, so I will throw R40/A40i CPUIDLE on the todo pile, after H3 SCPI
<apritzel>
smaeul: how is that going with 32-bit TF-A? Any problems?
vagrantc has joined #linux-sunxi
<smaeul>
apritzel: the main problem with 32-bit TF-A is that it doesn't fit in SRAM A2
<smaeul>
so I was thinking I would rather clean up the U-Boot PSCI implementation
<smaeul>
the big SRAM wasters are MMU and dynamic service registration. and since TF-A unconditionally uses spinlocks (ldrex/strex), I can't run it with MMU off
<apritzel>
yeah, I was wondering about that ...
<apritzel>
smaeul: funny enough the requirement for MMU on is not really documented nor enforced
<apritzel>
there is just this silent reliance of exclusives to work
<apritzel>
s/of/on/
<smaeul>
maybe they would accept a config option to avoid use of ldrex/strex? I'd have to check if sp_min would fit in 16k even with no MMU