ArmV8 / Aarch64 / ARM64... what would it take?

Want a new feature? Discuss what you would like to see in Ultibo.
aaronpeacock
Posts: 8
Joined: Wed Mar 23, 2016 9:31 pm

ArmV8 / Aarch64 / ARM64... what would it take?

Postby aaronpeacock » Wed Mar 23, 2016 9:38 pm

What would it take to run your amazing-groundbreaking-cool-software on ARM64 / aarch64 / armv8 ?

I am specifically looking at the Allwinner A64's that are coming out in several new low-priced boards.
aaronpeacock
Posts: 8
Joined: Wed Mar 23, 2016 9:31 pm

Re: ArmV8 / Aarch64 / ARM64... what would it take?

Postby aaronpeacock » Wed Mar 23, 2016 11:17 pm

for that matter, what's the support for the Raspberry Pi 3 ?
User avatar
Ultibo
Site Admin
Posts: 2189
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: ArmV8 / Aarch64 / ARM64... what would it take?

Postby Ultibo » Wed Mar 23, 2016 11:32 pm

Hi, thanks for the comments. Glad you like it.

We've been doing a little bit of research lately into what would be needed for an aarch64 build of Ultibo core and surprisingly it is less work than it might seem since FPC already has aarch64 support.

One of the problems with supporting a new architecture is having a source of easily obtainable boards to work with, the recent release of Raspberry Pi 3 with quad core ARMv8 Cortex A53 has answered that question.

Most of the work required would be in the platform support layers, low level things like cache management, MMU, page tables, interrupt and exception handling and context switching. These are all done within the platform units (PlatformARM, PlatformARMv8 etc) and are nicely abstracted from the core code which is deliberately kept as pure pascal.

All of the subsystems like filesystem and network would need rechecking for incorrect pointer arithmetic (code that assumes a pointer is 32 bits) but I have done that exercise before with other projects and the FPC compiler is pretty good at pointing out non portable uses of pointers.

As for supporting other chipsets, the Allwinner chips are high on the list because they are showing up in a lot of new boards and seem to have pretty good documentation available. Some additional drivers would be needed like an EHCI USB host driver but those things only need to be done once.

A question for you, do you have specific Allwinner A64 boards in mind? I know about the Pine64, do you have URLs for others?

As a call out to manufacturers, if you would like to see your board supported by Ultibo feel free to contact us and we will happily discuss it.
Ultibo.org | Make something amazing
https://ultibo.org
User avatar
Ultibo
Site Admin
Posts: 2189
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: ArmV8 / Aarch64 / ARM64... what would it take?

Postby Ultibo » Wed Mar 23, 2016 11:49 pm

aaronpeacock wrote:for that matter, what's the support for the Raspberry Pi 3 ?

As of Ultibo core 1.1.069 the Raspberry Pi 3 is supported in 32 bit mode, just choose Raspberry Pi 2 when creating a project and everything will work correctly.

For 64 bit support there are a couple of extra hurdles to overcome yet because the Raspberry Pi foundation don't actually have a 64 bit loader in their firmware so the initial boot (at power on or reset) would have to be handled a little differently. From reading the RPi forums it seems that projects like U-Boot have already got experimental support for RPi3 in aarch64 working and there is also the option to add a small bit of loader code to the start of our kernel image to handle what would normally be done by the firmware like parking the secondary cores, setting the execution mode and enabling some defaults.

There is a lack of documentation so far about the specifics of the RPi3 implementation, it is mostly the same as RPi2 but some info about the differences is starting to appear in public. Mostly this effects both 32 bit and 64 bit so it doesn't really stop any progress.
Ultibo.org | Make something amazing
https://ultibo.org
aaronpeacock
Posts: 8
Joined: Wed Mar 23, 2016 9:31 pm

Re: ArmV8 / Aarch64 / ARM64... what would it take?

Postby aaronpeacock » Sun Mar 27, 2016 10:01 pm

Ultibo wrote:Hi, thanks for the comments. Glad you like it.


it's focused on what i consider the essentials for what I think should be a more considered niche in computing!
I'm personally interested in real-time audio.

Ultibo wrote:A question for you, do you have specific Allwinner A64 boards in mind? I know about the Pine64, do you have URLs for others?


That and the ODROID C2.


Thank you for your prompt, informative, and interested response! I really appreciate it.
aaronpeacock
Posts: 8
Joined: Wed Mar 23, 2016 9:31 pm

