Darkmatter66 has quit [Quit: ZNC 1.7.1 - https://znc.in]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Quit: ZNC 1.7.1 - https://znc.in]
Darkmatter66 has joined #linux-amlogic
<AntonioND>
i'm thinking about GET_REBOOT_REASON (0x82000022) and another system call (0x82000042) that affect the "reboot reason" register. does it actually make sense to keep them in there? does linux even care? I know I need the system calls that give you the shared memory and that read the efuse for uboot, but is there anything else that linux needs to work? I'd rather keep this minimal, I don't like having many
<AntonioND>
firmware services
Darkmatter66 has quit [Client Quit]
<AntonioND>
khilman^
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Quit: ZNC 1.7.1 - https://znc.in]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Quit: ZNC 1.7.1 - https://znc.in]
Darkmatter66 has joined #linux-amlogic
The_Coolest has joined #linux-amlogic
The_Coolest has quit [Client Quit]
The_Coolest has joined #linux-amlogic
Darkmatter66 has quit [Quit: ZNC 1.7.1 - https://znc.in]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Client Quit]
trem has joined #linux-amlogic
Darkmatter66 has joined #linux-amlogic
moham_96 has joined #linux-amlogic
Darkmatter66 has quit [Client Quit]
moham_96 is now known as Darkmatter66
Darkmatter66_ has joined #linux-amlogic
trem has quit [Quit: Leaving]
<ldevulder>
AntonioND, narmstrong, I simply test with keeping the bl31.bin name instead of bl31.img, as the Amlogic u-boot code do this (they provid both version, I don't know why). No boot issue with the bl31.bin from Amlogic (of course), but bl31.bin generated byt ATF is still not working
<ldevulder>
but no more panic, just a freeze
<AntonioND>
hmmm
<AntonioND>
can you give me a link to that bl31.bin?
<AntonioND>
i suspect that this is simply crashing but the console address is different
<ldevulder>
FYI, I used this compiler to generate the ATF bl31.bin: gcc-linaro-7.2.1-2017.11-x86_64_aarch64-elf/bin/aarch64-elf-gcc, no issue during compilation, but bl31.bin is small (36993 bytes, but as it is a first basic implementation maybe it's logical)
<AntonioND>
you could give it a try: GXBB_UART0_AO_BASE set that define to the one that corresponds to that board
<AntonioND>
my bl31 is really small, yes
<AntonioND>
it's 50% of the original
<AntonioND>
because I don't care about any of the amlogic sip services
<AntonioND>
only about power management
Darkmatter66 has quit [Remote host closed the connection]
<ldevulder>
AntonioND, uart address is the same for s905x: configs/khadas-vim_defconfig:CONFIG_DEBUG_UART_BASE=0xc81004c0
<AntonioND>
hmmm
<AntonioND>
so not even the crash console works
<AntonioND>
that's weird
Darkmatter66_ has quit [Quit: ZNC 1.7.1 - https://znc.in]
<poulecaca>
I also just add the first 512bytes of what is what I think only a header of the amlogic bl31.img to your bl31.bin. And same freeze here.
<poulecaca>
no print
<ldevulder>
generating options for u-boot image with bl* blob are not the same for s905 and s905x, maybe it's something here
<AntonioND>
what kind of information is there in the header?
<poulecaca>
it's mainly null bytes. But I havn't managed to guess the meaning of the non-null ones
<AntonioND>
have you done the test to modify a random string in the original bl31.bin and running with that one? a string that you can see during boot, obviously
<AntonioND>
i assume that this doesn't have any kind of secure boot, right?
<AntonioND>
no, wait, don't bother
<AntonioND>
if it didn't wokr bl2 would probably hang
<AntonioND>
so yeah, that is fine
<poulecaca>
yes I modified a string in bl31.bin boot it and that went ok
<poulecaca>
so no secure boot at the bl3* level at least. bl2 may be signed though.
<AntonioND>
the memory map starts at that hex address
<AntonioND>
0x25250
<ldevulder>
yes bl2 looks signed
<AntonioND>
that's the mmap array with all the memory regions
<AntonioND>
well, most of them
<AntonioND>
there is something at 0x05200000 that isn't there in gxbb
<AntonioND>
otherwise... they are quite similar
<AntonioND>
i don't know what the problem is, it's hard to tell. however, the crash console should work really really early during boot of bl31
<AntonioND>
10 instructions after the entrypoint early
<AntonioND>
i'm wrong
<AntonioND>
6
<AntonioND>
the 6th instruction sets the vbar
<AntonioND>
from that point, the crash console should work
<AntonioND>
there is the possibility that my console driver is broken
<AntonioND>
could you try to turn console_meson_init into an empty function?
<AntonioND>
put a "mov w0,#1 \n ret" just at the start
jakogut has joined #linux-amlogic
<ldevulder>
AntonioND, still freeze, like before the last thing I have on the console is from bl2: "Load bl33 from SD, src: 0x0002c200, des: 0x01000000, size: 0x0007c400"
<ldevulder>
AntonioND, but I tried with bl31.bin from Amlogic without issue, not bl31.img, bl31.img is bl31.bin with the header
<ldevulder>
I use the tool from Amlogic: aml_encrypt_gxl
<ldevulder>
it's not fip_create anymore on s905x
<AntonioND>
maybe the img header is important
<AntonioND>
they need to store the size somewhere
<AntonioND>
so yeah, no idea
<AntonioND>
but again, it may be that the platorm is too different...
<ldevulder>
looks like
<ldevulder>
anyway, it was not too difficult to test
<ldevulder>
s905x and s912 are more close than s905 and s905x :)
<AntonioND>
yeah, it wasn't a huge waste of effort
<AntonioND>
and this bl31 was built pretty recently
<AntonioND>
25230 Built : 15:20:30, Feb 7 2018
<AntonioND>
(compared to gxbb anyway)
<ldevulder>
yes, it the last know
<ldevulder>
and it's the same for gxl and gxm
<ldevulder>
but not usable for gxbb
<AntonioND>
at some point I should really take a look at the dts'es
<AntonioND>
they don't have any useful information about the secure world, though
<AntonioND>
because... why would they?
<AntonioND>
linux doesn't care
<ldevulder>
available in u-boot :) but don't know for secure world
<AntonioND>
yeah, that's the problem
<AntonioND>
tbh i'm glad that they left a lot of undocumented registers in uboot
<AntonioND>
at least I can give names to my magic operations
<AntonioND>
i don't understand them, but the registers have names
<ldevulder>
but I think that Baylibre is working on the secure monitor in u-boot, don't know if it's related
<AntonioND>
secure monitor... as in psci and that kind of things?
<ldevulder>
I think yes
<AntonioND>
well
<AntonioND>
good luck :P
<AntonioND>
that's all I can say xD
<AntonioND>
uboot doesn't support multicore, right?
<ldevulder>
don't think so
<ldevulder>
(and not sure it is useful in u-boot)
<AntonioND>
i don't really think it is...
<AntonioND>
also, psci is... tricky
<AntonioND>
i've seen people in my team discuss for hours about that, and they have all the insider info about the cpus and specs and everything
<AntonioND>
so i'm not sure if it is wise to try to replicate it
<AntonioND>
i would certainly appreciate a gpl firmware, though
<ldevulder>
:)
<AntonioND>
in any case, what I'm trying to do now is to port our internal test suite to the gxbb
<AntonioND>
it will be made public hopefully this week
<AntonioND>
it will be useful for psci
<ldevulder>
AntonioND, I tried to change the address for bl31 in your ATF code for gxl, and it's a bit better I think (at least the xlat_tables_core.c file mentioned is in ATF): http://paste.opensuse.org/67116225
<AntonioND>
oh, nice!
<ldevulder>
don't know if it's very useful but it's progressing! :D
<AntonioND>
not enough tables
<AntonioND>
MAX_XLAT_TABLES
<AntonioND>
increase that
<AntonioND>
in meson/gxbb/include/platform_def.h
<AntonioND>
plat/meson/...
<ldevulder>
I also revert the change in meson_console.S