Pine64 / Pinebook

Hi all,

Has anyone had a try at running RISC OS on any of the Pine64 hardware? Specifically, the Pinebook (the $99 ARM laptop).

Was thinking that if they had, it’d be an ideal educational computer.

Thanks,

Ben

Not to my knowledge. It is theoretically possible though.
It uses the Allwinner H5, or A64. I forget which. Not a massive amount of difference. Those 64 bit variants also aren’t too different from the 32 bit Allwinner family.

Assuming I get further with my Allwinner H3 port, I planned on doing something to allow it, or a version of it to run on the 64 bit variants. In 32 bit mode of course.

I’d love to get a Pinebook too. It’d save me a lot of messing around with ssh, nfs, smb, rdp, and remote X applications. Unfortunately something like it falls into the lowest of low budget priority.

Anyway, I don’t think there’s anything inherently impossible about RO runnning on it. I can think of a few wrinkles though.

*WiFi. RO doesn’t have it (yet?). It’d need to be plugged into something.

*Boot. I don’t know if the Pinebook is wired to boot in 32 or 64 bit mode. It just involves different approaches to boot is all. I also have no idea how the Pinebook boots. NAND? SD? SPI flash?

*Display. Could be trouble. Between the Allwinner and iMx6 docs, there is a mostly complete picture of the graphics subsystem (except the PHY on some models, CODECs, and 3D (although that is changing recently)).

The Allwinner SoC family is pretty pervasive. Besides a few oddities they are really straightforward.

The strangest things I can think of are:

*Boot. Their built in ROM uses an odd method to load bootloaders, leading to the need for a multistage boot.
*Graphics. I touched on it above. They did something really weird.
*OpenRISC core for power / system control? Best to pretend it’s not there. Just access the necessary registers directly.

Has there been any updates to this:-

https://forum.pine64.org/showthread.php?tid=6058

I paid for a Pinebook recently… And paid again. A bit cranky about that. I’ve paid about the same in postage as for the Pinebook.

Access to anything which I can work on the code with for the H3 has been patchy at best. I’ve been trying to work out how the RISC OS driver modules work. Templates / “null” drivers would really, really go a long way.
I’ve also been reading about aarch64 which has surprisingly spotty available documentation given the age.

Really from what I can see the most of what should be necessary is to change the necessary exception levels to aarch32 and set up the handlers. The versions based on the 64 bit allwinners would either need their own build with some subtle differences, or a 32 bit U-Boot.
It is my understanding that the SoCs are set up to boot in aarch32, but it gets switched to 64 bit for U-Boot.
I’ve only seen vague references to an aarch32 U-Boot for older legacy kernels but have never found anything concrete.

Oh, looks like I said a lot up above. Anyway my plan is to get a Pinebook because of limited time available working at my desk with an actual RISC OS machine. I know the Linux port runs well on the Pinebook hardware because I run it on my Orange Pi PC2. Some recent experimenting showed that I can do almost everything I need via the OPiPC, so the same should hold for the Pinebook.

After I get enough operational on the H3, I will see if I can get the H5 happening too. Added bonus being that with the Pinebook I would just be able to reboot, intercept U-Boot and load the uImage straight from storage.

Right now I’m struggling with driver modules. Or rather trying to understand how the RO portion of them works. A portion of the iMx6 driver should do the job for either, I think. What I would love is an “empty” GraphicsV driver. I’m about 95% sure the H3 port is running the desktop successfully. I just can’t see it.

I’ve also been reading about aarch64 which has surprisingly spotty available documentation given the age.

I think the main problem there is that the main technical docs are hidden behind ARM’s registration system.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487c.a/index.html

And then once you’ve got the docs, you’ve got to try and find the information you need in amongst the 5000+ pages.

It is my understanding that the SoCs are set up to boot in aarch32, but it gets switched to 64 bit for U-Boot.

Which is impossible, unless they’ve added their own extensions to the CPU. The execution state of the highest exception level in the system (EL3 for Cortex-A53) is determined at CPU reset/init and can’t be changed. If the CPU is currently in a 64bit state then it can decide whether the lower exception levels are 32bit or 64bit. And if an exception level is configured to be 32bit then all of the lower exception levels are automatically also 32bit. So the only way for a CPU running in 32bit mode to switch over to 64bit mode is for it to cause an exception to a higher level (e.g. SWI/HVC/SMC instruction), and for that higher level to be running in 64bit mode.

So I think the options are either:

1. The CPU is hardwired to boot in 64bit EL3 (secure monitor), and the boot ROM examines the U-boot/bootloader binary to work out whether to enter it in 32/64 bit EL1/EL2 (and potentially provides SMC calls to allow U-boot to gain full control over the system)
2. Reset circuitry external to the CPU decides on the boot mode (e.g. on the Pi, the GPU is responsible for powering up the ARM, and is able to select between several different boot modes based around the contents of config.txt)

