Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
ing_warn__ has joined #linux-sunxi
ing_warn_ has quit [Ping timeout: 480 seconds]
<Soupborsh>
I have dts extracted from device from /proc/device-tree, which one should I use?
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<Soupborsh>
* I use? They differ
gsz has quit [Ping timeout: 480 seconds]
<Soupborsh>
* I use? They differ, especially in dram config.
BroderTuck has joined #linux-sunxi
<BroderTuck>
Soupborsh: 1st: I saw that the dram values you postad a few days ago extracted from a boot0 didn't match the numbers from the fex you postad a day or so later. Does the values from the /proc/ dts match the boot0 values?
<BroderTuck>
2nd: That /proc/ dts is probably the allwinner version of a devicetree file, and not directly usable with a mainline kernel/u-boot. It should still contain valuable info, tho.
<Soupborsh>
BroderTuck: Yes it same as values under A64.
<apritzel>
Hey Soupborsh, sorry to disappoint you, but you cannot take BSP code and try to use it for mainline easily: they are very incompatible, especially for those older SoCs
<apritzel>
they way to go is to copy from a mainline supported SoC, I'd recommend the H3, and then adjust some parameters and values according to the information you gathered from the BSP
<apritzel>
BroderTuck: Soupborsh: is there any BSP code for the regulator? Chances are it's a close relative to something existing, and comparing registers would help finding the match
<apritzel>
thanks, so it looks like the AXP221 is then probably compatible, at least mostly
<electricworry>
Dumb question that's been bothering me. I'm currently getting into the swing of hacking away at drivers for a couple of boards, and of course I'm relying heavily on early boot output. How does one know what console to set when targetting a new board? e.g. console=ttyS0,115200.
<apritzel>
I see the AXP223 being almost the same as the AXP221, just with the USB power supply part being different. I'd hope the situation is the same
<apritzel>
electricworry: for serial ports we have aliases in the DT, and by convention on most (modern) Allwinner SoC UART0 (aka ttyS0) is the debug UART
<apritzel>
the developers could pick any other UARTs, some older boards used UART2, for instance, but mostly we find BSP code using UART0 these days
<apritzel>
electricworry: and what do you mean with "hacking ... drivers for a couple of *boards*"? We write drivers for a certain SoC, and then just reference them per board
<electricworry>
Explain myself: I've been dabbling for a few months with how to write (or improve) drivers for a couple of OrangePi boards. Many people on here are doing more than I can and faster. I'm currently just trying to learn how to write drivers. And for that I sometimes look at the BSP kernel that came from Allwinner, sometimes look at the mainline effort you have all been working on,
<electricworry>
and sometimes I'll take work people are doing on Armbian.
<electricworry>
And I make changes and dump various structs so I can understand what's going on between the kernel and the device buffers.
<apritzel>
which drivers and which SoCs, exactly? I guess some coordination would be a good idea, and be it to avoid disappointment on your side
<apritzel>
and btw: "learn how to write drivers" and "looking at the BSP kernel from Allwinner" DO NOT go together
<electricworry>
No disappointment on my side. I'm learning. You have no idea what a massive learning curve this has been for me, and you absolutely do not want any of my code yet. I'm just trying to learn at the moment.
gsz has joined #linux-sunxi
<apritzel>
well, we could help you quite a lot with this effort, and provide some guidance and speed up the process
<apritzel>
but digging around in Allwinner code will mostly teach you the wrong things
<apritzel>
if you give a rough idea on what you are working/learning on at the moment, we could guide you, and give you a much better experience
<apritzel>
for instance there are quite some open things on the H616 or A523, we we could use some help. Some parts are easy, some are tedious (but not necessarily complicated)
<electricworry>
apritzel: I know what you mean - you mean the state of the code isn't good. But from a perspective of understanding the hardware (i.e. what MMIO registers to poke to achieve something) is it not sometimes easier to look at the Allwinner BSP which just gleefully does that thing rather than study the normalised mainline code which may involve jumping around many more .c files?
<apritzel>
yes, the mainline kernel is not good for this. Typically I'd recommend mainline U-Boot code, which is much simpler structured
<apritzel>
but for most peripherals we know the register bits, as we have user manuals
<apritzel>
there are a few undocumented devices, but not that many - hence my question about which ones specifically
<apritzel>
also sometimes you find some devices documented in other SoC's user manuals
<electricworry>
I've ostensibly got the manuals too... But there's a lot missing. e.g. the H616 manual and datasheet completely say nothing about the display. It's almost like there are separate books that are required. OR that Allwinner don't provide documentation and just provide the BSP and say "there you go!".
warpme has joined #linux-sunxi
<electricworry>
Mainly what I'm building towards is to write something baremetal for an OrangePi Zero 3 (H618) board. I think this is a good challenge for me as I'll need to 'reverse' the existing drivers to some degree to understand what they're doing to make the hardware work. And to get there I need to be able to *read* the drivers.
<electricworry>
I think if I can get to that point, I'll be more confident about contributing to drivers that do need improved or created.
<electricworry>
Yeah I found that. All gibberish to me. I don't know what's meant to be written to a CSC coefficient 10 register. Which is why I'm stepping through drivers to see what is actually being done by the BSPs.
<apritzel>
and this is where we could use your help: this series is blocked because of no review. So if you dig in *to this* code, you could help us out
<electricworry>
That's cool. Thanks for the link! So what is it you think I could do here for you? Bear in mind I'm a driver novice and I look at that patch series and don't know what's going on. Are you suggesting that I apply the patches and *test* it? Or are you suggesting that I *review* it and make suggestions or sign it off?
<apritzel>
the most helpful would be to dig into *that* code, and where it connects and lead to, and confirm that it makes sense
<apritzel>
I do understand that mainline Linux code is not the easiest to understand (see above), but it's by far the most useful, and really the only one that really matters
<apritzel>
I have no experience with the graphics stack, so I tried to do that, but don't find enough time to follow through with that
<apritzel>
the patches are nicely split, so you could tackle one at a time, and find out what everything means (for instance CSC)
<electricworry>
And this is where I think my current capabilities are being overestimated. If you would like to provide some guidance I would be happy to try and help. But currently I look at a driver and I think, well that's a lot of structs that mean nothing to me.
<BroderTuck>
I know this would be a tangent, but maybe see if you could update https://github.com/catphish/allwinner-bare-metal from H3 & DE2 to H616 and DE33. That would then be good as a test for the H728 DE code :)
<apritzel>
well, to be honest anything from the graphics stack is probably the worst start for understanding drivers or learning about Linux in general
<electricworry>
@BroderTuck. Yeah I found this before. I think updating this for H616/H618 DE33 would be a very good exercise. It helps that some of the 'magic' has been done for DE2 already.
<apritzel>
for instance PWM might be a much simpler target
ftg has quit [Read error: Connection reset by peer]
<electricworry>
I really appreciate your recruitment attempt, but I think I need some more time trying and failing in my own way. I'm slowly getting better an I will be back to help when I'm at a better level.
<electricworry>
Back to my original UART question. If the dtb has an alias "serial0" for serial@5000000 (which it does) then is that why I need console=ttyS0,115200 in the cmdline? Or is that a coincidence?
<apritzel>
I am not sure I fully understand the question. You connect your serial cable to certain pins - that's your debug UART then
<apritzel>
and then you know which UART those pins respond to, and that's the number you need to give to the command line
<apritzel>
you could as well pick any other UART which is exposed on the OPi Zero3 headers, for instance, and then use this
<apritzel>
if you need a simple answer to your question: use UART0, which is the mostly used debug UART for the H616, and exposed either on headers, or on separate pins
<apritzel>
for instance inside those H618 TV boxes
<apritzel>
also U-Boot and Trusted-Firmware configure a certain UART, which is UART0 by default for the H616
<apritzel>
electricworry: I am sorry if this more confusing than helpful, but I don't really know where you start with your question ;-)
<apritzel>
if this is just about the numbers used in Linux: the serial0 alias determines which UART will become ttyS0
warpme has quit [Ping timeout: 480 seconds]
<electricworry>
Thanks!
<apritzel>
if you don't give that, the kernel will assign this randomly, which is mostly not helpful
<electricworry>
You figured out my query. :) Time for bed for me (maybe via a whisky). I appreciate your time!
<apritzel>
yw
<apritzel>
electricworry: in the future you might find it helpful to post questions that nag you for days here
<apritzel>
can anyone with contacts to OrangePi nag them to release the schematics for the OrangePi 4A?
warpme has joined #linux-sunxi
<apritzel>
that looks like a nice board, but without schematics it's painful to create a DT
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
<BroderTuck>
Well, bedtime for me as well.
BroderTuck has quit [Quit: -]
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
<apritzel>
BroderTuck: thanks for all your help, btw!