<apritzel>
jernej: SO many thanks for the U-Boot review, that's much appreciated!
<jernej>
apritzel: no problem, anything to speed up adoption of new platforms :)
<jernej>
apritzel: I suppose A133 is pre-requisite for A523 support?
<apritzel>
well, there is some overlap, but it's not critical, I can handle it either way. A133 has DTs fixed and already in the tree, so the U-Boot proper parts can go already
<apritzel>
so it's just the first three cleanup patches, really, and with your tag I will merge them next week, so that you can base on that then
<loki666>
just opened my A133P devices, I don't see uarts pads...
<loki666>
at least not on the back of the board...
<jernej>
apritzel: should I prepare U-Boot support for A523?
<apritzel>
otherwise I would prepare the non-DRAM parts sometime on the weekend
<apritzel>
but we need the basic DT parts finalised first, so decide on how to go forward with the pinctrl, and fix the clock numbers in the binding headers
<apritzel>
jernej: I have some changes already compared to what I posted in November, and warpme pointed out that the second EMAC is missing
<jernej>
apritzel: ok, then I'll clean up TF-A code and improve DRAM over weekend. I'd like that early experimenters (hint, warpme) start using this code
<apritzel>
jernej: yes, that's a good plan, many thanks
<loki666>
there is a group of 3 pads next to the heatsink, maybe that... but it means soldering on the board...
<loki666>
and without knowing what is what it's going to be a mess
<loki666>
arf no sorry I can swap the other ends :p
<apritzel>
you can probe that: first find the GND pin, with a continuity test
<loki666>
good idea
<jernej>
apritzel: I just read about pinctrl. IIUC, you pretty narrow down a way forward?
<apritzel>
loki666: then you can just hold an RX wire to one of the others and see if it spits out something
<apritzel>
typically the BSPs are quite chatty on the serial
<loki666>
usb port casing are grounding ?
<loki666>
I don't have BSP
<loki666>
I have a SDK to build it, and it's a pile of 10gb crap
<loki666>
doesn't works
<apritzel>
ah, right, and there is no download image, because their image always contains games as well?
<loki666>
yes, no image
<apritzel>
jernej: if we go ahead with what I proposed, it's all fine, but LinusW seems to prefer more standardisation, so piggy backing on the Apple/STM32 binding seems more sustainable
<apritzel>
jernej: but that would require quite some rewrite of the sunxi pinctrl driver, at least that's my impression last time I checked
<apritzel>
so would change quite a bit, both in the driver and binding
<apritzel>
at the moment it stays mostly compatible, just adds this new property
<apritzel>
jernej: feel free to chime in there ;-) I wanted to hear opinions from both pinctrl and sunxi maintainers
<loki666>
I guess this pad group is the uart, there is at least one pad grounded
<loki666>
but I'll need a better iron
<loki666>
do we have a chatty uboot for A133 I can flash ?
<jernej>
apritzel: sure, but I need to wrap around my head beforehand and check Apple/STM32. No point of having one off driver, if we want Apple/STM32 way.
<apritzel>
loki666: what's the DRAM on this board? DDR3? LPDDR4?
<loki666>
let me check
<apritzel>
jernej: no worries, take your time. I guess LinusW will reply anyway next week, and we have some time now till this would get merged anyways
<loki666>
if zero28 is as zero40, 2gb LPDDR4
<loki666>
there is no specs yet for zero28
<apritzel>
loki666: without an image it's hard to know the exact DRAM parameters, but I could build you some A133 LPDDR4 image, though only later today (need to run now ...)
<loki666>
no rush, I still need to solder on the pads
<apritzel>
or you build something yourself based on the A133 series I posted two days ago, but that's missing DTs and defconfigs ...
<loki666>
Ok I'll check
apritzel has quit [Ping timeout: 480 seconds]
BroderTuck has joined #linux-sunxi
<BroderTuck>
loki666: 'sunxi-fel spl bin/uart0-helloworld-sdboot.sunxi' (from sunxi-tools) should spit out two lines of text, that should be a start at least
<BroderTuck>
jernej: really looking forward to something to test
jernej has quit [Read error: Connection reset by peer]
jernej has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Read error: Connection reset by peer]
jernej has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
BroderTuck: loki666: yeah, my A133 tablet uses secure boot, and FEL does not work nicely there, so I couldn't really test those old sunxi-tools patches well
<apritzel>
But I now have a proper devboard, so will send a PR soon
<apritzel>
just the usual problem: we have a massive review backlog :-(
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<maz>
apritzel: a raxda thingy unexpectedly landed on my doorstep this morning. doesn't look bad, but I don't think there's anything useful working on that yet, right?
<apritzel>
maz: well, it's work in progress. Basic Linux patches are on the list since November, jernej has a somewhat working TF-A port (since this week), and U-Boot/DRAM works now as well.
<MasterR3C0RD>
loki666: Is this the board you had sent the BSP for?
<apritzel>
maz: I got the same thing yesterday, and tried to boot it with the DRAM parameters extracted from that hideous BSP image, but to no avail. But I think I saw it working with the Avaota config
<apritzel>
maz: I can provide you with a combined SPL/TF-A/U-Boot binary hopefully later this weekend, which should be good enough for any kernel experiments
<MasterR3C0RD>
loki666: If so, and assuming the U-Boot configuration is correct, your device has DDR4 memory
<maz>
apritzel: if you add a bit of documentation that I can follow to slap it on this thing, that'd be perfect.
<maz>
apritzel: I guess there is no TRM either?
<maz>
(hint, I need PCIe)
<apritzel>
maz: I knew you would say this, was about to type something ;-)
<apritzel>
the combo PHY doesn't look too complicated, like two bits to change the mux
<MasterR3C0RD>
apritzel, maz: Is that the Radxa Cubie thing that was posted about on the old Google mailing list?
<apritzel>
MasterR3C0RD: yes
<apritzel>
maz: but the BSP code has some more clock code associated
<MasterR3C0RD>
That should be on the way for me as well; we'll see when that ends up arriving on my side of the ocean
<apritzel>
maz: we do have a "user manual", which is pretty detailed, I'd say
<apritzel>
maz: if you can convince Tom Cubie to publish the schematics, everything would be much easier. Atm I am about to do the usual guess/trial-and-error the PMIC rails
<apritzel>
he mentioned some GPIO to switch between USB3 and PCIe, so that's board specific. Not sure that is too practical, though, I'd rather expect a switch or jumper on the board
<maz>
I don't think I carry much weight, unfortunately. I can always fire an email.
<maz>
the amlogic thing that just died on me had a similar switch, GPIO driven.
<apritzel>
so that a *user* flips a hardware switch when they put in an NVMe
<apritzel>
since that's not hotplug anyway, I am not sure how useful a software controlled switch is, really
<maz>
yeah, there is a u-boot config to do that.
<apritzel>
maybe we can probe for a PCIe device, then flip the GPIO and alter the DT, in U-Boot?
<maz>
you can't probe PCIe, since this is the same lines that are used for both.
<maz>
you'd need to have some kind of presence detection, but this is usually implemented by the link training.
<maz>
chicken and egg.
<apritzel>
well, not safely, in general, but maybe there is some quirk or something we can use. For instance if the USB has a separate VBUS control, we can turn that off, then try to bring up PCIe, and check config space
<apritzel>
or somehow detect that something is in the M.2 slot (some pin grounded or so)
<maz>
maybe. seems fragile and complicated though. I very much like the idea of having PCIe, and only that (I can happily add USB3 back on a PCIe card)
<apritzel>
thought about this as well
<MasterR3C0RD>
The fact it's muxed seems strange to me; are they using an external PCIe-USB bridge?
<apritzel>
are there adapters that fit in 2230?
<apritzel>
MasterR3C0RD: aside from some electrical details, the PCIe and USB3 protocols are very similar, so they share a PHY (and pins)
<MasterR3C0RD>
On the adapter side, think the usual trick would be using an adapter that lets you connect a full PCIe device to it; that's what people do with Raspberry Pis at least (i.e., Jeff Geerling)
<maz>
I'
<apritzel>
that's what maz just pointed to, I guess
<maz>
I've been doing that for years. add a switch, and you can havve a collection of (slow) PCIe devices.
<apritzel>
that's piggy backing on this U.2 standard then, to connect 2.5" SSD via NVMe, as seen in servers? ... And my good ol' TX2 at work ;-)
<maz>
apritzel: not quite. the oculink thing is a bit different from the U.2 cabling. but that's the general idea. my amlogic crap works using USB3 cables carrying a single lane of PCIe down to a 4 port switch.
<apritzel>
MasterR3C0RD: I think AW's idea was that the board vendor decides: OrangePi chose M.2 2280, most other vendor went with USB3.0
<MasterR3C0RD>
The silly thing here is I don't see on the wiki page what GPIO is used for switching between USB and PCIe
<apritzel>
MasterR3C0RD: yeah, there are a lot of details missing about this board
<apritzel>
for instance the PMIC rails, how the POE thing is supposed to work, and this USB3/PCIe switcheroo magic
<apritzel>
a schematic would clear most of this up rather quickly
<apritzel>
given that it's supposed to be a community friendly dev board, I am quite hopeful we get this rather sooner than later
<MasterR3C0RD>
Really strange for a development board to not even have proper documentation; the website has empty pages for Downloads/Support, not even linking to the wiki article, so I have no idea what they're even really thinking here
<apritzel>
I agree
<apritzel>
also those BSP build instructions are abysmal, I am so tempted to delete all that crap from the wiki, and replace it with links to out WIP repos ...
<MasterR3C0RD>
Also your reply to their email was very well worded as well; I don't know if you noticed but the link to the Allwinner CEO's "open source contributions" was a set of 5 commits that simply updated a readme file
<apritzel>
s/out/our/
<apritzel>
MasterR3C0RD: yeah, I saw that, that was my first disappointment ...
<jernej>
apritzel: there is separate link for radxa specific board settings, which includes DRAM parameters and dts file (which has some pmic info)
<apritzel>
jernej: ah, thanks. I just downloaded the beginning of this image, then extract the DTB and boot0. Let me try this info instead
bauen1 has joined #linux-sunxi
<jernej>
apritzel: so 2 GB version is similar enough to work with avaota settings although skew time is slightly different, so it might have some stability issue.
<jernej>
other fex shows pretty different settings, so I highly doubt it will work
<apritzel>
yeah, there is so much conflicting and sometimes pointless information everywhere, that's why I usual look at working images and extract info from there
<MasterR3C0RD>
Other fun: wiki says it uses a Maxio PHY, but DT has a comment stating RTL PHY. WiFi on the other hand uses a long name for what might just be the AIC8800
<apritzel>
for instance one the .fex files in there says "evb1", which more points to some internal prototype devboard than this particular board
<apritzel>
it's definitely a MAXIO PHY, but warpme figured it (partly?) works as a generic IEEE802.3-c22 PHY
<jernej>
there is a driver for maxio phy
<apritzel>
The WiFi name is different because that's a *module* from some vendor, internally using the AIC8800, but with more hardware around it. Seems pretty common
<jernej>
in some rk bsp drop
<apritzel>
jernej: where? in mainline?
<apritzel>
ah ... :-(
<apritzel>
yes, we found a MAXIO driver in some AW code on github as well (the X96QPro+ uses this as well), but it's the usual BSP quality (#ifdef'ing stuff that breaks other PHYs and such)
<MasterR3C0RD>
Can't find much more information about it anywhere, of course
<apritzel>
They misspelled the vendor name, it's "LB-LINK"
<apritzel>
not that it helps you much, but at least you can read the module vendor's sale brochure ;-)
<MasterR3C0RD>
Of course, what would we do without a sales pitch?
<jernej>
apritzel: It seems I'll need to parameterize MR14 for DRAM, since it's some voltage setting
jernej has quit [Quit: Konversation terminated!]
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.6, revision: 5.2.6+git-7609-afed1336e, build type: debug, sources date: 20160102, built on: 2024-12-18 20:43:05 UTC 5.2.6+git-7609-]
jernej has joined #linux-sunxi
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
Ixnus has joined #linux-sunxi
megi has quit [Quit: WeeChat 4.4.4]
megi has joined #linux-sunxi
<loki666>
so I'm going to try to have a basic buildroot env for my A133P board
<loki666>
where are the atf, and uboot branches I can hope to works ?
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
<loki666>
on a sperate topic, I'd like to enable a gpio controlled led asap in u-boot proper for the H700 boards (not to be upstreamed ofc), could I have some pointer on where to do that ?
<MasterR3C0RD>
loki666: For ATF, you can build from latest master branch with the `sun50i_h6`, though note it only does enough to boot, and won't set up SMP
<MasterR3C0RD>
Mainly because it has newer DRAM code
<loki666>
ok thanks, I'll see how that goes, I understand kernel is WIP, dts WIP so I shouldn't expect much more
<loki666>
for u-boot I'll also need a dts...
<loki666>
I mean a defconfig
<loki666>
and a dts
<apritzel>
DT in U-Boot is the same, literally: it's now dts/upstream/src/arm64/allwinner
<loki666>
yes but I just can't pull a dts from my hat... so without a running bsp, I'll go nowhere right ?
<loki666>
ah but MasterR3C0RD found the dts in the SDK, I'll dig in that mud
<MasterR3C0RD>
That DTS will not work at all with mainline
<MasterR3C0RD>
You can potentially use it as a reference but I wouldn't be too hopeful that voltage rails and such are correct
<loki666>
yes that was the idea...
<loki666>
I think I see a AXP717
<loki666>
and unless the second one is very small, I don't see another, maybe that's why they limit to 1.8Ghz
<MasterR3C0RD>
I doubt it; do you have UART?
<loki666>
not soldered yet, but I think I identified the pads
<loki666>
my miopia wife confirmed the AXP717
<apritzel>
loki666: please forget about this BSP DT. You can look in there, but you will find conflicting information in there, or none at all
Schimsalabim has joined #linux-sunxi
<loki666>
apritzel: I know I saw the mess of the h700, but there were still usefull info on GPIO
<loki666>
not very usefull now... but
<BroderTuck>
www.palvencia.se/Datasheets.zip (won't keep this for long, just long enough for someone to grab 'em and decide what deserves to be on the wiki)
<BroderTuck>
(from that far too big download on the radxa page=
<apritzel>
maz: do you know if we can make use of PCIe's #CLKREQ signal for card detection? Looks like the device pulls that down to request the host to push the clk? So that would be floating without a card in?
<MasterR3C0RD>
At least looking through some more documentation I wouldn't see why it couldn't work; I think the process would be bring PERST# ("fundamental reset") low to high, then checking if CLKREQ# is being pulled low
<MasterR3C0RD>
s/wouldn't/can't/
<MasterR3C0RD>
Ah wait no PERST# would be brought low, and then CLKREQ# would be checked
<apritzel>
BroderTuck: ah, many thanks, that's from that big SDK package?
<MasterR3C0RD>
Too bad there's no docs for the NPU
<MasterR3C0RD>
Ah, but there's a hint! It states that it supports Vivante vendor extensions
<BroderTuck>
apritzel: yes. MasterR3C0RD There are some files in chinese in there that I could upload, hang on.
<MasterR3C0RD>
Also if you see anything about the Maxio PHY that would be great as well
<apritzel>
the whole NPU thing was already Greek to me :-)
<BroderTuck>
There are more chinese-only files, these are the ones I found most interesting
<MasterR3C0RD>
apritzel: Now it's Chinese :))
<MasterR3C0RD>
Actually these appear to mostly be development guides showing how to use the BSP
<MasterR3C0RD>
Ahhhh I see where the mention of the RTL PHY came from... it's an example in the documentation for how to set up the "GMAC200" with an external PHY
<BroderTuck>
Some SoCs mentioned in these chinese doce: AI985 H137 and the V821 someone posted a pic of earlier