What I would love is an “empty” GraphicsV driver

http://www.phlamethrower.co.uk/misc2/novideo.zip

There are some (brief) TODOs which indicate where code needs inserting in order to make the driver work (e.g. several GraphicsV entry points which need implementing). It’s just a stripped down version of OMAPVideo, so compare against that if you want to see how things “should” be done. Just remember that all drivers are different, so the implementation choices / implementation details of OMAPVideo may not make sense / be sensible for your hardware. E.g. the current version of OMAPVideo uses a number of different locking schemes to try and make sure concurrent access to data / state is done in a safe manner, and the configuration of those locks is based entirely on where and how each variable is being accessed.

Which is impossible

http://linux-sunxi.org/Arm64#Boot_modes

I couldn’t remember what point it did it. Apparently FEL mode. So it’s not baked in, so to speak.
It could boot 32 bit OSes, and I believe the code exists somewhere. I just don’t know where.

I could have worked on booting RO from FEL, but it seems like a lot of wasted effort and loss of versatility.

Another option I’ve considered is to have a small gap at the beginning of the image with a branch over it. I noticed ObjAsm supports insertion of binary “blobs”. So either doing that or patching in a little code to change back to aarch32, then wrapping the image in the correct container of course, could be a way.

I think the main problem there is that the main technical docs are hidden behind ARM’s registration system.

I have some ARM registration. Not sure if it allows me access. But it’s still absolutely brutal. I’ve found some tutorials etc. to get started online but they are a little brief. What I would love to know is about changine exception levels. I’ve only found one tutorial source code that touches it with an example. I’d rather a proper explanation of the process.

I’ll have a look at the source shortly. From what you say it’s what I need. It’s a pain trying to work backward to find what’s implementation specific and what’s more OS interface specific.

It should go in my thread but I had a mental block clear on a hardware interface in the H3 that has been stopping me for many months. I’m writing a usermode test program and “library” on the PC using Code::blocks configured for GCCSDK to work on it. I knew there was a way to neatly handle the PIO ports but every time I tried it was wrong even though I knew what I had to do. It finally clicked out of nowhere so I got coding. It was just some silly mistakes getting some bit shifting and masking mixed up.

Which is impossible

http://linux-sunxi.org/Arm64#Boot_modes

Ah, I hadn’t heard of the RMR & RVBAR registers – thanks.

Another option I’ve considered is to have a small gap at the beginning of the image with a branch over it. I noticed ObjAsm supports insertion of binary “blobs”. So either doing that or patching in a little code to change back to aarch32, then wrapping the image in the correct container of course, could be a way.

I’m not familiar with the ARM trusted firmware, but it sounds like it’ll boot the OS in EL2. So if that’s going to be AArch64 EL2, it should only require a small stub to disable the hypervisor functionality (e.g. disable HVC instruction and allow EL1 to service interrupts directly), and to drop into AArch32 EL1 for booting RISC OS.

https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-design.rst#id38

I have some ARM registration. Not sure if it allows me access.

“Non-confidential restricted access”; I think that means anyone who’s registered can download it.

What I would love to know is about changine exception levels. I’ve only found one tutorial source code that touches it with an example. I’d rather a proper explanation of the process.

The information is scattered around in the “AArch64 System Level Programmers’ Model” section of the ARMv8 ARM – so you’ll have to search through that a bit to find the exact information you’re after. E.g. chapter D1.16 covers the different instructions that can be used to programmatically call into a higher EL. Chapter D1.13 discusses where those instructions take you (since the hypervisor and secure monitor functionality mean there’s a lot of flexibility). Chapters D1.10 and D1.11 cover what happens when the target state is entered, and how to get out of it. Chapter D1.20 covers mixing AArch64 & AArch32. Etc.

And then there’s the “AArch32 System Level Programmers’ Model” section which discusses behaviour for exceptions handled by AArch32.

Hi Tristan. I don’t have your email address, but if you could get in touch with me at the usual rcomp at rcomp email address, it’d be really appreciated.

Would love to run RiscOS on something like the RockPro64 and the Pinebook Pro machines. Especially because of the ability to move the OS to emmc storage and Pine64 doesn’t charge that much for some of their larger storage sizes.

Would love to run RiscOS on something like the RockPro64 and the Pinebook Pro machines

Talk nicely to R-Comp – they already did the Pinebook. Whether the Pro is viable would depend on the CPU and general hardware.

