Thank you for quick (but less adequate) reply.
The Pinephone is developed directly on top of Pine64 Sopine A64 SOM. (Openwrt 19.07.7 Supported device no 696 ) As hopefully shown below:
The problem starts with drivers for touchscreen, gyro, modem, etc.
But by far the biggest one will be the userland side, OpenWrt doesn't really contain any GUI or other means to operate a phone in any meaningful way.
--
Yes, you can use OpenWrt as a media player, but that's pretty much single-purpose/ single-app on the screen. A phone is quite different from that.
1 Like
I understand that Openwrt is meant as a standalone box in general just like many other firewalk and router solutions.
Of course the things you mention above (modem touch gui etc complicates a lot.)
OTOH Linux is Linux.
Where can I read up specifically how Openwrt is put together in regards to the kernel network layers as well as modem , usb, bluetooth and wifi hardware? Does everything re Openwrt happen in kernel space? or are there user space tools as well?
A bit of both, actually - depending on what in particular you're looking at.
Conceptually, OpenWrt is quite a bit more like any other (but very limited) desktop linux distribution than android would be. Yes, it's not using glibc (musl instead, while android would use bionic), the userland is mostly made out of busybox and small dæmons (procd as initsystem), relying heavily on netifd to deal with the networking and hostapd/ wpa_supplicant for the wireless side. Should be rather straight forward to get familiar with, just not the best environment for a phone (but neither would be a general purpose/ desktop/ server oriented linux distribution).
Postmarket OS ( Alpine Linux Arm64 ) is also an old Router based on busybox (dash) that grew into something bigger and now runs on many older smartphones including mine ( That is new however)
The Pinephone started out specifically as a Linux phone for tinkerers. For me it us interesting to see wether it is possible to make a smartphone just as safe and viable to use as your everyday (Linux ) desktop box or even better. I think I would put everything with exception for the actual firewall environment ( with complete hardware drivers and simplest possible user interface ) into a sandbox container. I'm also considering customizing the hardware on the existing Pinephone platform.
What it was is one thing, what it is another.
Looking at https://wiki.postmarketos.org/wiki/Devices, I do not see a single non-phone'ish device, nothing remotely like a router - and most importantly, nothing which comes (remotely-) close to the system specifications that are still prevalent in the router market. Taking one of the oldest supported PostmarketOS devices as example, the Nokia N900, we're talking about 32 GB storage and 256 MB RAM, for which they offer a ~150 MB image. Many OpenWrt devices still come with 8 MB flash and 64-128 MB RAM, with OpenWrt 21.02 weighing just over 5 MB (ath79).
None of the most prevalent targets supported by OpenWrt even have any kind of display, keyboard, mouse or touchscreen - accordingly OpenWrt doesn't offer much in that direction. An excemption from that are the RPi- and sunxi SBCs, which (with OpenWrt) are predominantly still used as a routing appliance or other built-for-purpose devices (there are some media players based on OpenWrt). Can you add the missing parts, yes - but at a huge price (in terms of development efforts and getting them merged and kept maintained in an ecosystem where basically no one cares about these packages).
Edit:
Just to put some perspective into it, looking a bit into (recent) history.
The Netgear r7800/ ZyXEL NBG6817 (published to the market around mid- to late 2015) is still a rather highend 802.11ac router (these are still among the very best you can run OpenWrt on right now). It is based on the QCA ipq8065 SOC with 2*1.7 GHz ARMv7 cores and 512 MB RAM, which in term is derived from the KRAIT300 SOC (~cortex A15); it's supported by OpenWrt since summer 2016. The Qualcomm Snapdragon 600/ APQ8064T is a very close relative to it, published to the smartphone market in early 2013, albeit shipping with 4 cores instead of 'just' 2 - just like the Samsung Galaxy S4/ i9505. So not too far away from your PostmarketOS specifications, at a first glance.
But if you look into the specs closer:
- ipq8065, 2*1.7 GHz KRAIT300
- 128 MB NAND flash, about 100 MB usable (r7800) or 4 GB eMMC with about 68 MB usable (nbg6817)
- 512 MB RAM
- 4+1 1000BASE-T ethernet ports
- 2* USB3
- 1 SATA ports (r7800 only)
- 2*QCA9984 4x4 802.11ac/ wave2 wireless
Flash, not enough (depending on the devices 32-90 MB, kernel size limited to 2-6 MB) for a GUI - not even a (reasonable) way to attach a display. This still is a highend device, would you really expect the project at large to spend a lot of efforts on porting X.org/ wayland to this. to package up (and continue maintaining) gtk3, qt5 and your windowmanager of choice?
Now let's look at really modern highend (things like the Xiaomi AX9000) routers which are being worked on (but which aren't even fully supported yet; the first devices with the SOC entered the market in mid 2019, in rather scarce quantities and for big prices):
- ipq8072a, 4*2.2 GHz cortex a53
- 256 MB NAND, of which around 80 MB may be usable
- 1 GB RAM (a considerable chunk of that memory is reserved for the hardware, by the NSS firmware, the wireless drivers, etc. you may get just over half of that for your own disposal).
- 1* USB3 port
- 1* 2.5GBASE-T
- 4* 1000BASE-T
- 3* 4x4 802.11ax wireless
- 1* 1x1 802.11ac 'IoT' wireless
Is there any (reasonable) chance to attach a display, a touchscreen, a soundcard or a keyboard/ mouse to this? Just because it could be done, doesn't mean the project will suddenly switch targets and look into supporting a phone needing exactly that.
Btw., at the same time OpenWrt needs to continue working on ath79 (single core, 400-750 MHz mips74Kc) and mt7621a (dual-core, 880 MHz mips1004Kc) based devices, with flash sizes predominantly between 8 and 16 MB and most commonly 128 MB RAM for the contemporary devices (still selling today), because that's what the majority of users has on their desks and in active usage today. The oldest still somewhat working (bcm47xx based-) devices even come with 166-300 MHz single-core mips32 SOCs and 4 MB flash/ 32 MB RAM. That's where OpenWrt is coming from - and where it needs to remain (to some extent), unless it would want to abandon its target demographic.
2 Likes
First: I never implied that Openwrt should take the direction of Alpine Linux / Postmarket OS. (Its not my choice of OS anyway)
Secondly I asked for where to find information about basic Openwrt intrinsics, while presenting the Ideas I am working with. I want to see if Openwrt is useful to me in the specific context of trying to make my Tinkerphone safer for use. The drivers that you mention above are already developed, and installed in the Phone OS images
These drivers may or may not conflict with the specifics of the Openwrt kernel.
Lastly: I have no other opinion on what Openwrt would or could or should be. I found Openwrt recommended while looking for a Linux firewalling solution on my new Tinker project.
the OpenWrt documentation for developers is here but may or may not be good enough https://openwrt.org/docs/guide-developer/start
so you might want to come back and ask questions in this section of the forum (or the mailing list)
I find very strange that someone would want to run a firewall distro on a smartphone. Why did you buy a smartphone if all you needed was a battery powered router? GL.inet makes a couple of those that are supported in OpenWrt (and use the same or nearly the same modem) and it would have been much cheaper and simple.
Are you sure that running OpenWrt is what you actually wanted?
Afaik while you might be able to port over the drivers to operate the screen and internal devices, OpenWrt has no packages for GUI at all, the interface is web-based and is called Luci, you will be left looking at a console interface with no on-screen keyboard.
I mean nobody will stop you from adding packages to support a GUI but it is becoming a very big task for a lone person
1 Like
First:
Didnt I make it clear in my previous post that I am interested in trying to implement an external security layer on this the one most vulnerable and hacked platforms of our times?
I fail to understand why this would sound strange to a normal thinking and feeling individual.
Second:
According to what I already wrote above, I do not want to implement any gui or mouse driver to Openwrt.
Please read my input before answering.
Please try not to blur my topic!
You are writing conflicting information, this is your own problem.
I can't help if you don't explain better what you want to do, which is why I asked for more info
From what you said before my post you want to use OpenWrt as the main firmware for that device. That is not a phone anymore but a battery powered wireless 4G modem with a large screen showing a console.
Which is imho nonsense, but I posted a link to developer documentation you can use for that.
If the goal as you said in the last post is a more generic ""trying to implement an external security layer on this the one most vulnerable and hacked platforms of our times"
For that, I think you just want to run OpenWrt as a "firewall application" inside an actual phone OS, not fully replace the firmware with OpenWrt.
For that, you should be looking into virtualizing OpenWrt inside the phone (OpenWrt can be virtualized in most known hypervisors and your phone can run KVM/QEMU https://openwrt.org/docs/guide-user/virtualization/qemu?s[]=kvm&s[]=guest and also run as a docker container, see here Running OpenWrt in a Docker container ) and redirecting all network traffic to the VM/container so it can act as router/firewall.
If you run it like that you can operate it from a browser inside the phone OS, and you don't need to port any driver since you are just passing through network interfaces.
I am considering some kind of virtualization , but A Firewall IMHO is most secure if it resides on top of the operating system instead of in a docker image. I would rather have all the other features in the phone virtualized in this way.
You are not wrong, but I think you are asking too much for what the "state of the art" is at the moment, and I'm not talking of just OpenWrt or even Linux but virtualization in general.
You are probably looking to make something like Qubes OS but for a phone. https://wwwpreview.qubes-os.org/
Apart from the fact that Qubes OS is developed only for PC architectures so it won't run without some serious development, there are limitations, that for an embedded device like a phone are much worse than for a PC.
All the software in the VMs has no access to hardware acceleration (GPU and video decoding), which is very bad for a mobile device that is running on battery and does not have a lot of CPU power to begin with.
That's because passing through stuff to the VM running the "phone OS" is a challenge, especially the GPU/display, but also other peripherals like sensors and whatnot, since not even PC hardware supports being virtualized and split over to multiple different VMs like this.
Only CPUs can be freely shared between any number of VMs, (and some server network cards, and a couple models of ridicolously expensive businnes GPUs also for servers) all other hardware cannot and expects to be used by a single OS at a time.
That said, OpenWrt can be a virtualization host too (KVM/QEMU) https://openwrt.org/docs/guide-user/virtualization/qemu_host
I am hoping to find another way to containerize and possibly assign cpu cores and memory ranges to specific implementations that I need to operate my phone. If bios hardware test programs can do it, then there must be solutions ready out there.
I already looked at the qubes os model, but it has a somewhat different (and veey ambitious approach, and looks to provide solutions for problems that I wont bother to address.
With containers (both Docker or LXC) you can assign a RAM amount and pin it to a specific CPU core (and network resources and a lot of other metrics), and the processes are isolated from each other by the kernel.
Assigning a memory range is not possible but it does not change much since even if you could, this isolation would still be enforced by the same kernel that is already enforcing isolation between different processes (and containers) anyway.
A "bios hardware test program" (I think of Memtest or the Dell integrated diagnostics for their boards and laptops) is a single blob running bare metal. It has access to everything, there is no security nor need for security since that's the only software running.
Which is one of the reasons why it can access raw memory addresses and hardware registers to run tests. Programs running on any modern OS (Linux or Windows) can't just address memory (and hardware registers) directly, only the kernel can do that.
I'm not sure that OpenWrt is a proper solution for your purpose, but anyway I'm interested in adding support for PinePhone, maybe I can work on it in this month or after half a year, I don't know for now. I've been thinking about it since I bought it a year ago, but I couldn't find enough time for it. 
As you mentioned, the hardware is quite similar to PINE-A64 which is already supported, so I don't think the porting would be too hard. I'm still concerned that RTL8723CS is not supported by mainline kernel so we'll have to import the driver from pmOS or somewhere.
Of course, OpenWrt would not provide any gui applications, but it still can provide LTE backhaul, WiFi AP, ethernet via USB and more. I've once tried booting ALARM on PinePhone and it only showed a black terminal screen, I expect the same from OpenWrt.
I personally think you should either spend your time on porting a different device or to port a different operating system on the Pine Phone.
Going through all this effort to port an operating system that has no GUI on a smartphone seems a so big waste.
1 Like
Well, actually that's what I'm good at. Wasting time. 
While at it, I had to update sunxi U-Boot and kernel to the latest version as the current version does not support PinePhone yet.
And these are the first screenshots (from UART):
Currently the screen doesn't even show a tty and there's no network interface yet. I'll start turning on drivers one by one.
2 Likes
Very interesting project!
You probably need all the display, panel, touch, drm, gpu, ... drivers for video output and touchscreen to work. Then you can setup a container holding the UI and give it routed network access using a veth pair as well as to access /dev/drm/*, /dev/input/*, ... and the show can begin.
Coincidentally I've just tried making input and video devices accessible to containers when using the OpenWrt-integrated procd-ujail/uxc container run-time (on BananaPi BPi-R2, ie. MediaTek MT7623 with integrated Mali-400 GPU and MIPI-DSI as well as HDMI interfaces), so let me know if you need any support with that, I can probably help.
To make sure graphics drivers are working fine, you can try kmscube which is available in a fun PR I've posted the other day: https://github.com/openwrt/packages/pull/16436
Sorry to say. My time for this is very limited. Thank you for thinking about securing smart portable devices. It is important to have a working banking system also on a digital planet.
Yeah, I was also thinking I should look into your mt7623 patch. I'm not really familiar with the display stuff, so any kind of help would be highly appreciated. 
Sadly my busy period has started, so I would not make any meaningful progress for a while...
Wow that's cool! I've never thought the video feed could be ever resurrected. I'll definitely have a try, thanks!