<hexdump0815>
jernej: apritzel: i just gave your h616 code a try on my x96q box and it seems to boot well as far as it is expected
<jernej>
which one? t95 or orangepi zero2 config?
<jernej>
for U-Boot?
<hexdump0815>
jernej: i used your t95 u-boot branch, the h616-beta branch of atf from apritzel and his h616-v2 kernel branch
<jernej>
ok, so I guess we can expect multiple T95 clones
<jernej>
how much RAM your box has?
<hexdump0815>
jernej: for the kernel i used the opi-zero2 dts in that tree and ethernet is not working - is it using the same ac200 approach as the h6 on tv boxes and if yes, do you have some code for that somewhere already maybe?
<jernej>
yes, but not on this PC
<jernej>
anyway, you need t95 dts for that
<jernej>
but standard AC200 driver should work just fine, just wire DT for it
<jernej>
to emac1
<hexdump0815>
it has 1gb of ram - i actually bought it as 4+64 as i wanted to see if there are really 4gb h313 boxes around but in the end it was just 1+8 - tv boxes as usual :)
<jernej>
ah, H313 can have 2 GiB RAM max. according to boot0 (from BSP)
<hexdump0815>
do you have your t95 dts somewhere on github? if not, can you upload it somewhere maybe? its not urgent
<jernej>
not sure if this is hard or soft limit
<jernej>
as I said, not on this PC
<jernej>
remaind me during week
<hexdump0815>
yes, but so far to me h313 looks just a like a h616 with lower quality standards - i can even run that h313 box stable up to 1.8ghz with the legacy kernel :)
<jernej>
that's probably the case
<jernej>
however, you won't find > 2 GiB H313 devices
<hexdump0815>
no problem - just uploaded whenever your are next to the proper computer :)
<jernej>
because BSP don't support it and thus designers won't consider that even if it's really supported
<hexdump0815>
yes - i guess ist just a marketing thing to sell the lower quality h616 as h313 and tell the box manufacturers to only use them up to 2gb ram
<jernej>
well, we'll never know unless someone makes H313 board with more ram for testing purposes
<jernej>
there could be chicken bits burned for that purpose...
<hexdump0815>
i actually also looked at adding your ac200 dts stuff from h6 to h616, but it looks like the ac200 ehy uses some efuse entries for calibration - did you add those too or are they not strictly needed?
<jernej>
no, I relied on U-Boot to preconfigure AC200
<jernej>
that's really hacky solution
<hexdump0815>
did you make any progress with usb and hdmi already on h616? i think both are still not yet there - right?
<jernej>
I don't work on USB, I rarely use it on boards
<jernej>
apritzel has partial success - it works in U-Boot but not in Linux
<hexdump0815>
ah - ok ... then this is more something for apritzel: then
<jernej>
no success with HDMI yet, I can't figure root cause
<hexdump0815>
and for dvfs is there any extra code needed or only the opp tables and them linked into the dts with the clock supply? if that is the case i might sit down and try to prepare the opp tables from the bsp values
<jernej>
to be honest, I don't care about opp
<jernej>
not yet anyway
<hexdump0815>
ok - no
<hexdump0815>
no problem i wanted to say :)
<jernej>
usually that is done in later stage
cmeerw has joined #linux-sunxi
<jernej>
apritzel: U-Boot network doesn't work on H616 with A64 fallback, it must be H6
<hexdump0815>
jernej: i have ethernet working now :) - thanks for your hints!
<jernej>
np
AneoX has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
StandaSK has quit [Remote host closed the connection]
cnxsoft has quit [Ping timeout: 240 seconds]
<montjoie>
arm64_defconfig is too big for some board
<asdf28>
:->
<asdf28>
what happens when you use it?
diego71 has quit [Ping timeout: 264 seconds]
<montjoie>
uboot fail to load ramdisk in memory
<montjoie>
too many modules
<KotCzarny>
ramdisk_size=40000 ?
<KotCzarny>
:)
<asdf28>
oh, i didn't know that
<asdf28>
but i have only used 32 bit boards so far
\\Mr_C\\ has joined #linux-sunxi
warpme_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
ChriChri has quit [Ping timeout: 246 seconds]
cnxsoft has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
victhor has quit [Remote host closed the connection]
ChriChri has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
<bauen1>
nice, i got verified boot from spl -> u-boot to work
<bauen1>
but the amount of dark magic required is a bit much currently
kaspter has quit [Quit: kaspter]
diego71 has joined #linux-sunxi
jstein has joined #linux-sunxi
<montjoie>
KotCzarny: I got TFTP error: trying to overwrite reserved memory...
<KotCzarny>
fix the load addresses maybe?
<montjoie>
if I decrease load address, it is the Image which will overwrite ramdisk
<montjoie>
I got this also on non-sunxi boards
<montjoie>
arm64 kernel get bigger, but by chance we are just below limit
<montjoie>
but for testing I enable a bit more modules, and boom
bantu has quit [Quit: bantu]
bantu has joined #linux-sunxi
<Ashleee>
btw what does the loading address for kernel in u-boot affect? Is kernel position independent or fixed address? (normal Image, not uImage)
gaston1980 has joined #linux-sunxi
chewitt has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
warpme_ has joined #linux-sunxi
<Ke>
afaik if kernel is relocatable, the address is position independent
<Ke>
in general I have not utilized that feature apart from crashdump kernels
<montjoie>
Ashleee: in uboot I copy image,dtb,ramdisk via TFTP in memory, so I should do overwrite anything before linux start
<montjoie>
+not
<montjoie>
my nanopineoplus2 has 512M of RAM, kernel is 30M ramdisk is 400+M, what could go wrong ?
<Ashleee>
400+ Megs of initramfs? :P
<Ashleee>
I have 20M kernel and 50M compressed initramfs
<Ashleee>
and works fine across all devices (sunxi, rockchip, amlogic, even RPi)
<montjoie>
Ashleee: it is not production, it is CI, I build arm64_defconfig+crypto than boot via network
<KotCzarny>
turn off debugging?
<Ashleee>
ah
<KotCzarny>
i think if you compile kernel with debug sumbols it grows huge
<Ashleee>
yes it does
<montjoie>
the base rootfs is a minimal buildroot with tool for CI
<Ashleee>
also is it compressed or uncmopressed?
<apritzel>
Ashleee: older arm64 kernels had some requirements regarding their load address, but most of them have been lifted recently
<apritzel>
you just have to load them at a 2MB aligned address
<Ashleee>
oh ok wasn't sure, debugging some issue on rk3399 boards where it won't go past "Starting kernel..." on one board but another one works...
<Ashleee>
so load addr was my only idea :)
<Ke>
at some point I had very extensive debugging machinery in intramfs, like web browser and everything, maybe slight overkill, but I have gotten extremely annoyed with the super minimized initrds on some distros
<Ke>
eg. having strace on initrd goes extremely long way
<Ashleee>
strace and gdb!
<apritzel>
the old requirement of 2MB aligned + 512K is no longer, so U-Boot will actually *copy* the kernel around, from 40080000 to 40200000
<Ke>
anyway the cost of having huge initramfs is negligible, unless you have very fast EFI/bootloader, you won't even notice it
<Ashleee>
I need to retry my issue, I may actually drop initrd to speed it up as it won't even start booting kernel, no earlyprintk/earlycon :( if I use a different dtb it will die at pagefault or hang as well... nobody from #linux-rockchip replied since yesterday so I am all alone on this issue :)
<Ashleee>
well the cost of aving huge initramfs is that it will occupy space for runtime...
<Ke>
or very small emmc or similar boot source
<Ashleee>
(as I don't pivot root anywhere else)
<apritzel>
Ashleee: another common problem is something (kernel, initrd) overwriting the DTB
<Ashleee>
yeah that shouldn't be the issue as another rk3399 board boots fine... don't know if kernel does anything regarding RAM timing (doubt it, should all be a matter of uboot's RAM bringup code)
<Ashleee>
it's a noname "H96 Max" TV box with rk3399, OPi4 (with rk3399) works fine so I am getting slightly annoyed :)
<apritzel>
Ashleee: also keep in mind that kernels have BSS right behing their image, so the startup code will actually clear memory
<apritzel>
especially debug kernels have a rather large BSS
<Ashleee>
hmm
<Ashleee>
don't think this is my issue sadly...
<Ashleee>
will have to dig around dtb
<apritzel>
I once had an issue where I loaded the kernel (24MB in size) at 512KB, DTB at 32MB
<apritzel>
but then the kernel startup cleared from 24 MB to around 34MB, so the DTB was gone
<Ashleee>
oh
<Ashleee>
hmm
<Ashleee>
that's a fair point
<Ashleee>
thanks!
<Ashleee>
will check the dtb load addr
<Ashleee>
what controls the loadaddr for dtb? cannot find it in .config, or is it in the u-boot dtb?
<apritzel>
doesn't matter for modern (arm64) kernels, really
<apritzel>
the load address gets passed by U-Boot in register x0
<Ashleee>
I mean where does it download to via tftp... I know it is an env variable but where during build time is the default set?
<apritzel>
Documentation/arm64/booting.rst in the kernel tree explains the details
<Ashleee>
thanks!
<apritzel>
$fdt_addr_r is the canonical variable used in U-Boot
<apritzel>
the kernel itself has no default value or something, it just looks at x0 when it starts
<apritzel>
the only remaining constraint is that the DTB must be wholly contained in a 2MB region (for mapping reasons)
<jernej>
apritzel: your TF-A h616-beta branch fails to build H6 bl31.bin
<apritzel>
jernej: with what message? DEBUG=0, unused variable?
<apritzel>
jernej: I have a much updated version here, and built all three targets fine, both w/ and w/o debug
<apritzel>
will push this probably tomorrow, for offical code review
<apritzel>
jernej: yeah, that's with DEBUG=0, I fixed that here already
<jernej>
ok, just checking
<apritzel>
same for a64, actually
<apritzel>
jernej: but thanks for the report!
<apritzel>
jernej: I rarely build without DEBUG, so didn't notice it initially
chewitt has joined #linux-sunxi
<jernej>
apritzel: just curious - is there a way to enter FEL mode from U-Boot?
<jernej>
currently I'm unable to burn SD card
<bauen1>
jernej: triggering a jump to NBROM+0x20 in AArch32 mode should do the trick, not sure if u-boot offers a nice way of doing that
<jernej>
board also don't have FEL (U-Boot) button and Android is on eMMC, so no easy way to do it (I don't want to destroy Android)
<jernej>
bauen1: thanks, but it's in 64-bit mode
<bauen1>
jernej: then you need to trigger a board reset after writing some magic values and the jump address into magic registers, iirc apritzel actually made a patch that does that
<jernej>
yeah, but I don't such U-Boot on it yet
<jernej>
I'll just wait until I get working SD card reader
<jernej>
thanks anyway
<bauen1>
jernej: what is the processor ?
<jernej>
H6
<bauen1>
jernej: oh then it's easy
<bauen1>
"easy" as in 3 memory writes and triggering a reset, let me dig those up
<bauen1>
jernej: but just to be sure, you do have a way of completely removing power to the processor in case things go bad ?
<jernej>
yeah, sure :)
<bauen1>
basic idea is `writel 0x070001b8 0xFA50392F writel 0x070001bc 0x20`, trigger reset without disrupting power to Vcc-RTC
<jernej>
what could go so bad?
<bauen1>
jernej: if you write the wrong values, the board could be stuck in some form of loop until you clear the registers (stored in the RTC and therefor retain their values if Vcc-RTC has power)
<bauen1>
s/be/get/
<bauen1>
so something like `mw .w 0x070001b8 0xFA50392F`, `mw .w 0x070001bc 0x20`, then reset the board
<apritzel>
actually I tried that a few days ago, and it didn't work
<bauen1>
apritzel: did reset the board or trigger a reset from u-boot of some form ?
<bauen1>
jernej: yes, the trick above is untested
<jernej>
hah, it works, commands are as follows:
<apritzel>
that's why I asked whether the hotplug registers survive a watchdog reset
<jernej>
mw.l 0x070001b8 0xFA50392F
<bauen1>
apritzel: they do
<jernej>
mw.l 0x070001bc 0x20
<jernej>
reset
<jernej>
that's all to it
<jernej>
thanks!
<bauen1>
they survive anything short of a write or loss of power to both Vcc and Vcc-RTC (or voltage drop below 1.7v or something like that)
<apritzel>
jernej: interesting, I did the same, but on A64, I think
<bauen1>
apritzel: doesn't the A64 have the brom somewhere else ?
<apritzel>
bauen1: the hotplug registers are elsewhere, but BROM is at 0x0 as well
<apritzel>
jernej: because I felt the same pain for entering FEL, and was looking into a "felreset" U-Boot command
<jernej>
apritzel: but unfortunately, sunxi-fel uboot command doesn't work after that
<apritzel>
jernej: the new FIT version, or the existing one with a legacy image?
<jernej>
new FIT version
<bauen1>
apritzel: are the hotplug registers part of the rtc (0x01F00000) in a64 ? i don't see them in the manual
<apritzel>
I think I saw some issues yesterday if you load other binaries together with the uboot command
<apritzel>
bauen1: they are in the CPUCFG block, but it works, as this is what I use for the SPL 64-bit FEL return
<apritzel>
bauen1: by "works" I mean with an RMR reset, which is just resetting the core
<bauen1>
apritzel: but then they might not be part of the rtc (and thus might not survive a watchdog reset)
<apritzel>
bauen1: indeed, good point
<apritzel>
I was already thinking that I need to ask TF-A to do a core reset
<bauen1>
apritzel: can you try by using the same registers as the h6 but with the base address of the a64 (0x01F00000) ?
<apritzel>
because we can't do an RMR from U-Boot proper anymore, as this already runs in EL2
<bauen1>
apritzel: so something like `mw .w 0x01F001b8 0xFA50392F`, `mw .w 0x01f001bc 0x20`, `reset` ?
bantu has quit [Quit: bantu]
<apritzel>
something, but one address was 4 bytes off for me, let me check
<bauen1>
or right, the fel_enter offset in the nbrom on that chip might be different
bantu has joined #linux-sunxi
<apritzel>
bauen1: ha, thanks, I think you found my bug ;-)
<bauen1>
some care needs to be taken, since directly calling the fel skips some important bits of the n/sbrom that enable some SRAM chips and some clocks
<apritzel>
I feel victim to my own cleverness, but using a *pre-decrement* instruction, so I gathered the wrong address from my own code ;-)
lurchi_ is now known as lurchi__
<bauen1>
which is why i would be surprised if the processor still boots to fel fine if you remove power from Vcc but keep Vcc-RTC on, preserving the RTC values but clearing everything else (including what seems to enable the SRAM chips)
<bauen1>
on that note, is there an easy way i can use to check what mode u-boot is being executed in ?
<hexdump0815>
jernej: apritzel: i'm trying to boot another h616 box (tx6s 4/32) with you u-boot and on this one it fails with "spl: mmc init failed with error: -123" - details here: https://pastebin.com/raw/prEuBYmx
<hexdump0815>
jernej: apritzel: the box has a different mmc cd gpio then the one of the opi zero2 and the t95 of jernej (see pastebin) and i tried to adapt to that, but it still does not boot - any ideas?
<hexdump0815>
jernej: apritzel: what is a bit strange now is that the SPL says DRAM: 4096 MiB and u-boot later DRAM: 3 GiB - is this expected? jernej: does u-boot see the full 4gb on your box?
<jernej>
hexdump0815: I'm not sure I properly set up CD pin on T95
<jernej>
hexdump0815: U-Boot is not wired yet to full 33-bit address space, so 3 GiB is max. for now
<hexdump0815>
jernej: maybe this box even does not have one - removing it from the dts and setting it to "" in the config makes u-boot boot properly from the sd card
<jernej>
but it's entirely SW issue
<hexdump0815>
ok - good to know :)
<jernej>
how can you tell if there is no CD pin? if Android detects when SD card is inserted most probably such pin exists
lucascastro has joined #linux-sunxi
<hexdump0815>
if i use the exact gpio values from the running android dtb then i think it should detect it ... maybe i'll have to test if android actually detects inserted sd cards in this box ...
<hexdump0815>
or i did something wrong in the gpio counting or the interpretation of the android cd-gpio line in the dts
kevans91_ is now known as kevans91
<apritzel>
hexdump0815: CD GPIO is most likely just PF6, that's the most obvious pin to use
<jernej>
apritzel: hopefully you can get through all of my U-Boot patch series before merge window :)
<apritzel>
bauen1: not easily, but you can hack in a U-Boot command that dumps the CurrentEL system register
* apritzel
is restarting the crashed Thunderbird ...
<hexdump0815>
apritzel: with PF6 it did not work neither - i would really not be surprised if this box simply does not have any pin - everything is possible with tv boxes :)
<jernej>
and that's why there not well supported in mainline :)
<jernej>
*they are
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #linux-sunxi
popolon has joined #linux-sunxi
<Ashleee>
any clue why initcall_debug option could be ignored? :)
gaston1980 has quit [Quit: Konversation terminated!]
<apritzel>
hexdump0815: to find the CD pin, you can play around with the PIO registers in U-Boot, that way you can check multiple pins at once
<hexdump0815>
apritzel: can you give me or point to a quick example for that procedure?
<hexdump0815>
apritzel: btw. what is the exact state wrt usb on h616 - i think its not yet woking well in the kernel and you had it halfway working in u-boot?
<apritzel>
hexdump0815: it works fine in U-Boot (just tested a pen drive), but when I apply the same changes to Linux, the USB stack complains and bails out
<apritzel>
I have two more idea to try at the moment
<hexdump0815>
that sounds promising :)
<apritzel>
hexdump0815: re PIO: you need to pick a port, then dump the first 9 registers of its base address: "md.l 0x0300b0fc 9" for PortH, for instance
<apritzel>
at offset 0x10 (first in second line) you see the data regst
<apritzel>
*register, one bit for each pin
<apritzel>
I would turn all "7"s in the first four words into "0", to configure pins as "GPIO input"
<apritzel>
then dump the registers, change the SD card, dump again
<apritzel>
and see if some bit flipped
<apritzel>
or, if you have some candidates, you can use "gpio input ph4" (for instance), once with a card inserted, once without one
<apritzel>
but it could well be that the actual switch is broken (or bent), it was for instance on my Pine64 LTS
<apritzel>
jernej: bauen1: re felreset: I checked again: on the H6 the sequence indeed works, but not on the A64
<apritzel>
and I had the right addresses on the A64
<bauen1>
hm, maybe i'll do some diggign in the nbrom why it might not work
<apritzel>
also one caveat is that now every reset ends up in FEL, until someone clears those hotplug registers
<apritzel>
bauen1: does the BROM clear the hotplug registers at some point?
<bauen1>
apritzel: no
<apritzel>
so I could at least verify whether they survive a watchdog reset ...
<bauen1>
i've now "added" (read as: hacked on) fdt configuration signature verification to the spl, and it now only boots atfs that have been signed
<bauen1>
slowly getting there
<hexdump0815>
apritzel: thanks a lot for the explaination - i'll give it a try during the next days
hexdump0815 has quit [Remote host closed the connection]