rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
linkmauve has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 256 seconds]
lurchi__ has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
victhor has quit [Ping timeout: 272 seconds]
juri_ has quit [Ping timeout: 265 seconds]
juri_ has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
lurchi__ is now known as lurchi_
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 246 seconds]
ChriChri_ is now known as ChriChri
warpme_ has quit [Quit: Connection closed for inactivity]
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 240 seconds]
reinforce has joined #linux-sunxi
pCactus has joined #linux-sunxi
prefixcactus has quit [Ping timeout: 246 seconds]
apritzel has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
cmeerw has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 265 seconds]
matthias_bgg has joined #linux-sunxi
<KotCzarny> btw. if spl size matters, why not -Os ?
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
netlynx has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
pCactus has quit [Read error: Connection reset by peer]
pCactus has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
lkcl has quit [Ping timeout: 272 seconds]
rzerres has quit [Read error: Connection reset by peer]
rzerres has joined #linux-sunxi
cmeerw has quit [Ping timeout: 272 seconds]
mmarc__ has joined #linux-sunxi
lkcl has joined #linux-sunxi
rzerres has quit [Ping timeout: 272 seconds]
rzerres has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 272 seconds]
apritzel has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
apritzel has quit [Ping timeout: 246 seconds]
lkcl has quit [Ping timeout: 265 seconds]
lkcl has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 256 seconds]
Perlovka has quit [Ping timeout: 240 seconds]
warpme_ has joined #linux-sunxi
ldevulder_ is now known as ldevulder
lkcl has quit [Ping timeout: 265 seconds]
wens has quit [Ping timeout: 264 seconds]
wens has joined #linux-sunxi
apritzel has joined #linux-sunxi
Perlovka has joined #linux-sunxi
<karlp> apritzel: if you just meant that a static function can be inlined at higher opts, sure, but that's not "breaking linking" ?
<apritzel> karlp: no, I meant that the compiler optimises away calls, so you no longer need the definitions of functions (or even a symbol) for your program to link
lkcl has joined #linux-sunxi
<karlp> that's still not breaking linking....
<karlp> you should have had -lm, because you thought were going to call it.
<karlp> is just "yay, thanks"
<karlp> hang on missed a line
<karlp> you _should_ have -lm, because you were going to use it.
<apritzel> and that's the point: we remove the (equivalent of) -lm from the build
<karlp> when you go to -O1 or higher and it removes the call, you _can_ stop requesting to link with -lm, but that's a sideaffect.
<apritzel> ... we rely on
<karlp> there shouldn't be anything to pull in from -lm
<karlp> just leave the -lm there.
<apritzel> -lm was just an example
<karlp> if you're getting things in the bin from -lm when it's not used, you have a linker bug...
<karlp> you should be able to add -lwhateveryoulink and if its not used, it's not there.
<karlp> just leve the -lm there
mmarc__ has quit [Remote host closed the connection]
<apritzel> the whole reason we do this exercise is to get rid of -lm
<karlp> for what reason?
<apritzel> in TF-A we have a full bunch of code around SCPI, which talks to the ARISC
<karlp> to try and catch inadvertent uses of it?
<apritzel> but the H616 does not have an ARISC
<apritzel> so we just don't want to compile in all that code
<bauen1> shouldn't the specific optimisations (-fxxxx) then be enabled by default instead of enforcing -O >= 1 ?
<karlp> but it's not getting compiled in?
<karlp> it's only a p roblem when you go down to O0?
<karlp> when you _need_ it?
<apritzel> normally we run -Os, of course
<apritzel> but some of the CI tests use -O0, for reasons I dispute
<karlp> totally agree there, no point running CI on different code...
<apritzel> it's the same story in Linux: you can't compile the whole kernel with -O0, and those optimisations are one thing that breaks
<karlp> ok, but that's still the user broke linking by removing -lthingstheyactuallyneed
<karlp> if it's not used, it's not linked, the only reason to deliberately remove the -lwhatever call is to try and catch calls that _aren't_ optimized
<karlp> so that's on the users, you're not allowed to use -O0 anymore at that point
<apritzel> in the example the static variable is actually controlled by an #ifdef CONFIG_FOO, and the same CONFIG_FOO controls adding -lm or not
<apritzel> the teams wants to retain the option to use -O0, for debugging reasons
<karlp> then they need to leave -lm on then.
<apritzel> (which is somewhat pointless, as the Allwinner port doesn't fit into SRAM with -O0 anymore)
<karlp> and I still maintain that's not optimizations breaking linking, it's users removing links that are only no-longer needed because of an optimziation
<apritzel> it's not a library in TF-A, it's adding a whole bunch of code we *cannot* compile without having an ARISC
<karlp> but I guess you can argue that's semantincs and not really relevant.
<apritzel> originally I actually had the whole SCPI code in, but that was ugly (dummy addresses just to make it compile) and pointless (will never be used in that build)
victhor has joined #linux-sunxi
<apritzel> so we now use a preprocessor symbol to control inclusion of that code, and instead of adding #ifdefs *everywhere*, we just have one static inline function that guards SCPI code
<apritzel> so is_scpi_available() is a static inline function that always returns false if SCPI is not even compiled in
<apritzel> if SCPI is compiled in, this function dynamically determines the existence of the crust firmware
<apritzel> so we keep the existing code, which uses C if statements already, and everything falls into place nicely
<prefixcactus> apritzel: dumped memory starting from 0x4a000000 just in case. matches the uboot bin perfectly.
<prefixcactus> I'm at a loss as to what to do now with this whole thing besides waiting for news from that query
<apritzel> well, it could still be something else, but that's rather unlikely, there is not much that can break there for ARMv7, this whole handover between SPL and U-Boot proper is quite simple
ElBarto has quit [Quit: Lost terminal]
<apritzel> you could try to add early debug messages in U-Boot proper code, to see how far it comes (and if it comes there at all)
ElBarto has joined #linux-sunxi
<prefixcactus> apritzel: well, that's something, at least. Could you point me towards where the entry point to u-boot proper is in the code?
<apritzel> prefixcactus: arch/arm/cpu/armv7/start.S
<apritzel> if you write an ASCII character value to 0x1c28000, you should see it on the serial
<apritzel> that's how I do this kind of early debug: mov r1, #0x1c00000; orr r1, r1, #0x28000; mov r0, #'A'; str r0, [r1]
<apritzel> if you find an unused register, you only need to do the address setup once, then can add several checkpoints throughout the code
elros1 has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
<prefixcactus> apritzel: what's the purpose of the orr? can't you just mov r1, #0x1c28000 ?
<apritzel> prefixcactus: you can either load to the upper or lower halfword (16-bit), or you load any shifted 8-bit value
<prefixcactus> ah.
<apritzel> that's (roughly) the restrictions for AArch32 immediate loading
Guest66867 has joined #linux-sunxi
s_frit has quit [Ping timeout: 272 seconds]
mmarc__ has quit [Remote host closed the connection]
<prefixcactus> apritzel: by the way. how's SWD support with sunxi?
mmarc___ has joined #linux-sunxi
StandaSK has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
Guest66867 has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
StandaSK has quit [Quit: Connection closed]
StandaSK has joined #linux-sunxi
<StandaSK> Hi, I'm trying to retrieve the boot1.header and script.bin files over USB in FEL from my A64 tablet (Navon iQ7 2018), but when trying to read these, i keep getting this error: usb_bulk_send() ERROR: -7: Operation timed out. I tried entering FEL using volume down and using the special SD card image, but I get this error with both methods. Any tips?
<StandaSK> (also, I'm not sure if this is the right place to ask this)
<prefixcactus> there is mention of this in the wiki; the main point is that for loading to work, boot1 (?
<prefixcactus> ) needs to have run
<prefixcactus> there's an overview of which methods enter fel before boot0/boot1 runs and which do it after. Entering FEL with a button press at poweron is the former
<prefixcactus> (all that knowledge didn't help me make it work on my devboard, though...)
<StandaSK> i couldn't find a fel button on the pcb/motherboard (didn't yet look at the bottom side though). According to the wiki, entering FEL using a standard button (volume down in my case) should initialize Boot1
StandaSK has quit [Ping timeout: 240 seconds]
StandaSK has joined #linux-sunxi
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
<apritzel> StandaSK: I am not sure this works with A64 devices anymore, typically they don't even use the traditional boot1 (IIRC)
<apritzel> StandaSK: the easiest way is to use this "magic" SD card image which always enters FEL when you boot from it
<StandaSK> I'm having the same error even with the magic SD card image
<prefixcactus> apritzel: apparently lowlevel_init doesn't return
<prefixcactus> I can't figure out which one of 23 lowlevel_inits it actually jumps to, however
<prefixcactus> apritzel: another interesting thing is that whenever I place an instance of the debug probe code after the point where it fails, I get zero console output on that run
<prefixcactus> not even the SPL prints
mmarc___ has quit [Remote host closed the connection]
asdf28 has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
victhor_ has joined #linux-sunxi
victhor has quit [Ping timeout: 256 seconds]
<apritzel> prefixcactus: arch/arm/cpu/armv7/lowlevel_init.c
<prefixcactus> apritzel: thanks
<prefixcactus> I've traced it to clock_init() and clock_init_uart() within it, btw
<apritzel> prefixcactus: one thing to keep in mind is that this code is shared between SPL and U-Boot proper
<apritzel> and this early printing won't work in the SPL, since the UART isn't setup yet
<apritzel> you can try "#ifndef CONFIG_SPL_BUILD" to prevent this
<prefixcactus> then this makes sense
daregap has quit [Quit: daregap]
<apritzel> StandaSK: so what do you actually do with FEL? Does "sunxi-fel ver" work and lists you an A64?
mmarc__ has joined #linux-sunxi
<prefixcactus> oh, by the way
<prefixcactus> the comments in lowlevel_init.S say that the s_init function should do the absolute bare minimum yadda yadda and that for boards with SPL it should be empty
<prefixcactus> yet it does a buttload of things
lucascastro has quit [Ping timeout: 272 seconds]
<StandaSK> apritzel yeah, sunxi-fel version outputs this: AWUSBFEX soc=00001689(A64) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000
AndroUkeie has joined #linux-sunxi
<apritzel> StandaSK: great, so that means that FEL is working
<apritzel> so what did you actually try next?
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
<StandaSK> I ran "sudo ./sunxi-fel read 0x42400000 0x82d0 boot1.header" and got the error
<apritzel> that won't work
<apritzel> what do you expect it to do?
<apritzel> this will try to read from DRAM, which isn't even initialised at this point, not to speak to contain any interesting image
<StandaSK> well I just copied the command from wiki
lucascastro has joined #linux-sunxi
<apritzel> ah, but this relies on entering FEL via boot1
<apritzel> so those instructions are only for older SoCs, they won't work on the A64
<StandaSK> ah, I see. So, what can I do then?
<apritzel> to do what exactly? get some information from the existing Android on the eMMC?
<StandaSK> yeah
<apritzel> the most interesting piece of info is probably the DTB
<apritzel> do you have a recovery image (as a file) somewhere?
<StandaSK> I'm not aware of having such a file, but I can get to recovery mode :P
<StandaSK> though I guess that's not that useful
<apritzel> do you have a serial console? Either through pins on the PCB or through the serial SD adapter?
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
<prefixcactus> apritzel: I've found where it hangs.
<apritzel> StandaSK: if you don't have serial, it gets tricky. Do you get terminal access from the Android? I once managed to install some SSH server Android app and get access via this one
<prefixcactus> common/board_f.c:966: if (initcall_run_list(init_sequence_f)) hang();
<StandaSK> I couldn't find UART pads on the PCB (though I haven't checked the bottom side of the PCB). I don't have a serial SD adapter
<prefixcactus> (in board_init_f)
<apritzel> prefixcactus: but which one in this long list is the culprit?
<prefixcactus> that I haven't figured out yet
<apritzel> prefixcactus: try adding #define DEBUG to include/initcall.h
<apritzel> or rather in common/board_f.c, I guess
<prefixcactus> I just did that, and it didn't print anything
<prefixcactus> also of note is the fact that I'm still using the lowlevel debug in C files, cause puts does nothing
reinforce has quit [Quit: Leaving.]
AndroUkeie has quit [Read error: Connection reset by peer]
swiftgeek has quit [Ping timeout: 264 seconds]
JohnDoe_71Rus has joined #linux-sunxi
juri_ has quit [Ping timeout: 256 seconds]
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc___ has joined #linux-sunxi
<StandaSK> oh well, will try to look for the UART pads on the bottom side of the PCB next week
lucas_ has joined #linux-sunxi
lucas_ is now known as Guest82362
mmarc__ has quit [Ping timeout: 246 seconds]
<prefixcactus> apritzel: given that initcall_run_list does return (it's just nonzero, so everything hangs), I probably need something a bit more sophisticated at this point
lucascastro has quit [Ping timeout: 272 seconds]
cmeerw has joined #linux-sunxi
<apritzel> prefixcactus: what board image do you use? BPi-M2 Ultra?
<prefixcactus> yes
<prefixcactus> actually, let me check
<prefixcactus> nope, apparently I used the berry config
<prefixcactus> my basic debug did tell me it fails on the 7th call, btw.
<prefixcactus> no idea what it is, though
elros1 has quit [Remote host closed the connection]
<apritzel> so either it's some M2 Berry specific config that annoys the board, for instance I see two board specific voltage settings in the _defconfig
<apritzel> or it's indeed some *flaky* DRAM setup, which works for a bit, but fails at some point
<apritzel> (we have seen this before, where a board would boot well into Linux, but then randomly crashes there, due to inexact DRAM setup)
<prefixcactus> heh
<prefixcactus> I just replaced the device tree in the defconfig
<prefixcactus> and uboot gets right up to console
<prefixcactus> I've got a uboot shell now
juri_ has joined #linux-sunxi
<apritzel> did you use the Ultra now?
<prefixcactus> yes
<prefixcactus> apritzel: I cannot express how grateful I am right now
<apritzel> just the DT? I wouldn't think that we actually look at the DT that early ...
<prefixcactus> Yes, the DT was the only thing I changed in the defconfig
Guest82362 has quit [Ping timeout: 240 seconds]
<prefixcactus> it doesn't detect any MMC from here, though
<prefixcactus> so there's a lot to do still
StandaSK has quit [Ping timeout: 240 seconds]
we3fan has joined #linux-sunxi
<prefixcactus> here's the console log: https://pastebin.com/4SJ9NSKa
<prefixcactus> I think I'm gonna wrap it for today however
<apritzel> prefixcactus: enjoy the weekend ;-)
<prefixcactus> Thanks! You too :)
eduardas has joined #linux-sunxi
swiftgeek has joined #linux-sunxi
<swiftgeek> i blacklisted sun4i_gpadc_iio / sun4i_gpadc not sure if that will help with random crashes
<swiftgeek> at the very least kernel doesn't complain in dmesg
lucascastro has joined #linux-sunxi
<swiftgeek> at last from observing temperature for last dozen of crashes, it's clear it's not overheating or anything
<swiftgeek> neither on A13 nor AXP209
we3fan has quit [Quit: Leaving]
andy25225 has quit [Ping timeout: 256 seconds]
StandaSK has joined #linux-sunxi
StandaSK has quit [Client Quit]
prefixcactus has quit [Quit: Leaving for Mars]
andy25225 has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
pCactus has quit [Ping timeout: 256 seconds]
prefixcactus has quit [Ping timeout: 240 seconds]
pCactus has joined #linux-sunxi
lucascastro has quit [Ping timeout: 240 seconds]
prefixcactus has joined #linux-sunxi
pCactus has quit [Read error: Connection reset by peer]
hlauer has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has joined #linux-sunxi
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
braveannie has joined #linux-sunxi
braveannie has quit [Quit: Connection closed]
vagrantc has joined #linux-sunxi
macc24 has quit [Ping timeout: 260 seconds]
macc24 has joined #linux-sunxi
lucascastro has joined #linux-sunxi
lucas_ has joined #linux-sunxi
lucas_ is now known as Guest12216
lucascastro has quit [Ping timeout: 240 seconds]
pCactus has joined #linux-sunxi
prefixcactus has quit [Read error: Connection reset by peer]
diego71 has quit [Ping timeout: 240 seconds]
prefixcactus has joined #linux-sunxi
pCactus has quit [Ping timeout: 265 seconds]
gaston1980 has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
pCactus has joined #linux-sunxi
prefixcactus has quit [Read error: Connection reset by peer]
lucascastro has joined #linux-sunxi
Guest12216 has quit [Ping timeout: 265 seconds]
lucascastro has quit [Quit: Leaving]
lucascastro has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
lucascastro has quit [Ping timeout: 264 seconds]
hlauer has quit [Ping timeout: 272 seconds]
lucascastro has joined #linux-sunxi
eduardas has quit [Quit: Konversation terminated!]
mmarc___ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 272 seconds]
prefixcactus has joined #linux-sunxi
pCactus has quit [Ping timeout: 240 seconds]
prefixcactus has quit [Read error: Connection reset by peer]
pCactus has joined #linux-sunxi
hlauer has joined #linux-sunxi
lucascastro has quit [Ping timeout: 272 seconds]
mmarc__ has joined #linux-sunxi
lucascastro has joined #linux-sunxi
lucascastro has quit [Quit: Leaving]
lucascastro has joined #linux-sunxi
asdf28 has quit [Ping timeout: 246 seconds]
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 272 seconds]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 272 seconds]
hlauer has quit [Ping timeout: 272 seconds]
gaston1980 has quit [Quit: Konversation terminated!]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 272 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
<hexdump0815> jernej: i can confirm that your h616 hdmi tree is working well - just tested it on my h313 x96q box and i get hdmi output and also x11 is working using the modesetting driver ... my monitor is 1280x1024 vga connected via vga to hdmi adapter
<hexdump0815> jernej: i used the h616-v1 atf and h616-usb u-boot from apritzel: and your h616-hdmi kernel tree ... thanks a lot for your efforts!
cmeerw has quit [Ping timeout: 240 seconds]
matthias_bgg has quit [Ping timeout: 240 seconds]
<hexdump0815> jernej: apritzel: i think in the past the box even powered off on shutdown and now the led remains on - can this be due to the new u-boot maybe? now its h616-usb from apritzel and before it was h616-v2 from jernej
<hexdump0815> jernej: apritzel: i'm not using crust btw.
sandelinos[m] has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
<apritzel> hexdump0815: please just use mainline U-Boot, unless you desperately need USB
<apritzel> hexdump0815: and there is no ARISC processor anymore, so no crust
<hexdump0815> apritzel: ah ok - and i'm using mainline u-boot only
<apritzel> hexdump0815: it's important to get this tested as best as possible
<apritzel> for TF-A you can try h616-v2-wip, I will hopefully push something real this weekend
<hexdump0815> apritzel: any idea why the box did shut down properly before with the last mainline u-boot i used (jernej h616-v2 tree) and does not anymore with your h616-usb tree?
<hexdump0815> apritzel: or is that maybe more kernel related?
<apritzel> hard to say, I would actually suspect TF-A to be at fault
<hexdump0815> apritzel: i ment power off and not shutdown
<hexdump0815> apritzel: i used the same atf build in both cases
<apritzel> early power-off went directly through U-Boot, IIRC, but it should go through TF-A
<apritzel> haven't checked yet, need to rework the patches first, then will have a look
sunshavi has quit [Read error: Connection reset by peer]
netlynx has quit [Quit: Ex-Chat]
<hexdump0815> ok - np
sunshavi has joined #linux-sunxi
hexdump0815 has quit [Quit: Connection closed]
Mangy_Dog has quit [Remote host closed the connection]