<apritzel_>
wens: jernej: any plans for the A523 DT patches? I see the clk patches in -next (many thanks for that!), and pinctrl should appear there tomorrow, I guess (LinusW merged it into his for-next today)
<apritzel_>
does that depend on some binding patches going through other subsystems?
Hypfer has quit [Read error: No route to host]
Hypfer has joined #linux-sunxi
szemzoa has quit []
szemzoa has joined #linux-sunxi
cnxsoft1 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
warpme has quit []
vagrantc has joined #linux-sunxi
chewitt has joined #linux-sunxi
gsz has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<sdfgsdfs>
apritzel, thanks
<sdfgsdfs>
so this means there are A100s with memory configurations > 4GB, yet the mmio registers still remain 32 bit
<sdfgsdfs>
lol
warpme has joined #linux-sunxi
<sdfgsdfs>
hrmm, on pee cees, reading the hard drive with int 13h ax | 40h EDD extensions, the i/o request packet is a quadword
<sdfgsdfs>
maybe this way is better since it doesn't change register offsets
<wens>
apritzel_: bindings have to go in first, otherwise we'll start getting validation error emails :(
<wens>
and since you did one big patch for the whole .dtsi, that probably means we have to wait for all of them, or at least the ones that have accompanying driver changes
warpme has quit []
<sdfgsdfs>
i didnt want to set up a cross compile toolchain so i figured i'd build the kernel on the sbc itself on a "kootion" branded sd card. do you think it will survive?
<apritzel_>
wens: I see the MMC, USB, USB PHY, I2C bindings in next already, plus clk now, pinctrl hopefully tomorrow. the NMI binding is in the tip tree, which leaves the watchdog. Will poke those guys ...
<apritzel_>
sdfgsdfs: unless the SD card is really bad, it should be fine. Your patience is more of an issue here, and maybe cooling
<sdfgsdfs>
it feels cool enough
<apritzel_>
sdfgsdfs: my hunch is you will start exploring cross compilers very soon ;-)
<sdfgsdfs>
i think it's really i/o bottlenecked
<sdfgsdfs>
eh i dunno how much effort i want to put in... i just wanna get freebsd working on my orangepi
<apritzel_>
sdfgsdfs: do you have the 4GB version?
<sdfgsdfs>
no it's 1gb
<sdfgsdfs>
err
<sdfgsdfs>
but the machine i'm compiling it on is the libretech
<sdfgsdfs>
that's 2gb
<apritzel_>
2GB should be OKish, 1GB is really a stretch with -j4 (which you definitely want otherwise it will be REALLY slow)
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-]
JohnDoe_71Rus has joined #linux-sunxi
Robot_ has quit [Ping timeout: 480 seconds]
<sdfgsdfs>
asdf
<sdfgsdfs>
my build is finally done
<sdfgsdfs>
i think i regret not building it as debug
<apritzel_>
sdfgsdfs: so did you add a pinctrl and clock driver for the H616?
<sdfgsdfs>
nope i just want it to boot for now
<sdfgsdfs>
without a clock driver, it should fall back to jiffies so it's still boot-able
mripard has quit [Quit: WeeChat 4.5.1]
<apritzel_>
no, that's not what I meant with clock driver: it's the clock tree that provides clocks to each and every peripheral, including the UART
<apritzel_>
without that you won't get anywhere, same with pinctrl: the UART driver will need to enable the clock and configure the pins
<sdfgsdfs>
it's gotta have something in there because it's booting until it tries to mount rootfs
<apritzel_>
well, yes, because the UART is already configured by the bootloader, but that's cheating, at best
<apritzel_>
no, that's something completely different: that's the timer, which is the architected Generic Timer (think PIC), that works already
<sdfgsdfs>
/soc/clock@3001000
<apritzel_>
yes, that one, and clock@7010000
<apritzel_>
that is all very different from x86, if you come from this direction: those details are typically not exposed to the OS directly, but instead handled by the hardware or firmware, partly via ACPI
<apritzel_>
so if you enable a device via ACPI, the AML code might switch the reset lines and clock gates, but on a DT based system that's the responsibility of the OS and its drivers
<apritzel_>
the compatible strings in the DT are your guideline: if the OS does not know about a certain string, it won't work - you cannot use that device
<apritzel_>
and if other devices depend on it, you cannot use those either
<sdfgsdfs>
right
<apritzel_>
some devices have fallback string, which might already match, so there is nothing you would need to do there. Examples are the UART driver, I2C, SPI
<apritzel_>
and most (if not all) devices depend on pinctrl and clock, so you definitely need those
<sdfgsdfs>
fixed-clock ?
<apritzel_>
fixed clock is a standard thing, for clocks that are always running and, well, are fixed
<apritzel_>
MMC should be fairly straight-forward, as you figured. USB itself is standard, but the USB-PHY requires some nasty quirk
<sdfgsdfs>
ahh "allwinner,sun8i-h3-r-ccu"
<apritzel_>
yes, that is one example
<sdfgsdfs>
grepping...
<sdfgsdfs>
kinda appreciating how weird bsd source tree layout is
<sdfgsdfs>
it's not in src/sys/arm/allwinner
<sdfgsdfs>
instead...
<sdfgsdfs>
src/dev/clk/allwinner
<sdfgsdfs>
because of course
<apritzel_>
well, that makes sense, it's a clock driver, like the one from Rockchip or Broadcom or what not
<sdfgsdfs>
and that's another aspect, allwinner shares its mmc controller with the riscv D1 core i believe, so putting it into an arch-specific directory doesn't make a whole lot of sense either
smaeul has quit [Ping timeout: 480 seconds]
<sdfgsdfs>
I have a mangopi as well that somebody worked on already but was never merged
<apritzel_>
Allwinner is the SoC vendor, they provide or use 3rd party IP. They mostly use this with Arm cores, but made the Allwinner D1 with a single RISC-V core
<apritzel_>
from a periheral perspective they are the same, just connected to a CPU using a different architecture
<apritzel_>
so yes, the drivers itself should be architecture agnostic, and should not live in arch/arm or something. That something that bites us in U-Boot as well
apritzel_ has quit [Ping timeout: 480 seconds]
montjoie_ is now known as montjoie
<montjoie>
hello I want to enable crust on bananapi-m64, it has axp803. but no-one use CONFIG_MFD_AXP803 on crust, normal ?
<apritzel>
montjoie: it's the default, isn't it? drivers/mfd/Kconfig: default MFD_AXP803 if PLATFORM_A64
<apritzel>
sdfgsdfs: so to make this clear: the best path is to copy sys/arm/allwinner/h6/h6_padconf.c and adjust that accordingly, same with sys/dev/clk/allwinner/ccu_h6.c
<apritzel>
sdfgsdfs: the H6 and H616 are say like 90% similar, especially the clocks, but annoyingly the remaining 10% are various bits and bobs all over the place
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
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-]