aarch64-next on Mustang

[Itaru Kitayama]

Hi Claudio,

I am the HEAD of aarch64-next and tried it boot on Mustang:

$ qemu-system-aarch64 -nographic -M virt -enable-kvm -kernel
./build/release.aarch64/loader.img -cpu host -m 1024M -append "--nomount
/tools/uush.so"
OSv v0.05-2956-gf09fa1a
setup_arm_clock() ENTERED, lr=00000000400d098c
arm_clock(): frequency read as 0000000002faf080
interrupt_table::interrupt_table() ENTERED, lr=00000000400a96ec
gic_driver::init_cpu() ENTERED, lr=00000000402033e8
CPU interface enabled.
gic_driver::init_dist() ENTERED, lr=00000000402033f4
number of supported IRQs: 0000000000000100
interrupt table: gic driver created.
setup_arm_clock_events() ENTERED, lr=00000000400d098c
registered IRQ id=000000000000001b
thread_main_c: thread* t=00000000409c3e28
thread_main_c: thread* t=ffff900040e75000
thread_main_c: thread* t=ffff900040e8f000
thread_main_c: thread* t=ffff800040eaa048
thread_main_c: thread* t=ffff900040eb1000
thread_main_c: thread* t=ffff900040e96700
thread_main_c: thread* t=ffff900040ee3000
thread_main_c: thread* t=0000000040a11fe0
thread_main_c: thread* t=0000000040a11df0
thread_main_c: thread* t=0000000040a12870
thread_main_c: thread* t=ffff900040e79038
thread_main_c: thread* t=ffffa00040f53200
thread_main_c: thread* t=ffffa00040f53400
thread_main_c: thread* t=ffffa00040f53600
thread_main_c: thread* t=ffffa00040f53800
thread_main_c: thread* t=ffffa00040f53a00
thread_main_c: thread* t=ffffa00040f53c00
thread_main_c: thread* t=ffffa00040f53e00
thread_main_c: thread* t=ffffa00040f4b200
thread_main_c: thread* t=ffffa00040f4b400
thread_main_c: thread* t=ffffa00040f4b600
thread_main_c: thread* t=ffffa00040f93200
thread_main_c: thread* t=ffffa00040f93600
thread_main_c: thread* t=ffffa00040f93808
thread_main_c: thread* t=ffffa00040f93a00
thread_main_c: thread* t=ffffa00041bdc608
PCI irqmap
Bus,Device,Function 0x00000001 -> SPI irq 0x0031
B,D,F irqmap-mask 0x0000f8ff
Bus,Device,Function 0x00000801 -> SPI irq 0x0030
B,D,F irqmap-mask 0x0000f8ff
Bus,Device,Function 0x00001001 -> SPI irq 0x002f
B,D,F irqmap-mask 0x0000f8ff
registered IRQ id=0000000000000021
thread_main_c: thread* t=ffffa00041bdcc00
thread_main_c: thread* t=ffffa00041bdce00
page_fault ENTERED, lr=0000000040202824
faulting address 0000100000014f78
elr exception ra 000000004020036c
leaving page_fault()
page_fault ENTERED, lr=0000000040202824
faulting address 0000100000000198
elr exception ra 00000000401e13bc
leaving page_fault()
page_fault ENTERED, lr=0000000040202824
faulting address 0000100000001b6b
elr exception ra 00000000402826f0
leaving page_fault()
page_fault ENTERED, lr=0000000040202824
faulting address 0000100000002000
elr exception ra 00000000401e1bbc
leaving page_fault()
thread_main_c: thread* t=ffffa00041d4b808
page_fault ENTERED, lr=0000000040202824
faulting address 00001000000043bf
elr exception ra 00000000402aedd0
leaving page_fault()

uush $

Does the above what you see on your platform as well?

[hw.cl...@gmail.com]

Yes. I see you run uush, which is a -really minimal- shell for testing purposes. You can use it to launch other applications you build into the bootfs.

The kernel basically works now.
But we have substantial limitations, which you can see marked in red at:

https://github.com/cloudius-systems/osv/wiki/AArch64

Of these the core limitations from my point of view are:

1 cpu limit
lack of real floating point support in the libc/musl library
tls support is limited to the kernel, no tls variables in .so files.
lack of power management features (PSCI/ACPI).

To a slightly lesser extent, build system is also an issue, in that we cannot have persistent direct storage via ZFS (although we can use the network to achieve that).

Since I am not seeing us make use of apps/ and the python stuff in scripts/ etc, I see the lack of support there as less pressing, but they might be limiting to you depending on which use cases you are pursuing.

Ciao,

Claudio

[Nadav Har'El]

On Wed, Mar 11, 2015 at 10:50 AM, <hw.cl...@gmail.com> wrote:

On Monday, 9 March 2015 10:46:20 UTC+1, Itaru Kitayama  wrote:

The kernel basically works now.

Congratulations :-)
 

But we have substantial limitations, which you can see marked in red at:

https://github.com/cloudius-systems/osv/wiki/AArch64

Nice summary!
 

Of these the core limitations from my point of view are:

1 cpu limit

lack of real floating point support in the libc/musl library

Would upgrading musl help in this, or musl isn't good enough yet?

If upgrading musl would help, we need to continue the musl upgrade effort more seriously (we've already made quite a bit of progress there, but need to make the quantum leap).

 

tls support is limited to the kernel, no tls variables in .so files.
lack of power management features (PSCI/ACPI).

To a slightly lesser extent, build system is also an issue, in that we cannot have persistent direct storage via ZFS (although we can use the network to achieve that).

Since I am not seeing us make use of apps/ and the python stuff in scripts/ etc, I see the lack of support there as less pressing, but they might be limiting to you depending on which use cases you are pursuing.

Ciao,

Claudio

--
You received this message because you are subscribed to the Google Groups "OSv Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nadav Har'El

n...@cloudius-systems.com

[Claudio Fontana]

On 11 March 2015 at 10:03, Nadav Har'El <n...@cloudius-systems.com> wrote:
> On Wed, Mar 11, 2015 at 10:50 AM, <hw.cl...@gmail.com> wrote:
>>
>> On Monday, 9 March 2015 10:46:20 UTC+1, Itaru Kitayama wrote:
>> The kernel basically works now.
>
>
> Congratulations :-)
>

:-)

>>
>> But we have substantial limitations, which you can see marked in red at:
>>
>> https://github.com/cloudius-systems/osv/wiki/AArch64
>
>
> Nice summary!
>
>>
>>
>> Of these the core limitations from my point of view are:
>>
>> 1 cpu limit
>>
>> lack of real floating point support in the libc/musl library
>
>
> Would upgrading musl help in this, or musl isn't good enough yet?

It would help. Newer musl has support for ld128, which is needed for aarch64.