<bauen1>
but anything above that results in errors of some kind
<asdf28>
:->
damex has joined #linux-sunxi
<bauen1>
actually, it might be the signature code causing some weird error, just adding a massive printf works, but enabling the code that does the signature checks breaks
dev1990 has joined #linux-sunxi
apritzel has joined #linux-sunxi
<bauen1>
nice, i've probably found a NULL pointer dereference in u-boots spl
<jernej>
in your code or mainline one?
<bauen1>
or not so good because i don't really know how to fix it
<bauen1>
in my code
apritzel has quit [Ping timeout: 256 seconds]
<bauen1>
it might be related to me disabling CONFIG_DM_SPL despite SPL_FIT_SIGNATURE depending on it (and patching out the single call that i could find)
yann has joined #linux-sunxi
<bauen1>
basically `gd_fdt_blob()` returns NULL in my configuration, just need to figure out why, hopefully related to my configuration, but i'll have to do that later
cnxsoft1 has quit [Ping timeout: 265 seconds]
netlynx has joined #linux-sunxi
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
asdf28 has quit [Ping timeout: 265 seconds]
asdf28 has joined #linux-sunxi
victhor has joined #linux-sunxi
ec0 has quit [Quit: WeeChat 1.9.1]
ec0 has joined #linux-sunxi
apritzel has joined #linux-sunxi
ec0_ has joined #linux-sunxi
ec0 has quit [Quit: WeeChat 1.9.1]
ec0_ has quit [Client Quit]
ec0 has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<jernej>
smaeul, apritzel: I remember that in the past ATF has issue with regulators - IIRC it enabled too much of them (not sure)
<jernej>
was that problem fixed in latest stable
<jernej>
?
<apritzel>
jernej: Why are you asking? We enable those which are referenced (have a phandle), and those marked as "regulator-always-on"
<apritzel>
jernej: would ignoring a regulator when "regulator-enable-ramp-delay" is present help?
<jernej>
I guess, but that doesn't guarantee there won't be something else in future
<apritzel>
of course, but we never have that guarantee anyway
<apritzel>
and it would be a two-liner fix
<jernej>
if only driver manages power, which knows what to do, then we would have that guarantee
<apritzel>
but can't it disable both regulators, to get to defined state first?
<jernej>
True, but all that means U-Boot needs proper regulator driver anyway
sunshavi has joined #linux-sunxi
<apritzel>
but that would be to get Ethernet support for the OPi3 in U-Boot, which currently doesn't work either?
<apritzel>
and if that's now needed: fair enough
<apritzel>
but we need AXP support in TF-A for poweroff
<apritzel>
so back then it was far easier to just touch some enable registers in the AXP as well, since we had RSB support in TF-A already
hanetzer is now known as hanetzer-web
hanetzer-web is now known as hanetzer
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
<apritzel>
jernej: do you have any ETA for sending the H616 U-Boot patches?
<apritzel>
they don't need to be perfect, but I would rather get the review process started
<bauen1>
i've now got a similiar patch to increase the spl size on a h6, but lack a "normal" board to test it with, it works fine with toc0 and smaeul mkimage, so if someone has some interest in that and time to test it, i could also put it up somewhere
<jernej>
apritzel: sorry, no
<jernej>
apritzel: I addressed your gh comments in local branch
<jernej>
but I have yet to update DT and all that comes with it
<jernej>
I also plan to add injection of reserved memory node
<jernej>
I'll do something of that in the evening, but not sure when it will be finished
<apritzel>
jernej: I have a patch to add a reserved memory node in TF-A
<jernej>
apritzel: I'm not sure that's good enough
<jernej>
I think a lot of distros load separate DT before kernel is booted
<jernej>
it's easier to update one file on some partition that reflash U-Boot
<apritzel>
whatever, as I said it doesn't need to be perfect. But I would love to see the patches on the list before the merge window opens on the 11th, otherwise it will be a stretch to justify merging before April
<apritzel>
at the very least the patches that rework existing code and affect other boards
sunshavi has quit [Ping timeout: 272 seconds]
dev1990 has quit [Quit: Konversation terminated!]
dev1990 has joined #linux-sunxi
<Ashleee>
smaeul, so I've had 10 Pine64 booted with the CLOCK stuff thingy patch and they're still holding the clock, another 7 SoPine modules for 24 hours holding as well... here's hoping it will stay like that until another kernel update in a month's time :P
dev1990 has quit [Quit: Konversation terminated!]
<smaeul>
apritzel: you don't need AXP support in TF-A for poweroff. that's what crust is for
<smaeul>
jernej: u-boot copies the reserved memory nodes from its appended DT to the one loaded from disk
<smaeul>
TF-A should be the one to add the node, because it knows what memory it's using
<jernej>
smaeul: that's by default?
<smaeul>
yes
<smaeul>
see boot_fdt_add_mem_rsv_regions()
<jernej>
I see, thanks for info!
<apritzel>
smaeul: thanks for the confirmation, I was wondering about that U-Boot behaviour, but was too lazy to check ...
<smaeul>
well, I said that, and now that I look deeper I'm not sure my understanding was correct
<smaeul>
u-boot's DT handling is split across too many files to easily trace
<jernej>
apritzel: is now the right time to send DT updates for U-Boot?
<jernej>
from 5.11-rc1?
<apritzel>
jernej: yes!
<jernej>
do you have your FEL and mkimage patches merged?
<jernej>
so I can easily rebase h616 branch
<apritzel>
no, and they won't be until the merge window opens
<smaeul>
there were outstanding comments on both of those
<apritzel>
but I can prepare a next branch
<apritzel>
smaeul: plus that, yeah
<smaeul>
ok, I found the actual U-boot code I was thinking about. in lib/optee/optee.c, optee_copy_fdt_nodes copies reserved-memory nodes, but only those named "optee"
<jernej>
smaeul: I see boot_fdt_add_mem_rsv_regions() call in bootm handling code too
lucascastro has quit [Remote host closed the connection]
<smaeul>
jernej: I think that only affects U-Boot's internal memory management, and doesn't get added to the DT
<smaeul>
the optee code is the only one that calls fdtdec_add_reserved_memory
<jernej>
ah, yes, it depends on CONFIG_LMB
<smaeul>
arch/riscv/lib/fdt_fixup.c also has riscv_fdt_copy_resv_mem_node to copy reserved memory nodes... typical U-boot ad-hoc-ery
<smaeul>
I think that one handles all of them
<smaeul>
so if we had an AXP DM driver in U-Boot, we could remove AXP PMIC code from TF-A entirely, right?
popolon has joined #linux-sunxi
<jernej>
yes - would that save a lot of space?
victhor has quit [Remote host closed the connection]
<apritzel>
jernej: it would, but we can't do it immediately, as TF-A and U-Boot are independent
<apritzel>
smaeul: and it would mean we need to mandate crust
<jernej>
why would crust be mandated in that case?
<smaeul>
it would save 5904 bytes out of a 48KiB SRAM region
<smaeul>
(quick test of deleting the code on A64)
<apritzel>
jernej: because poweroff wouldn't work otherwise
<jernej>
ah, I forgot on that case
<jernej>
well, it would be less code anyway
<apritzel>
so we can do this transition, starting with a U-Boot driver
<jernej>
I mean, it could be less regulator code in TF-A, just minimum for power off
<smaeul>
that would also work
<apritzel>
or that, yeah
<smaeul>
I'm more concerned with removing the phandle hack and getting ethernet working than removing duplicate code
<apritzel>
smaeul: do you have a "heatmap" of code hogs in TF-A? I started to run into trouble with the A64 build, with my H616 patches applied
<smaeul>
so the cheap answer is SEPARATE_CODE_AND_RODATA := 0
<apritzel>
does that change anything? I tried that, but to no avail
<apritzel>
I think what's more annoying is that .data is only 393 byte, but requires a whole page
<smaeul>
there's a lot of fill in the TF-A build to separate things in pages, so it depends on where you are near a page boundary
<apritzel>
I used some of the libfdt "minimalisation" options, and could fix that, for now
<smaeul>
like adding one function can push .vectors, and that has 0x800 alignment
<apritzel>
yeah, we had this issue in the SPL in the past as well
<apritzel>
(until we actually made the vectors optional)
<smaeul>
> I used some of the libfdt "minimalisation" options // I had to do that too, when playing with protected-clocks fixups
gaston1980 has quit [Quit: Konversation terminated!]
victhor has joined #linux-sunxi
<plaes>
any ideas how to debug sudden reboots under "stress" for a64?
asdf28 has quit [Ping timeout: 265 seconds]
<plaes>
I'm attempting to run mame on amd64-olinuxino and it just reboots after a while.. :(
<plaes>
running `stress -v -c 4` for 30s keeps the board alive
apritzel has joined #linux-sunxi
<plaes>
ok, a lot better with heatsink :P
<plaes>
well, somewhat better :(
<Ashleee>
heat or bad power delivery is your enemy
<Ashleee>
I've had resets on bad USB cable (Pine64)
<Ashleee>
switching to better USB cable (and later on GPIO power) fixed my issues
<plaes>
hmm.. it doesn't seem to be only heat issue
<plaes>
right now it rebooted when I attempted to bring up network from console via `ifup wlan0` (mame was started but in the menu)
<jernej>
apritzel: I updated H616 U-Boot patches. Tomorrow I'll test it and hopefully send it to ML
<Ashleee>
plaes, what do you power it with?
<libv>
plaes: is it always mame that does it?
<libv>
or are there other cases
<apritzel>
jernej: very nice, many thanks!
<plaes>
Ashleee: I'm using lab power supply (so I can see how much amps it draws)
<plaes>
libv: haven't really tested other stuff here 1aaaaa
<plaes>
but I can see mame hogging all the cores...
gaston1980 has joined #linux-sunxi
<libv>
lima? display engine?
<apritzel>
jernej: you mentioned the CEC clock being wrong the other day, I added bits 30, but the rest looks like matching the manual to me?
<jernej>
apritzel: Flag is wrong, bits are ok
<libv>
plaes: the randomness of the issue, and the fact that it dies "later" with a heatsink would speak against that, i guess
<libv>
those are of course things you have thought of yourself
* libv
goes back to poking at dmabuf directly
<apritzel>
jernej: ooh, I see, should be CCU_FEATURE_FIXED_PREDIV
<jernej>
correct
<plaes>
well, heatsink gets pretty warm :)
<jernej>
apritzel: if you don't mind, you can fix H6 too :)
<bauen1>
after a lot of "led debugging" i've figured out why spl was broken, turns out reading from dram without initializing the controller just doesn't really work (caused by the spl thinking that the device tree was after the bss section)
<apritzel>
jernej: just wanted to ask ;-)
<apritzel>
bauen1: yeah, the SPL is quite fragile
<apritzel>
because we already use some DRAM, but hopefully only *after* it was initialised
<bauen1>
apritzel: i mean, technically it's my fault, but u-boot sure does offer you plenty of ways of hurting yourself
<bauen1>
ideally i don't want to use DRAM, but that is a goal for later :D
<apritzel>
bauen1: I think this is one of the main purposes of U-Boot: annoying developers ;-)
<apritzel>
bauen1: for the arm64 SPL we were/are so short of memory, that we have to pull many ugly tricks
<plaes>
libv: well, there are multiple layers that could be involved - wayland / sdl / mame
<libv>
smells like temp first though
<bauen1>
apritzel: i mean, the theoretical goal would be to prevent attacks that modify / read dram (using external methods, or maybe rowhammer (?) ), but with this little SRAM that might not be possible
<plaes>
yeah, not sure though why would mame in "idle" still take 4x ~70% CPU
<bauen1>
but i only really care about the secure world for that so just maybe
<bauen1>
OP-TEE seems to have the features necessary to swap integrity protected / encrypted pages from dram <-> sram when necessary, but it also requires >=250kb sram
<bauen1>
but for now a complete verified boot would be a nice thing to have