On Tue, Dec 03, 2013 at 12:09:00PM +1100, Petros wrote:
I am reading through some stuff related to the Firefox OS phone.. it looks as the "hardware BLOBs" are described and sitting in the firmware so can included in a new kernel you are building?
"firmware" in phone-speak is usually the same as "rom" which is basically the entire OS. you can replace the whole firmware using no blobs but then you may have usb and, if you are lucky, wifi working but likely nothing else (eg. no graphics, phone, video, ...). 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. eg. for another ZTE phone (yours will be a bit different but likely not too much), the list of userland "blobs" is below. it's all the "ril" bits that talk to the radio, all the "Omx" bits that do video encoding/decoding, the camera, all of the adreno200 GPU, some bluetooth, hw sensors, wifi/bt bringup, maybe "libloc" is gps, etc. % ls -R vendor/zte/v9/proprietary/* vendor/zte/v9/proprietary/bin: abtfilt akmd2 hci_qcomm_init hostapd qmuxd vendor/zte/v9/proprietary/etc: firmware/ init.qcom.bt.sh* ti_gauge.bqfs ti_gauge.dffs vendor/zte/v9/proprietary/etc/firmware: yamato_pfp.fw yamato_pm4.fw vendor/zte/v9/proprietary/lib: egl/ libmmparser_divxdrmlib.so libOmxMp3Dec.so libauth.so libmmparser.so libOmxMpeg4Dec.so libC2D2.so libnv.so libOmxOn2Dec.so libcm.so liboemcamera.so libOmxQcelp13Enc.so libcommondefs.so libomx_aacdec_sharedlibrary.so libOmxQcelpDec.so libdiag.so libOmxAacDec.so libomx_sharedlibrary.so libdivxdrmdecrypt.so libOmxAacEnc.so libOmxVidEnc.so libdll.so libOmxAdpcmDec.so libOmxWmaDec.so libdsm.so libomx_amrdec_sharedlibrary.so libOmxWmvDec.so libdss.so libOmxAmrDec.so liboncrpc.so libgsdi_exp.so libomx_amrenc_sharedlibrary.so libOpenVG.so libgsl.so libOmxAmrEnc.so libpbmlib.so libgstk_exp.so libOmxAmrRtpDec.so libqmi.so libloc-rpc.so libOmxAmrwbDec.so libqueue.so libloc.so libomx_avcdec_sharedlibrary.so libril-qc-1.so libmm-adspsvc.so libOmxEvrcDec.so libril-qcril-hook-oem.so libmmgsdilib.so libOmxEvrcEnc.so libsc-a2xx.so libmmipl.so libOmxH264Dec.so libwms.so libmmjpeg.so libomx_m4vdec_sharedlibrary.so libwmsts.so libmmosal.so libomx_mp3dec_sharedlibrary.so vendor/zte/v9/proprietary/lib/egl: eglsubAndroid.so libGLES_android.so libGLESv2_adreno200.so libEGL_adreno200.so libGLESv1_CM_adreno200.so libq3dtools_adreno200.so typically when you build a new rom you just include all of these. obviously all the kernel ABIs and other library ABIs that all those libraries use has to be present for them to run too. also you often have binary kernel modules as well (eg. for wifi, bluetooth) which force your kernel to be a specific version and major features (eg. PREEMPT on/off), although there's nothing to stop you backporting lots of newer kernel features to an old kernel. eg. I trivially backported the uhid driver to old kernels so that bluetooth keyboards (and other hid devices) work with newer android. I also backported smarter android lowmemorykiller kernel code. 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. so maybe we should back up here and ask what is it that you actually want to do with this phone? if you just want to add eg. sshd to it, then that's pretty easy, as would be compiling android-arm binaries to run on it. if you want to update the kernel then it depends how many binary kernel modules you have as to which features you'll lose, also you will have to use android patches to the kernel to keep the userland blobs happy. if you want to run a generic linux userland on it then that would probably work, but without access to phone, graphics, maybe bluetooth, wifi, dunno about sound, touchscreen, buttons, ... if you want to stick with FirefoxOS and just keep updating and tweaking and improving it then that would be easy (unless (quite likely) they rebase on a newer android version which you don't have blobs for) as they have provided a build system for you to use. so it kinda depends what you want to do as to how hard it'd be... cheers, robin