Re: Ramble about embedded ARM boards (was: Firefox OS and ZTE phone)
Quoting "Robin Humble" <rjh+luv@cita.utoronto.ca>
so maybe we should back up here and ask what is it that you actually want to do with this phone?
Well, let me start with David Bowie who has the best catch phrases for everything: "I demand a better future": http://www.youtube.com/watch?v=eoWJm5pzcMQ Well, it's for playing. For "normal use" it is already useless out of the box: It even completely logs out from the phone network after a while so I am not reachable (to be honest I did not expect it to be _that_ useless) I don't like the idea of having a device which I don't control and it is closed source (even if it is Android, an "open source operating system"). Well, that's as it is now but to be able to understand how it works, and then think about ways to tweak it for me. Thanks for your mail, it helps me a lot.
Note that the vast majority of the android blobs are userland binary blobs - not kernel - the device specific kernel is released as (usually shitty) source because of GPL compliance. vendors typically modify a standard android kernel enough to support the hardware, and then put all the real smarts in userspace with the kernel layer being minimal.
Okay, the kernel only sends "0x03 875" to the radio receiver and only closed source libradio.so knows what it means (having a function "switchStation(frequency)" in it)?
nothing is impossible, and with enough glue code and compat layers and forward and backward porting those blobs could continue to be ok for a long time, but it might easily be 1000's of lines of (usually android framework) code, and a lot of understanding of what is changing and why.
indeed, the above blobs are (I think) from Gingerbread (Android 2.3) which was the last drop that the vendor did for the phone, and yet the roms I currently build are JB (4.3) because many people have written enough compat code to workaround all the API/ABI changes in android over time and keep the blobs happy.
Does it mean there is a stable ABIs to hook the drivers into a Android kernel? How stable is this? E.g. all from Android 4.0 to 4.1 to .. 4.4? Linux 3.8 to 3.10 to..?
rom variants generally coalesce around specific blob drops from the vendor that often match android drops.
as long as userland sees exactly the same data from the kernel and the binary kernel modules still (ie. same kernel version) load then you can backport as many features to a kernel as you want. if you are lucky enough to have no binary kernel modules then you can probably use a much newer android kernel as long as it has android specific features that match the blobs. ie. there might not be much of a win.
In a newer FreeBSD version you can include a COMPAT_x option, e.g: options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options COMPAT_FREEBSD6 options COMPAT_FREEBSD7 so I can build a FreeBSD 9 kernel which is compatible with binaries written for FreeBSD 4 (which had EoL 2007) The ABI is usually stable over a major release so it does not matter which FreeBSD 9.x it is. I frequently have "minor mismatch" because I run newer jails on a kernel I did not update for a while. You have written something similar as I understand, so you have ZTE BLOBs from Android 2.3 still working. But is a bit more about the spots _you_ need so it may not work for all Android 2.3 BLOBs? I wonder sometimes how much of "smarts" are in the BLOBs which are worth to be hidden or could be easily open sourced without any commercial damage for the manufacturer, e.g. ZTE. Thanks for ideas Peter
On Wed, Dec 04, 2013 at 11:29:40AM +1100, Petros wrote:
Quoting "Robin Humble" <rjh+luv@cita.utoronto.ca>
so maybe we should back up here and ask what is it that you actually want to do with this phone? Well, let me start with David Bowie who has the best catch phrases for everything: "I demand a better future": http://www.youtube.com/watch?v=eoWJm5pzcMQ
Well, it's for playing. For "normal use" it is already useless out of the box: It even completely logs out from the phone network after a while so I am not reachable (to be honest I did not expect it to be _that_ useless)
if you get adb working over USB (you will need it to get anything done on the phone) then try 'netcfg' and 'cat /proc/net/route'. the firefoxos I built for my phone had most stuff working including wifi, phone, sms, but mobile data didn't work 'cos a default route wasn't set (I never got around to trying to fix it). doesn't sound like you have been quite so lucky though :-/ can you try a optus or vodaphone sim in the phone instead? it might be worth building a newer firefoxos for it too. might already be fixed...
I don't like the idea of having a device which I don't control and it is closed source (even if it is Android, an "open source operating system"). Well, that's as it is now but to be able to understand how it works, and then think about ways to tweak it for me.
exactly. which is why I started learning about android and building my own roms. it's just scary the way people download and run phone roms from random forum people... (err, although I can give you the modaco link for my roms if you like :-)
Note that the vast majority of the android blobs are userland binary blobs - not kernel - the device specific kernel is released as (usually shitty) source because of GPL compliance. vendors typically modify a standard android kernel enough to support the hardware, and then put all the real smarts in userspace with the kernel layer being minimal.
Okay, the kernel only sends "0x03 875" to the radio receiver and only closed source libradio.so knows what it means (having a function "switchStation(frequency)" in it)?
sorry, by 'radio' and RIL (radio interface layer) I mean the 'phone' functionality. ie. GSM/CDMA/2g/3g/whatever. there is indeed a FM radio in some phones too, but that's separate. there's also the wifi and bluetooth 'radios' but they're separate too. Re: talking to the RIL - I haven't looked at how it works at a low level much. android or firefoxos talk to the 'rild' daemon which uses the libril* libraries which (I'm guessing) in turn probably talk via some simple /dev/modem-like interface with AT commands to the baby OS that runs on the (closed source) GSM chip. I don't know exactly where the kernel comes into that, if it comes into it at all... there are a bunch of character devices in /dev owned by 'radio' so I guess that's most of it.
In a newer FreeBSD version you can include a COMPAT_x option, e.g:
options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options COMPAT_FREEBSD6 options COMPAT_FREEBSD7
so I can build a FreeBSD 9 kernel which is compatible with binaries written for FreeBSD 4 (which had EoL 2007)
wow. seems like freebsd changes API/ABIs a lot - fair enough if you control the userland too I guess. linux can't get away with that sort of thing - it's much more backward compatible - I'd hope a current git kernel would work fine with a rhel5 (2007) userland. I'm not sure where google lies in the spectrum. my feeling is that they're good about API versioning within one approach but also not afraid to replace with something better and remove after a year or so.
You have written something similar as I understand, so you have ZTE BLOBs from Android 2.3 still working. But is a bit more about the spots _you_ need so it may not work for all Android 2.3 BLOBs?
each device has different blobs released at a different time - whenever the manufacturer decided to compile and ship them. having said that a lot of phones use the same SoC (eg. exynos*, qualcomm msm*, omap*, ...) so some parts of the userland blobs likely work on a few phones with the same SoC.
I wonder sometimes how much of "smarts" are in the BLOBs which are worth to be hidden or could be easily open sourced without any commercial damage for the manufacturer, e.g. ZTE.
no idea. some of the media and gpu stuff would be licensed. the FOSS community is making some headway though. lima and freedreno folks are making great progress with reverse engineeering the gpus. also it might now be possibly to replace some of the old wifi binary kernel modules with open source versions, etc. for allwinner arm chips (in tablets and small computers) I think everything is now open and close to being mainlined except for the mali gpu (lima will fix that one day) and the media accelerator (cedarx) which folks are working on reverse engineering. cheers, robin
participants (2)
-
Petros -
Robin Humble