<tokyovigilante>
Real Engineering - The Insane Engineering of the Gameboy
<apritzel>
tokyovigilante: no, please have the three DTs that describe each different device. The DT describes the hardware, so describing buttons that are not there is no-go.
<apritzel>
and more prominent the USB port - even if it is non-fatal to use a different DT
<apritzel>
since there is no fixed storage, and having one SD card image for all three is indeed tempting, we can try to come up with some different solution
<apritzel>
like having DT overlays and detecting and applying the right one in U-Boot
<apritzel>
but for the DT directory in the kernel tree we should go with three separate .dts files
macromorgan has quit [Read error: No route to host]
macromorgan has joined #linux-sunxi
<tokyovigilante>
yup, shared image was the reason I was thinking. Happy to leave separate though
<tokyovigilante>
I am finding these regulators pretty tricky, better for my understanding at least to remove all but known essential and add, rather than trying to push them all in
<tokyovigilante>
also, feel like they are arbitrarily split between being defined under the axp node, and the root device node?
<apritzel>
how so? GPIO and fixed regulators go under the root node, since they have no "parent bus"
<apritzel>
the AXP regulators need to be inside the AXP717 regulator node, since only this driver knows how to reach each regulator
<apritzel>
and the AXP regulator node itself needs to be inside the RSB node, since only that driver knows how to access the AXP registers (via the RSB bus)
<tokyovigilante>
ok thanks, that clarifies it a bit
<apritzel>
in general addressing DT children is the responsibility of the DT parent device, and some devices might use a very specific and different addressing (like I2C or RSB), compared to all those MMIO mapped devices
<apritzel>
in case they are mapped like their parent, you use the "ranges" property, example is the "soc" bus in sun50i-h616.dtsi
<apritzel>
we everything that is neither MMIO or device mapped, we use the root node, examples are CPUs, the system register driven timer and PMU, and fixed clocks and regulators
ftg has quit [Read error: Connection reset by peer]
<tokyovigilante>
macromorgan: how sure are you about CLDO3 supplying the SD1 slot?
ynezz has quit [Remote host closed the connection]
ynezz has joined #linux-sunxi
ynezz is now known as Guest1350
apritzel has quit [Ping timeout: 480 seconds]
<tokyovigilante>
macromorgan: do you also have the gpadc node for the SoC?
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
vickycq has joined #linux-sunxi
nickAA has quit [Quit: Leaving]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
nickAA has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
freemangordon has quit [Ping timeout: 480 seconds]
ity has quit [Remote host closed the connection]
ity has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
smaeul has quit [Ping timeout: 480 seconds]
freemangordon has joined #linux-sunxi
smaeul 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]
Schimsalabim has joined #linux-sunxi
Robot_ has joined #linux-sunxi
<warpme>
apritzel: do you have working sharing emmc to PC via uboot ums? If yes - may you pls give what: uboot ver, PC kernel ver, PC OS you are using? On my current Fedora with 6.8.4 kernel I'm constantly getting in PC dmesg "device descriptor read/64, error -71" then "usb 1-3: Device not responding to setup address."
szemzoa_ has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
dsimic is now known as Guest1398
dsimic has joined #linux-sunxi
mkf has joined #linux-sunxi
Guest1398 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
vpeter has quit [Remote host closed the connection]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
<mkf>
hi.
<mkf>
i'd like to learn writing drivers and porting OSes to various SoCs, i was wondering if H618 is a good platform to start doing so.
<mkf>
or there is a better SoC i can use which is easier to write drivers for.
<apritzel>
mkf: regarding Linux drivers for the H616 (and friends): most low hanging fruits have been picked, and while there are drivers missing still, they are either not easy to do or they have already progressed quite a bit
<apritzel>
if you look at porting OSes: it seems like the BSDs don't have H616 support at all (last time I checked), they stopped at H6
<mkf>
yeah, openbsd have barely got h616 features (clock and gpio i think) in last release
<mkf>
i'd like to either port plan 9 to it or write more drivers for netbsd/openbsd, which both lack basic support at all.
JohnDoe_8 has quit []
vpeter has joined #linux-sunxi
<libv>
mkf: why not just try to install a linux on $hardware and fix bugs?
<apritzel>
mkf: wow, plan 9 ports look ridiculous (supporting a handful of older Arm boards only, apparently, and no sign of DT anywhere?), so I wouldn't recommend that
JohnDoe_71Rus has joined #linux-sunxi
<mkf>
libv: i'm not a linux person, and harder problems have been solved there. :)
<libv>
bugs are there harder problems, the word bugs does not seem glamorous enough to you
bauen1 has quit [Ping timeout: 480 seconds]
<Jookia>
mkf: all socs are around the same driver wise i'd say. porting linux drivers to other platforms can be fun :)
<Jookia>
the best soc to work on is the one attached to the board you want to use
<Jookia>
just be warned that linux drivers tend to be GPL so if that bothers you i would only use them as information about WHAT the driver does, not HOW
<Jookia>
often drivers include important facts not in the datasheet
vagrantc has joined #linux-sunxi
bauen1 has joined #linux-sunxi
<Jookia>
plan 9 isn't on the device tree train? oof
<Jookia>
people who run plan 9 sure confuse me sometimes
<jakllsch>
tbf, the device tree train kinda sucks if you aren't linux
<jakllsch>
linux likes to change up the device trees for some SoCs on a whim, and it can mean rewriting a lot of stuff for a SoC
<jakllsch>
this is especially problematic when try to sync your DTs with Linux for some new SoC, and your old device support breaks if you aren't careful
<Jookia>
is there something better than a device tree?
<jakllsch>
probably not, unless it's a OFW firmware-provided device tree that never changes once the hardware ships
<Jookia>
xboot uses some JSON thing
<apritzel>
jakllsch: we try to do this lately for sunxi: DTs become ABI, and we cannot change things in an incompatible way
<jakllsch>
good
<apritzel>
hence my constant recommendation to just use the DT in the U-Boot image, which we update regularly
<Jookia>
yeah i was under the impression DTs were ABI now? there's a whole DT mailing list
<Jookia>
apritzel: do you mean passing the DT to Linux?
<apritzel>
it's hard to do, though, and historically the decision about the level of compatibility was left to the platform maintainers
<Jookia>
right now my setup has a linux dt and uboot dt
<apritzel>
Jookia: yes, you should not load a DT in U-Boot, instead just pass $fdtcontroladdr to booti/bootz/bootefi
<Jookia>
interesting
<Jookia>
i was under the impression u-boot dts were heavily stripped down
<Jookia>
that said the last time i tried to do pass a dt from u-boot to linux was like 2015
<apritzel>
they *could* be, since U-Boot uses only a small subset of devices, but they are in fact regularly synced from the kernel tree
<Jookia>
things have changed a lot since then
<apritzel>
actually mainline U-Boot just very recently introduced a git submodule of the DT rebasing repo, which is a DT-only mirror of the kernel tree
<apritzel>
we will probably switch over to this at some point, but I would first like to see how this plays out
<Jookia>
i put so much effort in to making a nice fit with kernel dt though...
<Jookia>
oh well
<apritzel>
Jookia: what do you mean?
<Jookia>
i had to write a script and create an its file for buildroot to pack a kernel image and dtb in to a FIT for loading
<apritzel>
ah, FIT. Yeah, sounds like 2015 ;-)
<Jookia>
isn't FIT the current way to do things?
<Jookia>
i just moved from zImage :(
<Jookia>
i'm under the impression you need FIT images for secure booting
<apritzel>
FIT is not really used for distro booting, but it's indeed useful for combining multiple images or blobs into one file, and that includes certificates
<apritzel>
in any case: don't use a separate DT for the kernel
<Jookia>
this isn't distro booting, it's a pretty custom boot flow. but being able to change the dt just by rebuilding uboot and booting it over USB would be a lot easier
<apritzel>
yes, that's what I do
<Schimsalabim>
I got some really minor changes to dmic code (sun50i-dmic.c) to add controls for the gain stage (4xRL) which seem not to be in the code yet. what would be the proper path to getting them into mainline ?