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>
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>
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]
<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
<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
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]