ftg has quit [Read error: Connection reset by peer]
dliviu has quit [Quit: Going away]
dliviu has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
f_ has quit [Read error: Connection reset by peer]
f_ has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
chewitt has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
JohnDoe_71Rus has joined #linux-sunxi
<tokyovigilante>
ok, I've got a fedora aarch64 raw image on an SD card and a kernel image with the AXP717 driver, any tips?
<gnarface>
quake server
apritzel has joined #linux-sunxi
<Jookia>
tokyovigilante: boot it :D
<tokyovigilante>
heh, thanks
<tokyovigilante>
to be fair I chucked the SD card in and it got as far as a grub menu for the kernel that came with the image, which was unintended but cool
<tokyovigilante>
I don't seem to be able to control the terminal using minicom, which may be a PEBKAC
<Jookia>
tokyovigilante: for GRUB or for linux? you may need to set a console= arg for linux
<tokyovigilante>
for either, even "hit any key to stop autoboot"
<tokyovigilante>
using a FTDI usb->serial interface, may not be set up right
<gnarface>
turn flow control off
<gnarface>
and make sure you didn't forget to hook up the TX line after you sparked it up (i know a lot of the various wiki/forum posts i've seen about this process advises leaving it disconnected at power on)
apritzel has quit [Ping timeout: 480 seconds]
<gnarface>
you do also need to add a command-line argument to the linux kernel (and i'd assume somewhere in the grub config too) but i didn't think you'd actually be able to see any output without it
<gnarface>
likewise if it was set to the wrong speed
<tokyovigilante>
weird, leaving the TX line disconnected until after power-on totally worked
<tokyovigilante>
ok, I'm at the u-boot console
<gnarface>
something about the power line and rf noise at spark up time can corrupt the stream somehow, i don't know exactly but i've seen it mentioned and observed it happen here too
<gnarface>
if tx isn't attached at power on though, it can't feed that noise back into the system, so the stream stays pure
<gnarface>
anything could happen, usually you see obvious textual corruption then the output fails
<gnarface>
getting everything working except input... just lucky i guess?
<tokyovigilante>
I am pretty lucky
<tokyovigilante>
have had no probs with RX but this is the first time its been worth TX
<tokyovigilante>
so I guess I need to load a dtb and then the kernel image from the SD card?
<tokyovigilante>
yup, got the dtb and Image loaded at the offsets in the wiki, but not sure what to do without booti, I assume I just need to rebuild uboot
<tokyovigilante>
those are the 32 bit offsets but I think i've got the concept
<gnarface>
i know there's a range of possible values
<gnarface>
just need to remember to make room for the size of your actual kernel but i always forget the details
<gnarface>
i had to change them once after building a larger kernel
<gnarface>
obviously you'll want your own actual kernel command-line instead of what i've got there too
<gnarface>
i did have to build u-boot myself for this, but it was a while ago so i'm not sure exactly if booti was something i had to turn on myself or not
<gnarface>
i think there might be alternate commands in there though, this is just based on something i got from the wiki
<gnarface>
... and then edited with help from people over on the pine64 irc
<tokyovigilante>
ok, got it, just no console output yet
<tokyovigilante>
## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000
<tokyovigilante>
Working FDT set to 4fa00000 Loading Device Tree to 0000000049ff8000, end 0000000049fff97f ... OK
<tokyovigilante>
Working FDT set to 49ff8000
<tokyovigilante>
Starting kernel ...
<tokyovigilante>
ah ttyS0 not tty0
<gnarface>
yea, sorry this is the version from after not needing the serial terminal anymore
<tokyovigilante>
hmm, still not getting any output
<gnarface>
uh... i needed a second console argument too but i thought systemd didn't need that
<gnarface>
i'm using sysvinit on mine still
<gnarface>
(devuan)
<tokyovigilante>
might need the baud too
<gnarface>
yea, needs that
<gnarface>
console=tty0 console=ttyS0,115200
<gnarface>
there, like that i think
<gnarface>
sysvinit also needs something added to the /etc/inittab but i don't know what the systemd equivalent would be
<gnarface>
baud might be either 115200 or 1500000 maybe?
<gnarface>
depending on hardware
<gnarface>
?
<gnarface>
not sure about that, heard lots of accounts of only one or the other working depending on whether it was allwinner or rockchip pine64 hardware, but i'm not clear on how much of that was caused by the hardware and how much was caused by shipped distro defaults
<tokyovigilante>
yup got that, still no output, but it does cause the USB FEL device to disconnect immediately
tnovotny has joined #linux-sunxi
warpme has joined #linux-sunxi
<gnarface>
hmm, i got nothing, sorry :(
<gnarface>
someone around here smarter should be able to figure it out though, seems like you're very close
<tokyovigilante>
no worries, thanks
<tokyovigilante>
yeah I feel like the serial console must just need something extra, can't see why it wouldn't at least start booting the kernel at this point
<gnarface>
could it be actually missing from your kernel build?
<gnarface>
i built my own kernels but i mostly just copied over the debian kernel config when i did it
<gnarface>
mabye make sure it's not a module but is statically compiled in...
<tokyovigilante>
maybe, I just used the default 6.7 arm64 defconfig as apritzel had advised above
<tokyovigilante>
actually I've just realised now that you say his PMIC driver might need some changes
<tokyovigilante>
yup, serial tty enabled
bauen1 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel>
tokyovigilante: try adding "earlycon"
<apritzel>
for "console=ttyS0,115200n8" you need a working console driver, which appears about in the middle of the boot process and might depends on other things
<tokyovigilante>
BOOM
<tokyovigilante>
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
<tokyovigilante>
awesome, thanks
<apritzel>
now look at the end of the messages, to see what made it hang
<tokyovigilante>
[ 1.867186] sun50i-h616-pinctrl 300b000.pinctrl: could not request pin 224 (PH0) from group PH0 on device 300b000.pinctrl
<tokyovigilante>
[ 1.879379] dw-apb-uart 5000000.serial: Error applying setting, reverse things back
<apritzel>
tokyovigilante: gnarface: please don't mess with the load addresses unless you know exactly what you are doing, we have $kernel_addr_r and $ramdisk_addr_r for this purpose
<tokyovigilante>
whole bunch of these for spi, uart, etc
<tokyovigilante>
also [ 1.696764] axp20x-i2c 0-0036: AXP20x variant AXP313a found
<tokyovigilante>
[ 1.703927] axp20x-i2c 0-0036: Failed to set masks in 0x20: -6
<apritzel>
I mean the "reverse thing back" messages
<apritzel>
tokyovigilante: PLEASE don't just use some random DTB from another board, that's borderline dangerous.
<apritzel>
as I mentioned: copy that, but strip it, especially remove all regulator nodes
<tokyovigilante>
ok, ta.
<tokyovigilante>
Nothing has caught fire luckily
<apritzel>
because the driver bailed out ;-)
<apritzel>
I have seen devices using, say 1.8V on DLDO1, where another board used 3.3V on that same line
<apritzel>
most of the time you get lucky, and many copy from one reference design anyway, but it's risky
<tokyovigilante>
thanks
<tokyovigilante>
ok have gone right back to just a single MMC node, and included sun50i-h616.dtsi, but that won't get past TF-A now
Schimsalabim has joined #linux-sunxi
<apritzel>
tokyovigilante: what's the output? and what is your DT now?
bauen1 has joined #linux-sunxi
<gnarface>
apritzel: thanks, i didn't even know enough to know that...
<apritzel>
gnarface: yeah, I figured that many things we changed for the better in the past are not widely known
<gnarface>
apritzel: heh, yea like that this is all a complete jerkoff and i should have been using extlinux instead
<apritzel>
gnarface: like the DTB address you used is dangerously close to the kernel, so if the kernel grows, or clears its BSS (which can be several MB beyond the end of the image!), it overwrite your DTB
<apritzel>
and then you get NO OUTPUT at all and go into a day long debug journey
<apritzel>
been there, done that
<gnarface>
apritzel: uh... yea i did hhave that problem, that's why i had to change the numbers
<gnarface>
it really confused me for a while before i realized what was happening
<apritzel>
that's why we carefully chose the addresses and put them into U-Boot's include/configs/sunxi_common.h, there are some comments explaining some choices
<apritzel>
gnarface: so your specific boot script can be rewritten as: load mmc 0 $fdt_addr_r $fdtfile; load mmc 0 $kernel_addr_r Image; booti $kernel_addr_r - $fdt_addr_r
<apritzel>
which you will find now doesn't contain anything board specific anymore
<apritzel>
and you can go one step further: load mmc 0 $kernel_addr_r Image; booti $kernel_addr_r - $fdtcontroladdr
<apritzel>
which will use U-Boot's DTB (which we sync regularly from the kernel tree), so you don't need to load the DTB from the SD card, you don't need a file there, and you don't need to know its name
<tokyovigilante>
apritzel: thanks for the DT and the info regarding memory addresses, I was assuming they were placeholders for the correct values, not actual variables containing them...
<tokyovigilante>
the DT has worked a treat
<tokyovigilante>
Welcome to Fedora Linux 39 (Thirty Nine)!
<tokyovigilante>
Has made it all the way through boot including systemd, I presume I need to do <something> to redirect my vt tty1 to serial
<tokyovigilante>
[ryan@fedora ~]$ uname -a
<tokyovigilante>
Linux fedora 6.8.0-rc7-g2d190068f346 #2 SMP PREEMPT Tue Mar 5 20:02:54 NZDT 2024 aarch64 GNU/Linux
<tokyovigilante>
HOW GOOD
<tokyovigilante>
thanks all, apritzel particularly for entertaining the village idiot
aperezdc has quit [Remote host closed the connection]
aperezdc has joined #linux-sunxi
<tokyovigilante>
now if I can just get Wifi working for ssh...
aperezdc has quit [Remote host closed the connection]
<apritzel>
tokyovigilante: awesome, so glad it worked, and very pleased to hear it booting for you
<apritzel>
if you look into the DT, I commented some lines, for instance the card detect gpios for the SD card
<apritzel>
if you could try to comment broken-cd and uncomment the actual GPIO line, that would be helpful to know if the information I lifted from the vendor DT is actually correct
<apritzel>
also if you could try if the other SD card slot works at all
<tokyovigilante>
ok, will do. Looks like the realtek driver not enabled by the kernel defconfig so will build a new kernel and start fiddling the DT
<tokyovigilante>
ok, didn't have another card in for that boot
<apritzel>
regarding WiFi: one problem is that it requires the AXP to be working, as we probably need CLDO4 to be enabled
<tokyovigilante>
ah right
<apritzel>
I didn't have the time this morning to work this out, and the vendor DT is sparse on those rails, even though they are actually crucial information for a correct DT
<tokyovigilante>
as a general question, do config options selected as modules get built into the kernal Image file?
<tokyovigilante>
no worries, you've done more than enough so far
<apritzel>
no, they don't get build at all when you use "make Image"
<apritzel>
you have to either separately run "make modules" or do both: "make Image modules"
<apritzel>
(with the respective -j option, of course)
<apritzel>
and also I like to build with -s, which just prints errors and warnings, but no "hooray, I compiled yet another file" messages
<tokyovigilante>
I dunno, can't be a hacker without a wall of scrolling text...
<tokyovigilante>
;)
<apritzel>
my problem with that is that it makes you miss warnings, which are not tolerated upstream
<tokyovigilante>
fair
<apritzel>
so if you don't constantly watch, you will just miss them
<tokyovigilante>
Is it worth building the modules to try wifi, or are you doubtful it will work properly? I will just compile them all in otherwise for now
<apritzel>
it's definitely worth trying them, it's probably one of the easier things to get working
<apritzel>
dunno if we actually need CLDO4 or, or if it would be enabled already
<apritzel>
heck, you can actually cheat and try to force this on in U-Boot ;-)
<apritzel>
or we could actually bite the bullet and bring the AXP up
<tokyovigilante>
ok, again for an idiot, how do I pass the module path to the kernel image if I am just dumping it on the SD partition? does it look in a defined place? I'm just used to make install-ing on x86
<apritzel>
tokyovigilante: have you found the CONFIG symbol for the WiFi in Linux?
<tokyovigilante>
yup
<tokyovigilante>
have just built it into the image for now
<apritzel>
yes, that's also fine, though that might create problems with the firmware
<apritzel>
the WiFi firmware that is, which needs to be loaded from the SD card when the kernel starts the driver
<tokyovigilante>
sure
<tokyovigilante>
CONFIG_RTW88_8821CS for reference
<tokyovigilante>
will check and see if the firmware comes with fedora (annoying probably in a package, just using the minimal server image for now)
<apritzel>
yes, that's the one. I kept looking in the wrong directory
<apritzel>
modern distros typically split the firmware packages up, per vendor, which makes them more managable
<apritzel>
do you power the device through the USB cable, or would it keep running if you disconnect the cable and rely on the battery
<apritzel>
(not sure if the AXP would charge and switch without being told so by the kernel)
<apritzel>
because then you might be able to connect something via USB, for instance a USB Ethernet adapter or some USB Wifi device
<tokyovigilante>
rtl8821cs_fw.bin.xz - yup in realtek-firmware package
<apritzel>
ah, same as Debian, great
<apritzel>
well, if you have that file, then you can just copy it to the SD card, to /lib/firmware/
<apritzel>
or you harvest them from the official Linux firmware git repo
<tokyovigilante>
looks like it's already in the server image, nice
hexdump01 has quit []
hexdump0815 has joined #linux-sunxi
<tokyovigilante>
hmm, no luck with wifi. Not sure about second SD, can't seem to see it in lsblk output
<tokyovigilante>
I assime that's the two slots plus the SDIO wifi
<apritzel>
yes, 4020.0000 is the first SD that you can boot from, 4021. is the sDIO, 4022 should be the second SD
<apritzel>
those are the drivers loading, because the DT tells them so
<apritzel>
it doesn't necessarily mean that it detects devices, though it works on the first SD card, apparently
<apritzel>
tokyovigilante: can you boot into the vendor image and have a prompt there? The DT is pretty mute on the regulator voltages, so dumping them from a running system would be beneficial
ftg has quit [Read error: Connection reset by peer]