flyback has quit [Remote host closed the connection]
flyback has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
hexdump02 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
chewitt has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
lschmid has joined #linux-sunxi
<lschmid>
Hi everyone. Is it possible that gpio-hog in U-Boot is off-by-one? I'd expect '3' to be PD which it is under Linux but in U-Boot it's PC...
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
buZz has quit [Remote host closed the connection]
buZz has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.7.1]
<apritzel>
lschmid: are you referring to U-Boot's GPIO driver parsing the gpio-hog DT property?
tlwoerner_ has quit [Ping timeout: 480 seconds]
tlwoerner has joined #linux-sunxi
<apritzel>
lschmid: to me it looks like U-Boot's gpio-hog code cannot cope with 3 #gpio-cells at all, it reads two cells from "gpios", and interprets them as index and flags
Schimsalabim has joined #linux-sunxi
<lschmid>
apritzel: Yes I am. It's weird then, because when I changed the first digit from 3 to 4 it did go to PD correctly...
ftg has joined #linux-sunxi
<apritzel>
what's that hog for anyways? that's a new thing, appearing in v6, right?
<lschmid>
Yes. Due to the FEL-Bug/Backdoor the SoM has a USB-Mux that shall only enable the USB-OTG port when authenticated software is running. So unless one has hardware access and can modify the module the fel is unusable
<lschmid>
It effectivly disconnects the OTG data lines until the BootROM has loaded U-Boot and therefore is running an authenticated image
<apritzel>
mmh, using those usb-hogs is always a bit hacky
<lschmid>
What way would you recommend doing this then? I need the kernel and u-boot to just enable the pin and then never touch it again (unless somehow required by the user)
dsimic is now known as Guest25393
dsimic has joined #linux-sunxi
Guest25393 has quit [Ping timeout: 480 seconds]
<apritzel>
there is gpio-mux.yaml
<apritzel>
I guess the whole things it bit odd and unusual solution
<apritzel>
what's that "FEL-Bug/backdoor", exactly?
cnxsoft has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
<wens>
blah, can't get the dma controller to work
juanesf91 has joined #linux-sunxi
<juanesf91>
Wens: I have a Cubie A5e with an A527. When I get home, I'll try the PRCM/NPU patches.
apritzel has quit [Ping timeout: 480 seconds]
hazardchem has quit [Read error: Connection reset by peer]
<Jookia>
my kernel tree supports fractional N sdm stuff automatically now, see the commit history from today to see how it works
<apritzel>
wow, that's quite a read ;-) From skimming over it, that touches some things I was wondering about lately as well (like missing constraints or CLK_SET_RATE_PARENTs)
<apritzel>
so what are your upstreaming plans? I guess you could start with the simple things, like the two things I just mentioned
<apritzel>
let's be clear: I believe there are quite some bugs and shortcoming in the sunxi-ng code, I just discovered some of them this week
<apritzel>
and especially the fractional SDM code is barely working, as you figured
<Jookia>
i think getting a good solution would require moving the entire kernel to use 64-bit rates
<Jookia>
the kernel is not in a good place for fractional rates
<apritzel>
Jookia: so why not just send that patch? I feel like this is a clear fix, and would be taken quickly. Maybe would help to restore your faith in upstreaming
<Jookia>
most of my documentation applies to any MPU that needs to do fractional clocking, such as stm32 too
<Jookia>
the allwinner sdm turns out to be just another case of 'we put the fraction in a register'
<apritzel>
absolutely!
<apritzel>
is some fixed point arithmetic
<Jookia>
but there's a lot of problems with the kernel doing rounding on rounded rates and accumulating error, and being unable to show error for a rate
<Jookia>
so we can't really get sub-hz accuracy
<apritzel>
and those TODOs and XXX in the SDM/frac code show that this wasn't understood back then, I think
<Jookia>
the documentation for the sdm clocking was only put out in the h616 manual i think
<apritzel>
common AW issue: sometimes bits of info appear in some random SoC manual, giving us aha! moments ;-)
<Jookia>
apritzel: the short answer is that sending patches is an extremely stressful experience and i'd rather just not
<Jookia>
besides, i have a t113-s4 board on my desk. that looks like a lot more fun
<apritzel>
well, that experience depends quite a lot on the nature of the patches
<Jookia>
i have very high email patch sending anxiety
<apritzel>
in case of this patch and stuff like _SUNXI_CCU_MULT_OFFSET_MIN_MAX I am happy to do reviewing, and have the feeling that wens has a happy trigger finger on merging them
<Jookia>
i'll put it on my list of things that i would like merged :D
<Jookia>
the code is public and documented and it isn't going anywhere, neither are the commits
<apritzel>
exactly the problem: it's not going anywhere
<Jookia>
this week (next week maybe?) i'm going to try getting the t113-s4 going with the forks i have
<Jookia>
does anyone actually know what these chips are? i'm guessing they're just the t113-s3 with different RAM
<apritzel>
yes, we are pretty sure of that one: -s meaning on-
<apritzel>
yes, we are pretty sure of that one: -s meaning co-packaged DRAM
<apritzel>
and 3 meaning 128MB, 4 meaning 256M
<apritzel>
does the U-Boot DRAM code work out of the box?
<Jookia>
hmm. the chip manufacturer is not allwinner from what i can see, and apparently it has a c906?
yang2 has joined #linux-sunxi
<Jookia>
i haven't even touched the board outside booting the vendor BSP
<Jookia>
i kind of spent 3 months on that clocking deep dive
<Jookia>
a quick week long clean-up of my old patch
<apritzel>
yeah, judging from that text I was suspecting this was some serious effort
<Jookia>
i haven't tested it it on any other boards like the a20
<apritzel>
and honestly this is how Open Source works: for some odd reason someone emerges themselves in the code, and comes out as an expert
<Jookia>
yeah, that's the easy/best part
<Jookia>
i like learning and discovering things
<apritzel>
and ideally feeds that back to the community, by sending patches, reviewing, and contributing in general
<Jookia>
i not good at all with the people/community part
<Jookia>
i'm*
<apritzel>
tbh, most Linux people are more on the nerdy/unsocial side ;-)
<apritzel>
but for that patch for instance I guess it would literally just a "git send-email"
<Jookia>
the unsigned one?
<yang2>
Hello, I am looking at the page of LeMaker BananaPi M1, and I am interested how to plug the serial pins on it for establishing the UART connection? I am looking at the diagram, I have the Olimex F-serial cable with 3 R/G/B pins
<Jookia>
yang2: see https://docs.banana-pi.org/en/BPI-M1/BananaPi_BPI-M1 ? the gpio pin define shows a 26-pin header, on the right column you have GND, UART-TX, UART-RX. black goes to GND, green to uart-tx, red to uart-rx. plug it in and try using screen or picocom with a baud of 115200. if that doesn't work try switching the green and red wires
<yang2>
thanik you !!
<yang2>
thank you
<Jookia>
that might not work, you might want to also try both combinations with baud 9600
<yang2>
i usually use "tio"
<Jookia>
oh that's cool
<yang2>
previously I used screen, but getting better results with tio
<apritzel>
I am happy with picocom
<yang2>
Jookia: I am looking at the diagram, there are multiple GND's I guess the one I use is no. 6 GND on the right side
<Jookia>
yang2: any should work but yes :)
<yang2>
ok :)
<yang2>
Jookia: I have red-green-blue pins
<yang2>
so the blue is GND
<Jookia>
blue?
<yang2>
yes
<yang2>
on the wire
<Jookia>
the page for the f-serial says black
<apritzel>
there are indeed some pictures with a blue wire
<juanesf91>
If the A527 doesn't actually contain both the NPU and the DSP, would it be necessary to make a separate DTS? According to the datasheets, the A523 only has one Ethernet controller, unlike the A527 and T527, which contain both. Something similar to V3/V3S/S3.
<apritzel>
juanesf91: no, at least for the EMACs: the die always contains both, it's just one not being connected to any pins on the A523 package
<yang2>
apritzel: hmm, i see the U-boot boot on HDMI monitor, but nothing on the serial
<yang2>
trying to switch the red and green now
<apritzel>
juanesf91: so we just naturally not reference them on any A523 *board* DTS, same as we would do on boards without Ethernet sockets
<apritzel>
juanesf91: so I guess for the NPU and DSP it's now a matter of finding out if they are just not advertised or marketed, or if one or both of them are actively disabled/fused off or something
<juanesf91>
In this case, the NPU node was added to the DTSI, so the injection was executed automatically. I didn't have to enable it in the DTS of the Cubie A5e.
<apritzel>
yang2: ah, if you see U-Boot on HMDI, you should see something on the UART as well, at least with mainline U-Boot
<apritzel>
juanesf91: yes, in case of NPU (and DSP): the IP is internal, there are no pins, so there is no reason to not enable them
<apritzel>
given that the IP is really there, which we are about to find out now, I guess
<apritzel>
juanesf91: think about it as a scientific experiment: you have a theory, and conceive an experiment to prove or falsify it ;-)