Yes, kernel can be start at any address.
You can refer to BBL implementation : https://github.com/riscv/riscv-pk
BBL converts vmlinux to binary and inserts it into the section named .payload
which is one section of BBL.
Because the size of the BBL cannot be known before compiling and linking,
On 2018-09-26 10:29 PM, Philipp Hug wrote:
> In my local tree I just added the ram address in selfboot.
> Doing this beforehand with cbfstool would be even better. (E.g. only
> when choosing linux payload)
>
The proposed mechanism was already implemented here:
This elf file is position-independent and can be loaded to any location. We can
add a simple script to handle it.
1. Convert vmlinux to binary by objcopy, the binary file name is flat_file
2. Write a simple assembly file (tmp.S), convert binary to object, the file
name is obj_file
```
.section
In my local tree I just added the ram address in selfboot.
Doing this beforehand with cbfstool would be even better. (E.g. only when
choosing linux payload)
The FIT probably needs to be created by distro tools: assembling kernel, dt
and initramfs.
On Wed, Sep 26, 2018, 17:42 ron minnich wrote:
But the kernel can start anywhere. I don't see a reason to do this complex
objcopy step when all that is needed is to have cbfstool set some entries
in the SELF or just have selfboot use "0" to mean "somewhere useful"? Did I
miss something?
On Tue, Sep 25, 2018 at 10:32 PM 王翔 wrote:
> This elf
Am Di., 25. Sep. 2018 um 13:50 Uhr schrieb Jonathan Neuschäfer <
j.neuschae...@gmx.net>:
> Would FIT support require discussion/cooperation with other projects
> like Linux or u-boot?
>
> What seems to be missing is the kernel image format to be used within the
FIT. e.g. look at arm64:
On Mon, Sep 24, 2018 at 09:45:40AM -0600, Aaron Durbin via coreboot wrote:
> On Sun, Sep 23, 2018 at 9:00 AM ron minnich wrote:
> >
> > ah sorry I forgot.
> >
> > I think selfboot could be reworked (and should be) to interpret "0" as
> > "somewhere useful"?
Seems like a good idea.
And then the
On Sun, Sep 23, 2018 at 06:42:14PM +0200, Patrick Rudolph wrote:
> Can you make use of the uImage/FIT [1] mechanism coreboot supports ?
> It just needs some architecture specific code.
Good idea. I've seen the FIT support patches and I think FIT looks
reasonable, at least for loading Linux.
On Sun, Sep 23, 2018 at 9:00 AM ron minnich wrote:
>
> ah sorry I forgot.
>
> I think selfboot could be reworked (and should be) to interpret "0" as
> "somewhere useful"?
Why is the kernel being loaded at 0?
>
> On Sat, Sep 22, 2018 at 10:47 PM ron minnich wrote:
>>
>> shouldn't we fix the
Can you make use of the uImage/FIT [1] mechanism coreboot supports ?
It just needs some architecture specific code.
Can you provide a ling to the Linux calling conventions for riscv ?
[1] https://doc.coreboot.org/lib/payloads/fit.html
Regards,
Patrick
On 2018-09-23 04:59 PM, ron minnich wrote:
ah sorry I forgot.
I think selfboot could be reworked (and should be) to interpret "0" as
"somewhere useful"?
On Sat, Sep 22, 2018 at 10:47 PM ron minnich wrote:
> shouldn't we fix the riscv kernel build process? it's producing bad elf
> files?
>
> On Sat, Sep 22, 2018 at 4:40 PM Jonathan
shouldn't we fix the riscv kernel build process? it's producing bad elf
files?
On Sat, Sep 22, 2018 at 4:40 PM Jonathan Neuschäfer
wrote:
> Hi,
>
> we've discussed this briefly at OSFC: Linux's ELF file (vmlinux)
> currently has segments starting at 0x0 (if you look at the physical
> address
Hi,
we've discussed this briefly at OSFC: Linux's ELF file (vmlinux)
currently has segments starting at 0x0 (if you look at the physical
address field) and an entry point at 0xffe0:
> $ readelf -l vmlinux
>
> Elf file type is EXEC (Executable file)
> Entry point 0xffe0
>
13 matches
Mail list logo