Re: ArmV8 / Aarch64 / ARM64... what would it take?

Postby aaronpeacock » Mon Mar 28, 2016 4:24 pm

sorry, my bad. the ODROID appears to be another (faster!) aarch64 quad-core....

generally, an interesting side-note is that Linaro - the open source coalition for arm tools (aren't they the toolchain providers for baremetal aarch64/arm64? their download links were working today when i checked, anyway) is sponsoring the the 96boards initiative for a standard
http://www.linaro.org/news/linaro-annou ... velopment/

http://www.96boards.org
shows some pretty interesting targets including a board with a HiSilicon Kirin 620 eight-core ARM Cortex-A53 64-bit SoC running at 1.2GHz and delivering over 10,000 Dhrystone VAX MIPS total performance...
---

back on topic: so, Ultibo has 3 parts: Lazarus modified, FPC, and core, correct?
I'm kind of ignorant, generally, in life... so if we could outline/isolate which files need which data per SOC (chip),
(i'm assuming if you say "the rest, pure pascal" that you are referring to assembly code in these lower-level drivers etc?)
maybe this is something that other people can hack away at on all their boards and help the effort somehow, given guidance... some kind of tutorial, i don't know... I'm trying to think of how to help the effort... I can't personally commit yet to bringing a board up as I don't know enough about your platform etc. I had a rough look at the github at 4am last night LOL
aaronpeacock
Posts: 8
Joined: Wed Mar 23, 2016 9:31 pm

Re: ArmV8 / Aarch64 / ARM64... what would it take?

Postby aaronpeacock » Mon Mar 28, 2016 4:42 pm

yeah, generally i'm seeing a u-boot approach to most of these new chipsets for baremetal bringup.
User avatar
Ultibo
Site Admin
Posts: 2189
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: ArmV8 / Aarch64 / ARM64... what would it take?

Postby Ultibo » Tue Mar 29, 2016 12:48 am

Hi, no problem about the ODROID C2, you reminded me to finally have a good look at the specs since it was released on the same day as the RPi3.

Thanks for the 96Boards link, that is exactly the sort of initiative needed to make this sort of embedded development sustainable. I'll be following their progress closely to see how it evolves.

I'm not sure that I can write a full on tutorial yet on how to bring up a new board but I'll start with some basics and see where it goes from there. For any given board there are 3 factors involved:

  1. The CPU used (eg ARM Cortex-A7, ARM Cortex-A53 etc), this is internal to the chip but the licensing from ARM gives a certain guarantee about the behavior and functionality.
  2. The SoC or chipset used (eg Broadcom 2836, Freescale iMX6 or Allwinner A64), this sets the peripherals available (USB, SD, I2C, SPI etc) and the interfaces used to communicate with them.
  3. The board itself and the decisions made by the designers about which peripherals to attach to which pins and what features are enabled or not.
For Ultibo core we have followed a similar model to allow maximum code reuse for each board to be supported. The model isn't perfect and will likely need some adjustment over time but it's a starting point.

Each CPU variant is supported by a unit that covers the low level functions (cache, MMU, interrupts etc), if you look at PlatformARMv7.pas for example you will see lots of constants that define the register bits and lots of assembler that implements the CPU specifics. The PlatformARMv8.pas unit is currently nearly identical to ARMv7 but will get expanded to cover the aarch64 stuff as well. These units are intended to be reused by many supported boards so they contain only CPU specific code.

Above that there are platform units for each board (eg PlatformRPi2.pas) which work in conjunction with a chipset unit (eg BCM2836.pas) and define what peripherals are available and where to find them. These units contain a lot of addresses and other information like actual IRQ numbers for certain devices as well as the page table layout appropriate for the board and chip. They can contain some assembler if required but much of the functionality can be implemented directly in pascal.

Each specific board also has a boot unit (eg BootRPi2.pas) which handles the very low level boot process, things like setting up an initial stack and heap, clearing the bss section of the loaded image, setting interrupt vectors and handling any details passed from the bootloader. These units are almost always in assembler in order to kick off the environment required by the run time library.

Then there are the driver units which implement the behavior required for a specific piece of hardware. A good example is the USB subsystem, the USB.pas unit provides the USB core and is mostly agnostic about the board, chip or CPU. The USB unit requires a host driver unit to implement the actual device communication, in the case of the Pi this is the DWCOTG.pas unit.

In a way the Raspberry Pi is an unusual choice to start with because it uses a non standard USB device that is not used by any other board, most boards will use the standards based EHCI, OHCI and XHCI interfaces instead. Equally the use of proprietary firmware is unusual since the majority of other boards rely simply on U-Boot as the bootloader. Of course the choice to begin with Raspberry Pi was mostly about the availability of it and the huge amount of information to use as a reference.

I don't know if this helps anyone wanting to make progress on getting support for other boards, in the end any contribution will help. Simply creating the chipset unit for a new SoC that defines all of the addresses, peripherals and IRQ numbers as well as structures that describe the built in devices (like timers and UARTs etc) would speed the process a lot since the documentation for these chips is sometimes many hundreds of pages long.
Ultibo.org | Make something amazing
https://ultibo.org
aaronpeacock
Posts: 8
Joined: Wed Mar 23, 2016 9:31 pm

Re: ArmV8 / Aarch64 / ARM64... what would it take?

Postby aaronpeacock » Sun Jun 26, 2016 8:44 am

So.... I got an odroid-c2
(with an Amlogic S905- public datasheet was just released - http://dn.odroid.com/S905/DataSheet/S90 ... V1.1.4.pdf )

and I'm planning on downloading Ultibo core (gotta get my old battered pc laptop back from a friend first) and populating the various mappings, so I want to confirm and specify what needs doing to be sure:

1) PlatformARMv8.pas still needs work?
2) PlatformOdroidC2.pas would need to be created by cloning PlatformRPi2.pas and then digging into my odroid SOC datasheet etc, right?
3) driver modifications as mentioned (does Ultibo have a TDM over I2S unit? this is probably the only original driver I will need to make)
4) ? more?

