Native on ARM Cortex-A53

[Mark Staver]

Hi,

Cortex-A53 is used with most popular Raspberry Pi computers for now. So on my vision partly success of Inferno and limbo depend on such task. That computers are used especially for education.

May some one point on ways of using most important parts of that SoC.

ARM® TrustZone® -  boot process  depend on that technology so implementing file server to access some protected memory or devices. e.g. with optee_os.

AArch64 - many of you already know that step is necessary in the case Inferno is planing to grow at any how.

For now I'am studding Inferno  and "coding" Telegramm bot, may be HID 

Have to read and find out how it works. That forum I guess have people can point on necessary parts of code.

Thank you indeed. 

[bhgv]

to use on Raspberry (or any Raspberry like) the best is using of Linux kernel + Inferno (as it does Android). Why? because of drivers. part of drivers on these "opensource" hardware are closed. and will always be closed. due to high competition and licenses.

 

to use on Arm-64 platform just remove the JIT compiling in the time of execution. especially because of JIT-compiling to Arm-FPU isn't correct (it compiles to old unsupported Arm-FPU commands). to prevent JIT compiling in the emu just add next line to the `/emu/Linux/emu` config, to the 'code' section:

```

# /emu/Linux/emu

code

   int dontcompile = 1;

```

 

JIT is not too necessary. dis code without JIT compiling executes faster and consumes significantly lower memory than .net (C#) code with JIT compiling

 

вторник, 13 февраля 2018 г., 15:11:05 UTC+2 пользователь Mark Staver написал:

[Mark Staver]

"the best is using of Linux kernel + Inferno" with all respect...  best way to ride a horse is to ride it but not to put on an elephant... I do realize there is many problems on that way... But Raspberry made for education. Firs eight seconds of video on official web page says it... https://www.raspberrypi.org/products/raspberry-pi-3-model-b/

I guess drivers can be given not as source codes but binaries to build Inferno... other question: is inferno ready for that?

Thank you describing that necessary part. 

вторник, 13 февраля 2018 г., 16:55:56 UTC+3 пользователь bhgv написал:

[Timothy Gaskell]

Does anyone know exactly what changed in the Raspberry Pi platform that prevents the older Inferno Pi project from being forward compatible?

[Ethan Grammatikidis]

On Tue, Feb 13, 2018, at 1:11 PM, Mark Staver wrote:
>
> success of Inferno and limbo

> in the case Inferno is planing to grow

Sorry, but I don't think "success" and "growth" are priorities. As evidence, I haven't seen a mail from Inferno's maintainer on this list for a long time.

If you can successfully port Inferno to RPi, I'm sure some will appreciate your efforts, but I'm sorry, I've seen a lot of questions like yours from people who weren't capable of figuring out how to find the information for themselves, let alone get started on an actual port. You'll need a lot of patience, I think.

Sort-of related: I recently started programming again. I had to re-learn how to think, especially how to focus on a task without getting overwhelmed. A friend of mine told me he has to re-learn how to think approximately annually, and doesn't even have my excuse for it. :) Mostly I had to learn to take breaks when I get confused, and let the ideas percolate and the big picture come to mind.

--
The lyf so short, the craft so long to lerne. -- Chaucer

[Mark Staver]

http://people.linaro.org/~rikuvoipio/aarch64-talk/#/19

среда, 14 февраля 2018 г., 9:14:41 UTC+3 пользователь Timothy Gaskell написал:

[Ethan Grammatikidis]

Uh... sorry for my confusion, but wouldn't an Inferno Pi project be native? The linked post is just news about Linux syscalls.

To reply to Timothy's question, I don't know specifics, but in general, platforms other than X86/AMD64 and *maybe* POWER are not forward- or backward-compatible. The CPU may be similar, but everything else can change.

[Mark Staver]

Inferno Pi is interesting project but armv6 based... 

Have somebody compile kernel with LLVM?

and is is possible to replace 5* by LLVM 

ARMv8 have 2 execution states 32 & 64

4 exception lvl 

..app

..op sys

..hypervisor

..trust

A64 instruction set

diff around registers

armv6:

typedef struct Ureg {

uint r0;

uint r1;

uint r2;

uint r3;

uint r4;

uint r5;

uint r6;

uint r7;

uint r8;

uint r9;

uint r10;

uint r11;

uint r12;

union {

uint r13;

uint sp;

};

uint r14;

uint link;

uint type;

uint psr;

uint pc;

} Ureg;

AArch64 general-purpose registers

x0 64 bit / w0 32bit - lower part of x0 register

X0/W0

X1/W1

X2/W2

X3/W3

X4/W4

X5/W5

X6/W6

X7/W7

X8/W8

X9/W9

X10/W10

X11/W11

X12/W12

X13/W13

X14/W14

X15/W15

X17/W17

X18/W18

X19/W19

X20/W20

X21/W21

X22/W22

X23/W23

X24/W24

X25/W25

X26/W26

X27/W27

X28/W28

X29/W29 Frame pointer

X30/W30 Procedure link register

EL0, EL1, EL2, EL3

Special registers in AArch64

Name	Size	Description
WZR	32 bits	Zero register
XZR	64 bits	Zero register
WSP	32 bits	Current stack pointer
SP	64 bits	Current stack pointer
PC	64 bits	Program counter

Special registers by Exception level

	EL0	EL1	EL2	EL3
Stack Pointer (SP)	SP_EL0	SP_EL1	SP_EL2	SP_EL3
Exception Link Register (ELR)		ELR_EL1	ELR_EL2	ELR_EL3
Saved Process Status Register (SPSR)		SPSR_EL1	SPSR_EL2	SPSR_EL3

EL0 - trusted 

That is basic

вторник, 13 февраля 2018 г., 16:11:05 UTC+3 пользователь Mark Staver написал:

[Charles Forsyth]

Inferno won't run in 64-bit mode either native or hosted.

Getting the bulk of the kernel code to run in 64-bit mode isn't that hard but Dis and its implementation is more tightly bound to 32-bit (eg, pointers are 32 bits, and offsets are collapsed into addresses) so I'm afraid there's little point in extending the kernels until that's fixed.

Limbo itself doesn't really care.

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

[Mark Staver]

can you point on code?

понедельник, 5 марта 2018 г., 18:13:37 UTC+3 пользователь Charles Forsyth написал:

To unsubscribe from this group and stop receiving emails from it, send an email to inferno-os+...@googlegroups.com.

[Hendrik Boom]

On Mon, Mar 05, 2018 at 03:13:35PM +0000, Charles Forsyth wrote:
> Inferno won't run in 64-bit mode either native or hosted.
> Getting the bulk of the kernel code to run in 64-bit mode isn't that hard
> but Dis and its implementation is more tightly bound to 32-bit (eg,
> pointers are 32 bits, and offsets are collapsed into addresses) so I'm
> afraid there's little point in extending the kernels until that's fixed.
> Limbo itself doesn't really care.

So porting to 64-bit mode would require a full bootstrap.

Redesigning Dis to handle 64-bit addresses and data, rewriting Limbo's
code generator to generate 64-bit Dis, using the old one to compile the
new one and then using the new one to compile itselt, then checking
that the new new one compiles itself reproducibly.

And then wondering hom much code there is in inferno that relies on
integers being only 32 bits.

Maybe there's some language design to be done here, too?

-- hendrik

[bhgv]

for dis registers:

typedef int64_t int;
typedef uint64_t uint;
typedef int64_t long;

inside inferno are many conversations *a_type -> *void -> *a_type. but they will be 64bit automatically.

i think this is possible, but it takes a lot of time to debugging. not on bare metall raspberry, but hosted on 64bit linux (ddd debuger) or 64 bit windows (msvs debuger). key word here - debuger. as good as it possible.
and yes, it requires good experience in such works (debuging and porting and debuging)

[Ethan Grammatikidis]

On Sat, Mar 10, 2018, at 4:03 PM, Hendrik Boom wrote:
>
> And then wondering hom much code there is in inferno that relies on
> integers being only 32 bits.

64-bit 9front has 32-bit ints. i think it made for a lot less work, but i wasn't really involved.

[Mark Staver]

U-Boot> dm uclass

uclass 0: root

- * root_driver @ 3af45050, seq 0, (req -1)

uclass 10: simple_bus

- * soc @ 3af45160, seq 0, (req -1)

-   clocks @ 3af47e20

uclass 13: blk

- * m...@7e202000.blk @ 3af476a0, seq 0, (req -1)

-   sd...@7e300000.blk @ 3af47ac0

EFI: Initializing UCLASS_EFI

uclass 19: efi

uclass 20: eth

- * smsc95xx_eth @ 3af610c0, seq 0, (req -1)

uclass 21: gpio

-   gpio_bcm2835 @ 3af48090

uclass 29: keyboard

uclass 33: usb_mass_storage

uclass 35: mmc

- * mmc@7e202000 @ 3af47450, seq 0, (req -1)

- * sdhci@7e300000 @ 3af478b0, seq 1, (req -1)

uclass 40: panel

uclass 41: backlight

uclass 46: pinconfig

-   dpi_gpio0 @ 3af45360

-   emmc_gpio22 @ 3af45410

- * emmc_gpio34 @ 3af454c0, seq 4, (req -1)

-   emmc_gpio48 @ 3af45570

-   gpclk0_gpio4 @ 3af45620

-   gpclk1_gpio5 @ 3af456d0

-   gpclk1_gpio42 @ 3af45780

-   gpclk1_gpio44 @ 3af45830

-   gpclk2_gpio6 @ 3af458e0

- * gpclk2_gpio43 @ 3af45990, seq 1, (req -1)

-   i2c0_gpio0 @ 3af45a40

-   i2c0_gpio28 @ 3af45af0

-   i2c0_gpio44 @ 3af45ba0

-   i2c1_gpio2 @ 3af45c50

-   i2c1_gpio44 @ 3af45d00

-   i2c_slave_gpio18 @ 3af45db0

-   jtag_gpio4 @ 3af45e60

-   jtag_gpio22 @ 3af45f10

-   pcm_gpio18 @ 3af45fc0

-   pcm_gpio28 @ 3af46070

-   pwm0_gpio12 @ 3af46120

-   pwm0_gpio18 @ 3af461d0

-   pwm0_gpio40 @ 3af46280

-   pwm1_gpio13 @ 3af46330

-   pwm1_gpio19 @ 3af463e0

-   pwm1_gpio41 @ 3af46490

-   pwm1_gpio45 @ 3af46540

- * sdhost_gpio48 @ 3af465f0, seq 3, (req -1)

-   spi0_gpio7 @ 3af466a0

-   spi0_gpio35 @ 3af46750

-   spi1_gpio16 @ 3af46800

-   spi2_gpio40 @ 3af468b0

-   uart0_gpio14 @ 3af46960

-   uart0_ctsrts_gpio16 @ 3af46a10

-   uart0_ctsrts_gpio30 @ 3af46ac0

- * uart0_gpio32 @ 3af46b70, seq 0, (req -1)

-   uart0_gpio36 @ 3af46c20

-   uart0_ctsrts_gpio38 @ 3af46cd0

- * uart1_gpio14 @ 3af46d80, seq 2, (req -1)

-   uart1_ctsrts_gpio16 @ 3af46e30

-   uart1_gpio32 @ 3af46ee0

-   uart1_ctsrts_gpio30 @ 3af46f90

-   uart1_gpio40 @ 3af47040

-   uart1_ctsrts_gpio42 @ 3af470f0

-   gpioout @ 3af471a0

-   alt0 @ 3af47250

uclass 47: pinctrl

- * gpio@7e200000 @ 3af45270, seq 0, (req -1)

uclass 58: serial

-   serial@7e201000 @ 3af47340

- * serial@7e215040 @ 3af477e0, seq 0, (req -1)

uclass 68: usb

- * usb@7e980000 @ 3af47d70, seq 0, (req -1)

uclass 69: usb_dev_generic

uclass 70: usb_hub

- * usb_hub @ 3af49090, seq 0, (req -1)

- * usb_hub @ 3af604d0, seq 1, (req -1)

uclass 71: video

- * hdmi@7e902000 @ 3af47c40, seq 0, (req -1)

uclass 73: vidconsole0

- * hd...@7e902000.vidconsole0 @ 3af48910, seq 0, (req -1)

The ARMv8-A long descriptor format is always used in AArch64 Execution state. This is similar to the ARMv7-A long descriptor format with Large Physical Address Extensions. It uses the same 64-bit long-descriptor format, but with some changes. It introduces a Level 0 table index, which uses the same descriptor format as the level 1 table. There is added support for up to 48-bit input and output addresses. The input virtual address is now 64-bit.

(c) https://developer.arm.com/products/architecture/a-profile/docs/100940/latest/translation-tables-in-armv8-a

But I guess it is good enough to run hypervisor

In some existing hypervisor solutions, such as KVM or Xen, giving guests access to platform devices is uncommon. Both of these hypervisors provide a virtual platform and emulate all devices, exceptions are only made for network or storage controllers, which might not be platform devices.

(c) https://developer.arm.com/products/architecture/a-profile/docs/100942/latest/hypervisor-software

the 32-bit application can execute and generate a Supervisor Call (SVC) instruction, or receive an interrupt, causing a switch to EL1 and AArch64. (See Exception handling instructions.)

(c) http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/CHDIHCJE.html

if so, we can run.

may be some hypervisor to deploy host for kernels, a32 ot t32 to begin, than execute a64 vitrual machine.

all of this is to "using  the old one to compile the new one"

I am wandering can we use.... clang as compiler with mk?

CC=clang

CFLAGS=-c --target=aarch64 -march=armv8-a+simd+fp -I./include -I$ROOT/include -I$ROOT/libinterp

$CC $CFLAGS -DKERNDATE=$KERNDATE $CONF.c

суббота, 10 марта 2018 г., 19:03:54 UTC+3 пользователь Hendrik Boom написал:

[Charles Forsyth]

Instead of having a 64-bit version of Dis, since any change would be disruptive, I had in mind something more radical:

replacing Dis by a completely different representation, essentially an encoded fully-typed medium-level intermediate tree representation,

which would be safe to exchange being easy to check (which Dis is not), and from which respectable code could be generated dynamically in obvious ways.

A similar approach has been used for Oberon (Thin Binaries) and JavaScript.

It's possible to include a code generator from that representation to existing Dis.

There are some implications for the language, for instance the len operator returns the length of strings in characters and number of elements of an array (perhaps array of byte).

On a 64-bit machine that is sensibly 64-bits, which implies that int would also be 64 bits, to avoid requiring new explicit type conversions

for example in for(i := 0; i < len a; i++) ... . Unlike C, the underlying representation of complex data structures is not accessible, but as with Plan 9 C programs, before u32int etc,

there will be instances where for instance masks are created. Several languages and libraries introduced explicit sizes ("int64", "int32") for those cases.