<div dir="ltr">ah sorry I forgot.<div><br></div><div>I think selfboot could be reworked (and should be) to interpret "0" as "somewhere useful"?<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 22, 2018 at 10:47 PM ron minnich <<a href="mailto:rminnich@gmail.com">rminnich@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">shouldn't we fix the riscv kernel build process? it's producing bad elf files? </div><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 22, 2018 at 4:40 PM Jonathan Neuschäfer <<a href="mailto:j.neuschaefer@gmx.net" target="_blank">j.neuschaefer@gmx.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
we've discussed this briefly at OSFC: Linux's ELF file (vmlinux)<br>
currently has segments starting at 0x0 (if you look at the physical<br>
address field) and an entry point at 0xffffffe000000000:<br>
<br>
> $ readelf -l vmlinux<br>
> <br>
> Elf file type is EXEC (Executable file)<br>
> Entry point 0xffffffe000000000<br>
> There are 3 program headers, starting at offset 64<br>
> <br>
> Program Headers:<br>
>   Type           Offset             VirtAddr           PhysAddr<br>
>                  FileSiz            MemSiz              Flags  Align<br>
>   LOAD           0x0000000000001000 0xffffffe000000000 0x0000000000000000<br>
>                  0x000000000000ffce 0x000000000000ffce  R E    0x1000<br>
>   LOAD           0x0000000000011000 0xffffffe000010000 0x0000000000010000<br>
>                  0x00000000002cda3c 0x00000000002cda3c  RWE    0x1000<br>
>   NOTE           0x00000000002dea00 0xffffffe0002dda00 0x00000000002dda00<br>
>                  0x000000000000003c 0x000000000000003c  R      0x4<br>
> <br>
>  Section to Segment mapping:<br>
>   Segment Sections...<br>
>    00     .init.text<br>
>    01     .init.data .exit.text .data..percpu .text .softirqentry.text .rodata __param __modver .srodata .data __bug_table .sdata .bss __ex_table .notes<br>
>    02     .notes<br>
<br>
<br>
coreboot's SELF loader rightly points out that 0x0 is not in RAM:<br>
<br>
> Loading segment from ROM address 0x00000000200287b8<br>
>   code (compression=0)<br>
>   New segment dstaddr 0x0 memsize 0xffce srcaddr 0x2002880c filesize 0xffce<br>
> Loading segment from ROM address 0x00000000200287d4<br>
>   code (compression=0)<br>
>   New segment dstaddr 0x10000 memsize 0x2cda3c srcaddr 0x200387da filesize 0x2cda3c<br>
> Loading segment from ROM address 0x00000000200287f0<br>
>   Entry Point 0xffffffe000000000<br>
> SELF Payload doesn't target RAM:<br>
> Failed Segment: 0x0, 65486 bytes<br>
>  0. 0000000080000000-0000000080011fff: RAMSTAGE<br>
>  1. 0000000080012000-000000008003ffff: RAM<br>
>  2. 0000000080040000-0000000080044fff: RAMSTAGE<br>
>  3. 0000000080045000-00000000fffdbfff: RAM<br>
>  4. 00000000fffdc000-00000000ffffffff: CONFIGURATION TABLES<br>
>  5. 0000000100000000-000000027fffffff: RAM<br>
> Payload not loaded.<br>
<br>
<br>
How should we solve this?<br>
<br>
One option I see is to keep CONFIG_PAYLOAD_ELF as is, and add quirks to<br>
CONFIG_PAYLOAD_LINUX.<br>
<br>
<br>
Jonathan<br>
</blockquote></div>
</blockquote></div>