Re: Porting Fiasco.OC to RISC-V - Questions

Hi Adam,

Thanks for your reply. I thought it would be a good idea to start with
L4Re to familiarize myself with Fiasco.OC/L4Re structure, and chose to
start with L4Re because it doesn't need a lot of architecture
dependent code. So, after your reply, I'd work on getting bootstrap
working and loading the "to-be-evolved" Fiasco.OC RISC-V kernel. This
would allow me to debug and test Fiasco.OC/risc-v as I add new
code/features their.

Best,
Hesham

On Thu, Mar 12, 2015 at 12:48 PM, Hesham ALMatary
<[email protected]> wrote:
> Hi Adam,
>
> Thanks for your reply. I thought it would be a good idea to start with
> L4Re to familiarize myself with Fiasco.OC/L4Re structure, and chose to
> start with L4Re because it doesn't need a lot of architecture
> dependent code. So, after your reply, I'd work on getting bootstrap
> working and loading the "to-be-evolved" Fiasco.OC RISC-V kernel. This
> would allow me to debug and test Fiasco.OC/risc-v as I add new
> code/features their.
>
> Best,
> Hesham
>
> On Wed, Mar 11, 2015 at 11:14 PM, Adam Lackorzynski
> <[email protected]> wrote:
>> Hi,
>>
>> On Wed Mar 11, 2015 at 17:53:58 +0000, Hesham ALMatary wrote:
>>> I'm considering porting Fiasco.OC/L4Re to RISC-V architecture (for
>>> both my research and GSoC). So, I started reading the documentation
>>> and building the environment (For Fiasco.OC and RISC-V tools), and
>>> QEMU (the emulator that I'll use initially) is running Hello World
>>> example just fine.
>>>
>>> After some reading, I wanted to start adding support for building L4Re
>>> for RISC-V (is this a good start?), and I came up with some questions.
>>>
>>> There are two variants of RISC-V ABI (32 and 64 bit) should I provide
>>> both or just 64-bit version?
>>
>> For starting, just choose one. The other type could be done later.
>>
>>> What are the minimal packages and/or Fiasco.OC system components that
>>> need to be implemented to get Hello World working? Please correct me
>>> if the following L4Re list is not right (contains more than needed, or
>>> lack others):
>>>
>>> "bootstrap, sigma0, moe, Log, libc, libc_minimal, cxx_util, cxx_io,
>>> cxx_base, cxx_io_kdebug,l4sys-direct, l4sys"
>>
>> Good list. To find out the exact list you can just do
>> "make O=... sigma0 moe bootstrap l4re_kernel hello" and then see in the
>> build directory what was actually built.
>>
>> But actually for starting, you just need boostrap because then comes the
>> kernel that needs to work before anything more needs to be done for the
>> user level components.
>>
>>> Some of the packages are architecture dependent which need some code
>>> from other projects (like uclibc), should I add them all? FYI, newlib
>>> has support for riscv, but uclibc doesn't,
>>
>> True that uclibc does not support riscv natively. But there's nearly no
>> architecture dependent code needed, so this is not really an issue.
>>
>>> how can I make the build
>>> system choose specific packages for the target architecture (riscv in
>>> this case) and maybe neglect building others?
>>
>> One way is putting 'broken' files in to package's root directory (e.g.
>> l4/pkg/hello/broken). Then there's the SYSTEMS variable which defines
>> for which architecture a library/program can be compiled for. Its
>> default is all architecture, so by not changing the default and just
>> adding riscv-l4f where you want it could also be a way.
>>
>>
>>
>> Adam
>> --
>> Adam                 [email protected]
>>   Lackorzynski         http://os.inf.tu-dresden.de/~adam/
>>
>> _______________________________________________
>> l4-hackers mailing list
>> [email protected]
>> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>
>
>
> --
> Hesham



-- 
Hesham