rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at - *only registered users can talk*
cmeerw has quit [Ping timeout: 260 seconds]
popolon has quit [Quit: WeeChat 3.0]
Mangy_Dog has quit [Ping timeout: 240 seconds]
Mangy_Dog has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
Mangy_Dog has quit [Ping timeout: 240 seconds]
apritzel has quit [Ping timeout: 265 seconds]
cnxsoft has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
jstein has quit [Quit: quit]
victhor has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
kaspter has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
lurchi_ has joined #linux-sunxi
t3st3r has quit [Ping timeout: 240 seconds]
t3st3r has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
t3st3r has quit [Remote host closed the connection]
t3st3r has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 260 seconds]
ChriChri_ is now known as ChriChri
growtop has joined #linux-sunxi
growtop has quit [Remote host closed the connection]
growtopiajaw has joined #linux-sunxi
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
growtopiajaw has left #linux-sunxi [#linux-sunxi]
growtopiajaw has joined #linux-sunxi
<growtopiajaw> hello
<growtopiajaw> i have just built a new rootfs for my a33 tablet with uboot, kernel and everything
<growtopiajaw> when i plugged the sd card into the tablet with the key combination it just boots into a black screen
<growtopiajaw> i have no idea what to do oof
growtopiajaw has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
cnxsoft has quit [Ping timeout: 264 seconds]
cnxsoft has joined #linux-sunxi
sunshavi has quit [Ping timeout: 256 seconds]
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 246 seconds]
JohnDoe_71Rus has joined #linux-sunxi
t3st3r has quit [Ping timeout: 240 seconds]
ganbold has quit [Ping timeout: 246 seconds]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 265 seconds]
jerbob92 has quit [Ping timeout: 260 seconds]
apritzel has joined #linux-sunxi
kaspter has joined #linux-sunxi
ganbold has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
asdf28 has joined #linux-sunxi
cmeerw has joined #linux-sunxi
jerbob92 has joined #linux-sunxi
<bauen1> yup, 48KiB seems to work
iyzsong has quit [Quit: ZNC 1.7.5 -]
iyzsong has joined #linux-sunxi
<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"
<jernej> I think it breaks megi's OPi3 ethernet patches
<jernej> apritzel: why would you enable referenced regulators (with phandle)?
<jernej> that calls for issues, where certain procedure must be followed
<apritzel> because Ethernet wouldn't work otherwise in U-Boot
<apritzel> and HDMI
<jernej> well, I'll revert that for LibreELEC
<jernej> OPi3 ethernet PHY needs proper power up sequence (has 2 regulators)
<jernej> if not done correctly, PHY is unresponsive
<jernej> I would rather implement U-Boot AXP drivers and handle all that there
<apritzel> jernej: revert what? The TF-A code? Sacrificing U-Boot functionality?
<apritzel> jernej: please make sure to supply extra SRAM A1 with your AXP U-Boot patches ;-)
<jernej> yes, U-Boot doesn't need HDMI and rarely network for LibreELEC
<jernej> I didn't get single complain about that
<apritzel> I see that for LibreELEC, but there are more users out there ;-)
<jernej> I said in LE, not for general population
<jernej> AXP driver can be done in U-Boot proper, anyway
<apritzel> ah,right
<apritzel> do you have a pointer to the OPi3 3 patches?
<jernej> somewhere here:
<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
iyzsong has quit [Quit: ZNC 1.7.5 -]
iyzsong has joined #linux-sunxi
<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
<apritzel> and for U-Boot I could save some space by utilising the gaps between the vectors:
<smaeul> apritzel: the biggest hog is really the MMU setup... is there some reason we actually have to have the MMU enabled at EL3, other than speed?
<apritzel> smaeul: that's a good point. TF-A seems to rely on the MMU for *some* locks to work, though this is not well documented
<apritzel> so for the ARM FPGA port we just don't enable the MMU at all, but this seems to be wrong
<smaeul> yeah, spinlock needs MMU, bakery lock doesn't, and some generic code uses spinlocks
<smaeul> we could add a build option replacing all spinlocks with bakery locks :)
<apritzel> we have bakery locks, that work without the MMU, but other parts rely on atomic instructions
<smaeul> oh, not just ldrex/strex?
<apritzel> yeah, I was already thinking about that
<smaeul> there's an option to drop init-only code, but I don't see that helping us any, unless we had TF-A copy crust from DRAM to SRAM A2
<smaeul> or some weird thing like that (I'm not suggesting we do that)
<apritzel> smaeul: hah, I was wondering about that the other day as well
<apritzel> but came to the same conclusion
<smaeul> generic PSCI code is a page and a half, .text.vprintf is the largest single function at 0x400, panic/backtrace code is pretty big
<apritzel> and "atomic instructions" was my sloppy term for "fancy synchronising instructions which rely on normal memory semantics"
DrFrankensteinUK has quit [Read error: Connection reset by peer]
DrFrankensteinUK has joined #linux-sunxi
<apritzel> smaeul: but indeed the AXP setup code was also quite large in my "readelf -s | sort" analysis
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 240 seconds]
apritzel has quit [Ping timeout: 240 seconds]
jstein has joined #linux-sunxi
apritzel has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jernej has quit [Remote host closed the connection]
jernej_ is now known as jernej
apritzel has quit [Ping timeout: 240 seconds]
cnxsoft1 has quit [Read error: Connection reset by peer]
dev1990 has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 256 seconds]
ldevulder_ has joined #linux-sunxi
ldevulder__ has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria]
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
<bauen1> smaeul: i've implemented as an alternative of you just stripping the magic check to determinte the boot device, but have only tested it on a secure-boot toc0 pine h64
<bauen1> smaeul: by the way, do you plan on submitting the mkimage toc0 patches to upstream u-boot ?
<smaeul> yes, there's still some work I want to do (it needs error messages and a way to specify where to find keys), but it's planned
<smaeul> I don't plan to hook it up to the Makefile at first
<smaeul> also it depends on eGON support being merged
<bauen1> finding my issue with u-boot so "quickly" is great, it only gets worse from here :D
qschulz has quit [Remote host closed the connection]
warpme_ has quit [Quit: Connection closed for inactivity]
qschulz has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
Mangy_Dog has quit [Ping timeout: 268 seconds]