I bought an ArmBook from RComp in March. It is lovely. Run it as a Pinebook (not Pro – under the screen it still says Pinebook ) and it is a Linux laptop (Manjaro-ARM). Stick the RISC OS micro-SD card in the slot and it runs RISC OS 5.26. I use it with a wireless mouse from the late Maplin company.
It can be used all day on its battery. I would say that it is not quite as fast as an Rpi 4. Listening to music (YouTube < FireFox < Manjaro < PineBook) I get an occasional crackle on tracks where (YouTube < Chrome < Raspbian < Rpi4) plays smooth but it is nevertheless satisfying to use, and it is portable. RComp have done a good job. When it first arrived it came with an out of date version of Manjaro, that could not be updated because the Manjaro team had changed the repository naming protocols. Andrew Rawnsley replaced it with the current Manjaro. It is everything I have long wanted in a RISC OS portable.

I have a ArmBook / Pinebook from RComp. It isn’t the fastest RISC OS machine out there and for me two things it lacks in RISC OS is monitor support and wifi. Yes there are “work arounds” for the lack of wifi but they’re just that. It would be nice to be able to plug a monitor into it when using it at a desk. There is a mini-HDMI socket, but I think no RISC OS driver (yet).

Where it really excels though is it’s small and portable (with good battery life). It’s small enough you can take it just about anywhere. I’ve used it on trains and planes, and often take it with me if I’m going somewhere. I had to do a number of 7hr+ trips earlier in the year and I did a lot of work on Python sat on a cross-country train, without even needing to bother about finding a seat with a socket.

Bottom line is it means I use RISC OS a lot more than I would if I had a ‘desktop’ system.

@Chris Johns
Can I quote you and your RISC OS experience for our Cloverleaf RISC OS project? It is very helpful to let NON-RISC OS user know about real life experience with RISC OS.

I like my ARMBook too, but the pad could be much better with a few modifications in the driver.

How do you manage Select/Menu/Adjust?

What’s the sound output like?

What’s the sound output like?

If it’s based on the Pinebook, reviews of it’s audio capabilities (in terms of speakers) was poor. Thank goodness for a headphone jack though.

How do you manage Select/Menu/Adjust?

This part is simple (mapped to other keys).
But – IMNSHO – there are many issues with the pad driver.

Are there any switches in the touch pad?

Two. But really, the problem is not here.

@Stefan
feel free to quote me. I have found it’s (re)opened RISC OS for me.

The sound is “passable” on the internal speakers, I’m not sure I’ve tried it with headphones… I should do that :)

I tend to carry around a small cordless mouse, although the touchpad works okay for me.

@Stefan Hopefully Cloverleaf will consider the PineBook Pro as a target for a RISC OS port. It is a very capable laptop, Rockchip RK3399cpu, 4GB LPDDR ram, up to 128 GB eMMC, NVMe capabilities, with usb2, 3 and C oports. The slim case is made from Magnesium alloy sheel. There will always be niggles with touch pads and speakers but, for the price point, the PineBook and Pro laptops represent outstanding value for money.

Has anyone gotten the RiscOS image listed on the Pinebook software releases page to work on a Pinebook 11 (non-Pro, with the 1920×1080 panel)?

I’ve tried running it from an SD card, and whilst it appears to boot – once it gets past u-boot, the display appears “corrupted” – you can see various pixels moving in a pattern that move in relation to the mouse pointer, and you can make out areas of the screen that look like they could be a dialog box, and the deskbar. My suspicion is that it’s expecting a 1366×768 screen, and assumes the framebuffer is already at this resolution – and that I’m seeing rows of 1366 pixels stacked side by side, wrapping at the 1920 pixel screen width.

I’m a relative newcomer to RiscOS (having last played with it on a A3000 may years ago) – any thoughts on how I can get this one working?

Has anyone gotten the RiscOS image listed on the Pinebook software releases page to work on a Pinebook 11

That’s the RISC OS image for the old 14" PineBook, which as you say had a 1366×768 display.

RComp’s build for the 11" PineBook does still have a 1366×768 display option, which produces a “sheared” display as you describe.

Thanks for confirming my theory.

I’ve managed to make a little headway, and gotten the display working (although, I suspect only for this session). After searching the card image for “1366” I found a couple of files referring to screen resolutions (one looked to be a script, and a couple of monitor definitions) – both including 1366×768 and 1920×1080.

After discovering the F12 command line, and spending a lot of time unsuccessfully trying various ‘wimpmode’ commands, I found that the magic incantation was:

LoadModeFile Resources:Resources.IMXVideo.PineMon
WimpMode X1920 Y1080 C16M ltrgb

Now I just need to work out how to make the change permanent.

Now I just need to work out how to make the change permanent.

Well, while you’re experimenting, making that specific Obey file – !boot.choices.boot.predesk.configure.monitor – a read only file should hold the settings. :)