I just want to confirm if there are other steps needed. Also, since I have the odroid-c2 and can confirm that a customized uboot is the secondary boot loader (primary is closed source, per usual)
will I simply upload a binary compiled by ultibo straight to uboot? what's the overall boot process look like with ultibo in a uboot environment?
(vs Raspberry Pi and it's GPU doing the CPU/memory config and loading)

Thank you for any tidbits of advice etc... that will help me bring up a new board. once I get it working, what's the preferred means of contributing?
User avatar
Ultibo
Site Admin
Posts: 2189
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: ArmV8 / Aarch64 / ARM64... what would it take?

Postby Ultibo » Sun Jun 26, 2016 10:46 am

aaronpeacock wrote:So.... I got an odroid-c2

Excellent, if you can make some progress on this it will be great, this isn't a small task but it is achievable if you take it on in bite size pieces.

My first question for you is, do you want to start with getting the C2 working in 32bit mode or do you want to go full on with 64bit first up?

The starting point for bringing up any new board is to get it to boot an image created by FPC and do something really basic like blinking an LED just to prove the boot process actually works.

To do this you will need to know some basics about the way the U-Boot version supplied with the Odroid is set up, what does it expect the image file to be called, what address will it load the image at and what information will it pass to the image on boot. With that information in hand you can create a new BootODROIDC2.pas unit that kicks off the boot process, the BootRPi3.pas would make a reasonable template to refer to. The compiler will need some modification to tell it about the new board and any specifics like load address etc (we can supply info on what needs changing).

Beyond that the work differs depending on the choice to start with 32 or 64bit.

aaronpeacock wrote:1) PlatformARMv8.pas still needs work?

At present PlatformARMv8 is 32bit only so it would need expanding for 64bit, the preference would be for adding IFDEFs based on the CPU arch so it works for either.

aaronpeacock wrote:2) PlatformOdroidC2.pas would need to be created by cloning PlatformRPi2.pas and then digging into my odroid SOC datasheet etc, right?

Yep, this is where the datasheet becomes needed to know how to talk to the C2 and find the chip specific stuff. You would also need to create a AmlogicS905 unit (something like BCM2836) that defines all the peripherals and interrupts etc.

Drivers and things would all have to be worked out based on what the C2 contains, some things will likely be very similar even on a different chip.

aaronpeacock wrote:once I get it working, what's the preferred means of contributing?

Anything that suits you really, zip file, pull request on GitHub, difs etc.


This is just some starter info, I'm sure you'll have a bunch of questions but we can keep the conversation going as you think of things.
Ultibo.org | Make something amazing
https://ultibo.org

Return to “Feature requests”

Who is online

Users browsing this forum: No registered users and 1 guest