<apritzel>
"console=ttyS0,115200n8 earlycon root=/dev/mmcblk0p1" is probably all you need, or leave that to the distro's bootloader
<apritzel>
kernel-parameters.txt is not something you browse through to find options, it's more a reference in case you need something special (like limiting the number of cores, or memory, or enable special debug options)
ftg has quit [Read error: Connection reset by peer]
<apritzel>
ch341a> so you hook something onto the SPI flash chip, on the board?
<apritzel>
I find FEL much easier: sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin wdreset
<sdfgsdfs>
yea I already have the stuff set up for hacking other devicse
dok has quit [Ping timeout: 480 seconds]
<apritzel>
U-Boot's default settings should find the FreeBSD UEFI installer .efi on an USB stick, but sure about the installed system on an SD card - we don't support persistent UEFI variables, so rely on bootaa64.efi
<apritzel>
but *not* sure about ...
<sdfgsdfs>
it's a -memstick.img, but that's the only generic image available for sd cards
<sdfgsdfs>
pine64 and rpi seem to be well supported at least
<apritzel>
it should have an ESP (EFI system partition) on it, with efi/boot/bootaa64.efi, U-Boot will find and boot that
<sdfgsdfs>
so to be clear, it works like:
<apritzel>
if Pine64 works, H5 should work, given that the kernel has the drivers for that SoC (clocks + pinctrl, most importantly)
<apritzel>
in this model the DT comes from U-Boot, for a while now we sync this regularly from the Linux kernel repo into U-Boot, and to my understanding FreeBSD should work with that just fine
<apritzel>
that means everything board specific is in u-boot-sunxi-with-spl.bin, the rest is generic UEFI and AArch64
dok has joined #linux-sunxi
<sdfgsdfs>
works! except it didn't define bootcmd
<sdfgsdfs>
i thought the uboot built from freebsd ports would have set this lol
<apritzel>
what do you want with bootcmd? The default mainline is to look for bootaa64.efi (among other things)
<sdfgsdfs>
oh wait a minute, it's not able to read the SD card at all... unless I'm reading that wrong...?
<sdfgsdfs>
how on earth is it booting uboot then
<apritzel>
no, I think it's looking for the wrong UEFI boot image, seems like it finds some UEFI boot variable (Boot0000), but that doesn't work out as expected
<apritzel>
and then it gives up and falls back to PXE boot
<apritzel>
a simple hack is to copy whatever the EFI bootloader is to /efi/boot/bootaa64.efi
<apritzel>
lol, the first time I see someone using TF-A LTS releases, I guess that's coming from FreeBSD ports as well?
aggi has quit [Ping timeout: 480 seconds]
<sdfgsdfs>
oh
<sdfgsdfs>
the ESP is completely messed up
<sdfgsdfs>
huh okay that's odd
<sdfgsdfs>
128k is right in the middle of the ESP
<sdfgsdfs>
so it boots uboot and then uboot tries to read from the same partition that it overwrote
<apritzel>
sdfgsdfs: typically the first partition should start at 1MB, that's the default model we assume
<sdfgsdfs>
yeah no this partition starts at 0x4400
<sdfgsdfs>
right after the GPT
<apritzel>
that's not good then
<sdfgsdfs>
i think i downloaded the wrong image...
<sdfgsdfs>
usb installer eugh
<apritzel>
but you actually should not need any U-Boot on some storage, you can write U-Boot to the SPI flash, and then have no restrictions about the ESP location
<sdfgsdfs>
the SPI rom is on the orangepi zero3, not the one i'm currently working with
<apritzel>
ah, right
<sdfgsdfs>
i just wanna get freebsd up and running on this one and then i'll do the h616
<apritzel>
that's the Libretech?
<sdfgsdfs>
yes
<apritzel>
that has eMMC, right?
<apritzel>
you can put u-boot-sunxi-with-spl.bin on one of the EMMC boot partitions then, where it's also out of the way of any partitions
<sdfgsdfs>
it has an eMMC slot
<sdfgsdfs>
you'd need to pay like an extra $20 or $30 for it so i just didn't bother. SD card is better suited
<sdfgsdfs>
ohh
<sdfgsdfs>
now I know why I got confused about the image to download. there aren't any genericsd images for aarch64
<apritzel>
it might be a bit tedious, but can't you use a generic USB installer, on a USB stick, and then install from there to an (empty) SD card?
<apritzel>
I know, that sounds like a PC, but that's the idea of UEFI, really
<sdfgsdfs>
I think that was the original plan before I got confused with bootloader placement
<sdfgsdfs>
this is weird. FreeBSD puts the SD card images together with the installable ISOs
<apritzel>
not sure if the installer puts the ESP (or the root partition) at an 1MB offset of the SD card, but you might want to help it by creating the ESP already, on the SD card
<sdfgsdfs>
I'm gonna try installing if I can't get this to work
<sdfgsdfs>
reusing a specific board's prebuilt sdcard image and replacing the uboot image
<sdfgsdfs>
i feel that FreeBSD should have arm64-aarch64-GENERICSD
<sdfgsdfs>
this was way too convoluted and sent me down wrong paths
wingrime-ww has joined #linux-sunxi
<apritzel>
yeah, just figured that as well: the Pine64 image uses the right offsets, for the SPL and the ESP, but mini-memstick does not bother
<apritzel>
interestingly there is an FreeBSD-14.2-RELEASE-arm-armv7-GENERICSD.img.xz, though
wingrime1 has quit [Ping timeout: 480 seconds]
<apritzel>
system64: shot you an email (with the old sunxi list on Cc:), with tinymix and tinyplay attached, plus what I typed to play a .wav file
<sdfgsdfs>
right, that's what confused me. perhaps they mean to say "we don't have any specific 32 bit SoCs to support, so here's the GENERICSD for it in case you'd like to try"
<apritzel>
sdfgsdfs: I would hope the pine64 image is also generic, just minus the U-Boot installation between 128K and 1MB
<sdfgsdfs>
it booted!
<sdfgsdfs>
and now it panicked
<sdfgsdfs>
should i skip and try to get the orangepi working now
<sdfgsdfs>
i'm gonna install it from scratch to rule out PEBKEC actually
apritzel has quit [Ping timeout: 480 seconds]
<sdfgsdfs>
holy crap that's hot
<sdfgsdfs>
do you know if allwinner chips have thermal runaway protection?
<sdfgsdfs>
i left it running after it paniced and it must've been spinning like crazy
<sdfgsdfs>
well, it's a GENERIC kernel, not something specific in sys/arm64/conf like i expected
<sdfgsdfs>
thanks btw
cnxsoft has joined #linux-sunxi
radxanaoki has joined #linux-sunxi
<system64>
Greetings apritzel! Thank you for the kind email, I've now got audio working thanks to you :D, The playback DAC switches were both off for some reason.
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest11158
dsimic has joined #linux-sunxi
Guest11158 has quit [Ping timeout: 480 seconds]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
aggi_ has quit []
aggi has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
radxanaoki has quit [Quit: radxanaoki]
vagrantc has quit [Quit: leaving]
radxanaoki has joined #linux-sunxi
bauen1 has joined #linux-sunxi
ungeskriptet_ has joined #linux-sunxi
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet_ has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<sdfgsdfs>
wasn't able to replicate the kernel panic, it seems like the mmc controller timed out when it was trying to swap in kernel code
<sdfgsdfs>
anyway i got that one working pretty nice
<sdfgsdfs>
the orange pi i have is actually an h618... not sure what the difference is, but i think that's like an h6? i use the allwinner64 target i believe
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<sdfgsdfs>
cpufreq and dvfs is known to be broken on here so i guess i got something to do
warpme has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
aggi has quit [Quit: zzz]
aggi has joined #linux-sunxi
ungeskriptet_ has joined #linux-sunxi
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
ungeskriptet_ has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
funderscore is now known as f_
warpme has quit []
apritzel has joined #linux-sunxi
<apritzel>
sdfgsdfs: there is no rhyme or reason for Allwinner SoC naming, so H616 and H6 are different SoCs, and you cannot boot anything that just supports H6, but not H616
Schimsalabim has joined #linux-sunxi
<apritzel>
sdfgsdfs: so you would need at least a new file looking like say sys/arm/allwinner/h6/h6_padconf.c - and the numbers and strings in there would be quite different
<apritzel>
also something for the clocks: something copied from sys/dev/clk/allwinner/ccu_h6.c
<apritzel>
that's for the basics, next would be go over the various peripherals (USB, MMC, Ethernet) and adjust their drivers to cope with the tiny but annoying changes that AW did to them
<apritzel>
grep'ing for the compatible strings in Linux' drivers/ directory and looking at how the respective structs differ between the H6 and H616 would probably be a good start for this (just remember to not copy any actual code)
bauen1 has joined #linux-sunxi
<apritzel>
sdfgsdfs: oh, also: the H618 is very close to the H616, from a kernel perspective they are compatible: https://linux-sunxi.org/H616
dliviu has quit [Quit: Going away]
dliviu has joined #linux-sunxi
ungeskriptet_ has joined #linux-sunxi
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-sunxi
ungeskriptet_ has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Remote host closed the connection]
<kuba2k2>
hello again, any tips for debugging a D1s kernel getting stuck at... well, the very beginning, I only see U-Boot's "Starting kernel ..." and then it watchdog-resets after 16 sec
<kuba2k2>
passing earlycon=sbi or earlycon=sbi0 didn't make a difference, I've tried many different load addresses for the kernel/initrd/fdt (to make sure they don't overlap)
<kuba2k2>
also tried setting fdt_high and initrd_high so that they don't get relocated, same result
system64 has quit []
<apritzel>
kuba2k2: have you tried just "earlycon"? That should pick the normal UART from the DT. Not sure SBI supports UART output still at runtime?
<sdfgsdfs>
i have a lot to do for sure
<sdfgsdfs>
more generally for all sunxi i should probably look at cpu throttling after the halt from a panic
<sdfgsdfs>
people are gonna use these as mini servers and leave them unattended for long periods of time, something's gonna crash, then the chip will kill itself after like months of screaming hot temps
<sdfgsdfs>
i could've sworn the schematic didn't have the data pins connected
<sdfgsdfs>
and it all just went to the voltage regulator
<sdfgsdfs>
is there no consistent console message when entering FEL?
<sdfgsdfs>
what i got by using the efex command is different than what i got by plugging it in while holding down '2'
<apritzel>
You are again wandering into BSP territory here, please stay on the path! On the OPi Zero3 you enter FEL mode by booting from an SD card with fel-sdboot.sunxi on it, see the sunxi-tools.git repository
<apritzel>
so you could also boot with mainline U-Boot on the SD card, and then write the u-boot-sunxi-with-spl.bin to the SPI flash from there:
<sdfgsdfs>
yeah weird i dunno
<sdfgsdfs>
the serial console method should've gotten to boot1 but it didn't judging by the output
<sdfgsdfs>
it just said "detected keypress 2" and halted, no FEL
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
sdfgsdfs: boot1 (and boot0) are vendor things (see above...)
<sdfgsdfs>
hold on i need a different sdcard...
<sdfgsdfs>
i could've sworn i had like 5 of them
<apritzel>
and I think even the vendor boot stack doesn't use boot1 anymore, for years now, that's some really old legacy stuff that still floats around a lot, unfortunately
ungeskriptet_ has quit [Remote host closed the connection]
<sdfgsdfs>
wait
<sdfgsdfs>
i just
<sdfgsdfs>
literally boot fel-sdboot.sunxi?
<sdfgsdfs>
so it checks for the eGON signature at 0, 0x2000, and 0x20000
<apritzel>
sdfgsdfs: you can backup the H5 image from the SD card, "dd" the OPiZero3 build on it, boot and install that to SPI flash, then restore the H5 U-Boot, if you must
<sdfgsdfs>
it's not reading my FEL sdcard
<apritzel>
on MMC it doesn't check at 0, but yes: you "dd" fel-sdboot.sunxi to where you would put the SPL, and that puts you in FEL mode
<sdfgsdfs>
it just skips right over that and boots off of spinor
ungeskriptet has quit [Ping timeout: 480 seconds]
<sdfgsdfs>
oh, i should've read the wiki article
<sdfgsdfs>
the example dds to 0x2000
ungeskriptet has joined #linux-sunxi
<sdfgsdfs>
ok i have the image base correct now, but it doesn't do anything at all now
<sdfgsdfs>
like the power LED doesn't even come on
<sdfgsdfs>
no console output
<apritzel>
there is no console output in FEL, because console is board specific, but FEL is a pure SoC thing (it's in the BootROM)
ungeskriptet_ has joined #linux-sunxi
<apritzel>
if that succeeds, it just sits there and waits for USB commands
<sdfgsdfs>
how do i know if it's successful or not even
<apritzel>
run "sunxi-fel ver"
<apritzel>
it should report a H616 chip
<sdfgsdfs>
success
<sdfgsdfs>
heh it reports h616 even though it's really an h618
<apritzel>
then you can run "sunxi-fel uboot u-boot-sunxi-with-spl.bin" and launch U-Boot (without writing it to anything)
<sdfgsdfs>
it says so right on the chip package
<apritzel>
I knew you would say that ;-)
<apritzel>
read the H616 wiki page
<sdfgsdfs>
i know it's the same aside from more cache
<sdfgsdfs>
but where does sunxi-fel get it from
ungeskriptet has quit [Ping timeout: 480 seconds]
<apritzel>
if you really care, send a patch to sunxi-fel to test for the specific revision ;-)
<sdfgsdfs>
some kind of arm equivalent to cpuid?
<sdfgsdfs>
ah
<apritzel>
Allwinner reports a "SOC ID", but that's just for a die, not for a package version
<sdfgsdfs>
yeah the only other port for sunxi is for the h6
ungeskriptet has joined #linux-sunxi
<apritzel>
it's fairly simple and quick to build. But it's rather stable and mostly one image per SoC, so not board specific, so you can just use what I just built
<sdfgsdfs>
seems easy to make
<apritzel>
it's sometimes picky about the toolchain
<sdfgsdfs>
ha ;-) nice try haxor
<sdfgsdfs>
ur firmware is gonna securely monitor me
<sdfgsdfs>
i need to make the port for this if i'm gonna add orangepi support to mainline freebsd
<sdfgsdfs>
cause it's a dependency
vagrantc has joined #linux-sunxi
<apritzel>
well, it's the same repo as for the H6 (or A64/H5), just built with PLAT=sun50i_h616 instead
<apritzel>
and it's only a dependency if you want to build the firmware, the kernel part is completely independent from this
ungeskriptet_ has joined #linux-sunxi
<sdfgsdfs>
hahaha i realized what i was doing
<sdfgsdfs>
i copied over the other atf which already had the a64 bl31.bin
<sdfgsdfs>
and make didn't do anything
ungeskriptet has quit [Ping timeout: 480 seconds]
<sdfgsdfs>
okay anyway i have it now
<sdfgsdfs>
when i built the uboot image it must've used /usr/local/share/atf-sun50i_a64/bl31.bin
<sdfgsdfs>
or didn't have one at all?
<sdfgsdfs>
guess i'm gonna be digging thru makefiles more
ungeskriptet_ has quit [Ping timeout: 480 seconds]
<sdfgsdfs>
i am confused, is uboot supposed to build its own ATF?
<sdfgsdfs>
CLEAN_FILES has "bl31_*.bin"
ungeskriptet has joined #linux-sunxi
<sdfgsdfs>
where on earth does $BL31 get set even
<apritzel>
that might be how the FreeBSD port is done?
<apritzel>
if BL31 is unset, it looks for bl31.bin in the build directory
<sdfgsdfs>
okay yep
<sdfgsdfs>
I see it
<sdfgsdfs>
this would require changing sysutils/u-boot-master/Makefile
warpme has quit []
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-sunxi
ungeskriptet_ has joined #linux-sunxi
ungeskriptet__ has joined #linux-sunxi
ungeskriptet__ has quit [Remote host closed the connection]
ungeskriptet__ has joined #linux-sunxi
ungeskriptet has quit [Ping timeout: 480 seconds]
<macromorgan>
apritzel: had the flu (or a really bad cold) the past week so I didn't look at the IIO stuff much more. In honest truth I'm still not sure the best path forward, even with guidance.
<macromorgan>
I'll keep at it but if you have any ideas I'd be more than happy to listen. In truth the best thing would be to define the channel names in the device tree, but I feel like since that would break backwards compatibility upstream might not take it.
ungeskriptet_ has quit [Ping timeout: 480 seconds]
<apritzel>
macromorgan: yeah, Jonathan's explanation went a bit over my head as well, but I hope just because I haven't really looked at this code before
<macromorgan>
as near as I can tell based on what I see is that the MFD probes and starts generating devices to probe for each of the children, and it appears to do so in order.
<macromorgan>
Setting the device ID to auto means the device name is no longer deterministic
<macromorgan>
what we really need to do is wait until after the MFD device has attempted to add all the devices so it generates device IDs... then once the device IDs are generated we need to use those in the ADC device map instead of the static name we use today.
<sdfgsdfs>
spritzel: anyway, I built the atf for h616, built a new u-boot-sunxi-with-spl.bin, retried the FEL uboot step
<sdfgsdfs>
got that same "Trying to boot from FEL" message over console and that's it
<sdfgsdfs>
wait, no
<sdfgsdfs>
just noticed it's using the wrong path... -a atf-bl31-path=/usr/local/share/atf-sun50i_a64/bl31.bin
<sdfgsdfs>
ok nevermind i figured out my problem..
<sdfgsdfs>
yeeeeeeeeeaaaaaaaaaaaaaaassssssssss
hexdump01 has joined #linux-sunxi
<apritzel>
wens: jernej: can you maybe ACK the A523 pinctrl series, if you are happy with it? I think LinusW is waiting for some signal to get it merged
<jernej>
I thought that they are all acked or reviewed?
<jernej>
I mean patches
<apritzel>
I think 4/8 is missing, the one you had a comment on in v3
<sdfgsdfs>
so what am i doing here... i have the fel boot image on mmc, and the old crappy uboot on spi nor
<sdfgsdfs>
i wanna put this uboot onto the flash chip
<jernej>
oh, I thought I gave you conditional r-b
<sdfgsdfs>
there is sunxi-fel spiflash-write but i'm not sure if a uboot command is preferred
<apritzel>
sdfgsdfs: simplest is using FEL to write directly to the SPI flash: sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin wdreset
<macromorgan>
if I hard code .6.auto or .7.auto in the adc driver it starts working again, so in theory I just need to set the device names at runtime in the ADC driver...
<apritzel>
and if you get a newer TF-A version, this error should go away. There is really little reason to use those LTS releases, TF-A is very stable
<sdfgsdfs>
sweeeeeeeet
<sdfgsdfs>
i'm booting stuff
<sdfgsdfs>
thanks apritzel
<apritzel>
sdfgsdfs: nice, but I guess you won't get very far into the kernel, without padconf and the clocks ...
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<wens>
"clk: sunxi-ng: ccu: add Display Engine 3.3 (DE33) support" looks ok to me, but I didn't check the datasheet
<wens>
if someone could take a look, I think we can get the clock bits in for 6.15 as well
<apritzel>
wens: let me have a look, I think I checked that one before ...
<apritzel>
wens: that would be "v8 08/11"?
<apritzel>
is there actually a datasheet/manual for the DE33? Or is this "The clocks and resets required are identical to the H3 and H5 respectively" an educated guess (confirmed by it working)?
<wens>
no idea
<wens>
yup, "v8 08/11"
<jernej>
no, it's not correct, as discussed on cover letter of previous series
<jernej>
clocks are alright, but that small chunk which writes some magic numbers in it, should not be there
<jernej>
actually, clock should export syscon regmap, since those bits are responsible for assigning planes between mixers
<jernej>
settings live in same mmio region as clocks & resets, but it should be set from "plane" driver
<wens>
I see
<jernej>
this is actually the only showstopper now for this series
<kuba2k2>
apritzel: I finally managed to boot Linux on that D1s, but out of the total 64 MiB over a half is reserved by who knows what... /proc/iomem doesn't help at all: https://pastebin.com/raw/KgPYVCjc
<kuba2k2>
by the way, sorry for being so annoying with all these questions... :D
ftg has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
hazardchem has quit [Read error: Connection reset by peer]
<apritzel>
loki666: don't worry, that looks good in general. For the last patch, replace that stub sentence with: "Tie the Allwinner compatible string to the two feature bits that will toggle the clocks and the reset line whenever the power domain is changing state."
<apritzel>
for the cover letter: just describe the situation, and mention that the hang happens on the second PD enable event.
<loki666>
apritzel: thanks, I updated the gist
electricworry_ has quit [Remote host closed the connection]
electricworry has joined #linux-sunxi
<loki666>
I'll wait for jernej feedback and sent this later
<loki666>
should I add sunxi linux ML in the sendTo ?
<apritzel>
loki666: definitely
<apritzel>
loki666: you could add a sentence to the end of the cover letter saying that this allows to use the Mali GPU on all Allwinner H616 boards and devices, as some kind of motivation
radxanaoki has joined #linux-sunxi
<loki666>
on a different topic, on the H700 mmc1 (second sd card slot) we are getting some "sunxi-mmc 4022000.mmc: fatal err update clk timeout"
<loki666>
it's random as usually, a reboot "fix" the issue
<loki666>
any idea ?
Robot_ has quit [Ping timeout: 480 seconds]
<apritzel>
loki666: can you reproduce it somewhat, at least? and which is the second SD slot, it is mmc1 (normally SDIO) or mmc2 (normally eMMC)?
<apritzel>
loki666: there is a timeout of 750ms (at the beginning of sunxi_mmc_oclk_onoff()), I wonder if one can increase that temporarily and sample the time needed, to see if they are just a tad over 750ms
<apritzel>
though I wonder if it's because it waits for the last(?) transaction to finish (SDXC_WAIT_PRE_OVER), before changing the clock, and that wait spoils the timeout
<apritzel>
also not sure if this jiffies busy polling method is still the wait to implement timeouts?
wingrime1 has joined #linux-sunxi
wingrime-ww has quit [Ping timeout: 480 seconds]
electricworry has quit [Ping timeout: 480 seconds]
<loki666>
apritzel: it's mmc2
<loki666>
I can reproduces it also, but it's random... sometimes it works, sometimes we get these errors
<apritzel>
loki666: can you add the value of oclk_en to the error message? I wonder if it's only happening when the clock is turned off
<loki666>
ok I'll add logs
<apritzel>
also maybe dump the value of REG_CMDR before it's written, to see if there is still a command running
<apritzel>
(but only print that value in the error case, to not disturb the timing)
<apritzel>
and this busy wait should really be fixed, commit 7bb9c244356d2d suggests it's really waiting a long time, even in the normal case
Schimsalabim has quit [Read error: Connection reset by peer]