Feature #1882

Replicant based on mainline Linux for Midas boards

Added by Joonas Kylmälä 6 months ago. Updated 5 months ago.

Target version:
Start date:
Due date:
% Done:




Forkbomb, Wolfie and many others have been working on mainlining the kernel for Midas boards (Samsung Galaxy S3, Note, etc.). We want to have Replicant running using that.

Current progress on the kernel can be seen here:

Putti/Joonas is making it work with the latest AOSP master branch. So far it boots and graphics & touch work. After the devices work with AOSP master (maybe weeks, months or years) the work needs to be rebased to the latest LineageOS version. Then the binaries need to be removed and Replicant artwork added.

Current development version can be downloaded with this command:

repo init -u git:// -b master


#1 Updated by Joonas Kylmälä 6 months ago

  • % Done changed from 0 to 10

Graphics work now and the operating system works now, too but it is really slow. I decided now to start publishing sources, so here you can download the kernel I used: :aosp/kernel_i9305.git. To compile it just do "ARCH=arm make midas_defconfig && ARCH=arm CROSS_COMPILE=arm-none-eabi- make zImage dtbs". With "cat arch/arm/boot/zImage arch/arm/boot/dts/exynos4412-i9305.dtb > kernel.img" you are able to append the device tree to the kernel and the image can be then used with AOSP. More repositories coming tomorrow!

#2 Updated by Joonas Kylmälä 6 months ago

Here is my little fork of hardware/libhardware: :aosp/libhardware. The change is that the hwcomposer.default now implements some dummy functions that are needed to support framebuffers (/dev/graphics/fb0). In the long run I will try to get the drm_hwcomposer working with the phone.

I also sent today a feature request "ARMv7-A architecture support" to SwiftShader and I got these instructions back on implementing support for SDIV/UDIV:

The Subzero JIT compiler that we're using for ARMv7 does have support for emulating division (see TargetARM32::genTargetHelperCallFor), which as far as I can tell would require two changes to use it: in Nucleus::Nucleus(), set the target instruction set to Ice::ARM32InstructionSet_Neon instead of Ice::ARM32InstructionSet_HWDivArm, and secondly sw::relocateSymbol would have to support R_ARM_CALL relocations and resolve the address of the emulation functions."

Does someone want to try implementing the emulation as described so that less patches in the kernel would be needed if we end up using SwiftShader?

#3 Updated by Joonas Kylmälä 6 months ago

I started writing the i9305 device tree from scratch soo it took me a bit longer to release the source code but here it is: git:// If you want to compile an image that can be run on your i9305 phone just do the usual "repo init -u git:// -b master" and then follow the instructions on device/putti/i9305/

Oh yeah, I didn't get around writing a manifest file yet to this rewrite so graphics won't work. I'm gonna be busy the next couple of weeks so maybe someone else wants to write it? The fstab also needs some work, and could those dozen hal packages be removed? Patches welcome.

#4 Updated by Joonas Kylmälä 5 months ago

I created now a minimal manifest.xml file that makes the device boot and graphics work! Just do "repo sync" to get the new device tree.

#5 Updated by Joonas Kylmälä 5 months ago

Next goal is DRM graphics (instead of current framebuffer). Can someone confirm me that is the right code repository to use for it?

#6 Updated by Joonas Kylmälä 5 months ago

  • Description updated (diff)

#7 Updated by Joonas Kylmälä 5 months ago

I stumbled upon this issue after updating AOSP source code (repo sync):

build/make/core/ error: device/putti/i9305-kernel/linux/drivers/staging/greybus/tools: MODULE.TARGET.EXECUTABLES.gb_loopback_test already defined by device/putti/i9305-kernel/drivers/staging/greybus/tools.

Looks the same as reported here: I moved now the kernel out of AOSP source code tree as a temporary fix, and so if you want to compile the OS image yourself you need to do the same.

Also available in: Atom PDF