Pine64 / Pinebook
Ben Collier (4915) 2 posts |
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 |
Tristan M. (2946) 1039 posts |
Not to my knowledge. It is theoretically possible though. 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. |
Colin Ferris (399) 1819 posts |
Has there been any updates to this:- |
Tristan M. (2946) 1039 posts |
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. 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. 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. |
Jeffrey Lee (213) 6048 posts |
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.
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:
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. |
Tristan M. (2946) 1039 posts |
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. 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 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. |
Jeffrey Lee (213) 6048 posts |
Which is impossible Ah, I hadn’t heard of the RMR & RVBAR registers – thanks.
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
“Non-confidential restricted access”; I think that means anyone who’s registered can download it.
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. |
Andrew Rawnsley (492) 1445 posts |
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. |
Braillynn (8510) 51 posts |
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. |
Steve Pampling (1551) 8188 posts |
Talk nicely to R-Comp – they already did the Pinebook. Whether the Pro is viable would depend on the CPU and general hardware. |
GavinWraith (26) 1563 posts |
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. |
Chris Johns (8262) 242 posts |
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. |
Stefan Fröhling (7826) 167 posts |
@Chris Johns |
David Feugey (2125) 2709 posts |
I like my ARMBook too, but the pad could be much better with a few modifications in the driver. |
Colin Ferris (399) 1819 posts |
How do you manage Select/Menu/Adjust? What’s the sound output like? |
Braillynn (8510) 51 posts |
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. |
David Feugey (2125) 2709 posts |
This part is simple (mapped to other keys). |
Colin Ferris (399) 1819 posts |
Are there any switches in the touch pad? |
David Feugey (2125) 2709 posts |
Two. But really, the problem is not here. |
Chris Johns (8262) 242 posts |
@Stefan 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. |
Norman Lawrence (3005) 172 posts |
@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. |
Jason (8591) 6 posts |
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? |
Stuart Painting (5389) 717 posts |
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. |
Jason (8591) 6 posts |
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 Now I just need to work out how to make the change permanent. |
Steve Pampling (1551) 8188 posts |
Well, while you’re experimenting, making that specific Obey file – !boot.choices.boot.predesk.configure.monitor – a read only file should hold the settings. :) |