Amlogic Oreo 8.1 on S905X

Amlogic ‘released’ Android Oreo 8.1. They did it for their next generation SoC-s but support for S905X also exists. Just to be noted I don’t expect any of manufacturers to release Oreo for their S905X devices. A lot of them are still on Marshmallow anyway.

My opinion on SDK and code is actually good. There are issues here and there but over next few releases of SDK it will be fixed.

Android is stable – only bug I noticed in short time of testing is rotating screen in apps such as Antutu Benchmark (see screenshots below).

Geekbench 4 scores are not too bad (check here).

Kodi 17.6 runs fine, all videos I’ve tested worked without issues but for some reason it doesn’t read CPU usage on any of 4 cores.

So, this is just small report (not review!) on Oreo from Amlogic and how they actually surprised me for once 🙂

Here are some screenshots:


Some thoughts on Amlogic – Part 2

I’m not really sure where to start with this one. Amlogic seems to be doing some funny stuff, both with software and hardware.


I thought that I will start with history of Amlogic SoC-s for STB-s or OTT devices or whatever you want to call them but then I figured that mixing that with what I want to say won’t be good and probably would be too long to read.

Instead of that I will focus on last generation of Amlogic STB system on chips (S9 family). First SoC of that family (S905) was available in 2015. That was 2 years ago. Since then we had couple hardware revisions of S905. S905 SoC is 64-Bit quad core ARM Cortex A53 system on chip with integrated Mali 450 GPU, USB 2.0, internal Ethernet PHY (10/100 Mbps) with support for external Ethernet up to 1 Gbps. It implements HDMI 2.0 IP with maximum output resolution 4K at 60Hz and hardware h265 (HEVC) video decoder. Originally SoC was clocked and advertised as 2.0 GHz chip but in later SDK releases for platform it was down-clocked to 1.5 GHz (however, on Amlogic’s openlinux website it’s still stated that it is 2.0 GHz SoC) However, it was lacking VP9 hardware decoding capability. After that S905X was introduced with VP9 hardware decoding which implemented support only for internal Ethernet (10/100) but it was compatible for Android TV certification process (since Android TV requires SoC to support VP9 decoding among other features).

After that, S912 was introduced, Octa core Cortex A53 SoC with Mali T820 GPU, clocked at 1.5 GHz which had Gbit Ethernet support and VP9 hardware decoding.

When I first saw specifications of S912 it looked very promising. But that excitement faded with time. But more on that later.

Couple weeks ago I read that there’s new Amlogic SoC called S805X. I thought it was joke but it seems it is not. As stated on Amlogic’s Android 7.1 SDK releases page, it exists. I tried to get some more info on that chip but only I got is that it is S905X SoC with video output limited to 1080p (?!).

Couple days ago I saw article on CNX Software titled – Tanix TX3 Mini TV Box is Powered by Amlogic S905W SoC. Once again, it’s joke or typo, right? Never heard of S905W yet it exists and this time specs says that video codecs supported are: 4K@30fps H.265, MPEG1/2/4, H.264, HD AVC/VC-1, RM/RMVB, Xvid/DivX3/4/5/6 , RealVideo8/9/10. So basically you have HDMI 2.0 capable of 4k@60Hz but you limited 4K decoding to 30fps?!

This is frustrating, just getting all the info to put in post. There are some other SoC-s like S905L, S905D… and maybe there will be S905Z in future with I don’t know…. Mali 400 GPU that was used in earlier generations? Who knows…

Now I want to say something about software, more precisely Android 7.1 SDKs released (officially) by Amlogic.

Android 7.1 SDKs

This part was actually reason why I wanted to write article but in meantime I decided to add some hardware info and confusion 🙂

Back in March I wrote Amlogic Nougat small review and thoughts post. But now it’s more exciting…. We have some new bugs and some bugs that brought back to life! Awsome….

On Android 7.1 SDK releases page you can see versions that are official so you can follow story I’m going to tell you.


There was SDK release 2017-06-19 which was decent release. HDMI passtrough was working fine (tested), even HDMI self adoption as they call it was working not only with native VideoPlayer app but with all apps (Kodi, YouTube for Android TV…). What is not fixed and no documentation provided is IR remote issue where IR codes are HARDCODED in kernel device tree include. All of it is described in my post from March but to sum it up, they hardcoded infra-red remote codes into kernel’s device tree include files (yes, for each platform one file. One for GXB, one for GXL, one for GXM and so on).

After that SDK release, as you can see on SDK releases page, new release was made, dated 2017-08-04. That release states that it’s patch for 2017-06-19 release.

Changes in 2017-08-04 version (both versions tested on S912 board):

  • IR issue still not fixed
  • SoC gets extremely hot for no obvious reasons in almost idle state (I’m talking about approximately 20 degrees Celsius difference)
  • HDMI passtrough is not working anymore (but Amlogic engineer I talked to claims that it passed QA on q201 board (S912 board, same as mine). Even shows me small cropped screenshot where someone reported that it passed QA)
  • Google’s ExoPlayer is not working – crash on any attempt of video playback – also happens in latest Android 6.0 SDK (response from engineer that I quote: we test it by the android 7 release. it is in common use)
  • And finally… HDMI self adoption is not working. This is kind of hilarious, I will put below images of sample video results (ffprobe on my laptop and fps calculation on Amlogic S912 device together with current refresh rate on TV). Basically what happens, screen ‘switches’ to refresh rate closest to fps of video, except it doesn’t do that…. It just flickers.

Here is ffprobe of tested video:

And here is Putty output of 2 sysfs nodes when same video is playing in native VideoPlayer app and HDMI self adoption is turned on:

I also said that I will write why S912 excitement started to fade for me…

Well, it is simple. I agree that S912 is not bad SoC at all. Problem is with Linux support for it. Fact that S912 is using Mali T820 GPU and that there are no any Linux userspace libraries available (and probably won’t be) you have only option to use it as Android device. Another fact is that Amlogic hired BayLibre to bring Amlogic GX support to mainline Linux kernel. CNX posted that Shenzhen Wesion company who is behind Khadas VIM development board is working on VIM2 board which will be based on S912 SoC. So, my question is, what is point of development board with features like HDMI output, DVB bus… when you are limited to Linux console and basic framebuffer device without any kind of hardware acceleration (again because there is no Mali T820 Linux support available).

Aside from development boards, there are open source projects like LibreELEC that would love to port Just enough OS for Kodi to S912 devices but they can’t.

Another thing is, Amlogic is stuck in past. They are utilizing USB 2.0 for years, they do not have SATA controller, not to mention PCIe. Take Rockchip for example. They have all of that. They are opening their sources They announced their new official wiki pages with all resources, they host their sources and Mali blobs on their official Github pages. Rockchip is integrated in some of Chromebooks. From that perspective, Amlogic is years behind Rockchip.

Few years ago I had very different opinion when someone would ask me to compare Amlogic and Rockchip. But not anymore. Same goes for Allwinner.

Amlogic, please wake up!

Amlogic Nougat small review and thoughts


I’d just like to make it clear that all mentioned here is my opinion and mine only. This post will be combined technical and user perspective review of Amlogic Nougat 7.1.1 SDK release 2017-02-22.

Few technical details about this SDK:

  • Original Amlogic source is based on AOSP Nougat branch android-7.1.1_r6 (NMF26Q) which I bumped to android-7.1.1_r26 (NOF27C).
  • Kernel used with this SDK is still version 3.14.29
  • Compared to Marshmallow SDKs, Nougat can be built with as 64 bit Android OS
  • Mali T820 kernel and userspace libraries are still r11p0
  • Internal storage partitions are changed in size, so in 99% of cases I am pretty sure current devices that are on market will not receive Nougat update (at least not 64 bit version). For example, system partition (where Android is actually installed) is now 2 GB in size by default (defined in kernel) while on previous versions (I am sure for Lollipop and Marshmallow was 1 GB). 64 bit version of Nougat running on my test device takes approximately 1.5 GB of space on system partition.
  • There is work to be done and some ‘crazy’ stuff to be sorted out, especially one in particular which I noticed today and it’s connected to IR remote support (more about that at end of post)

UI, design flaws, bugs


Nothing new here. It’s not changed since Lollipop release as far as I can remember. Each tile opens it’s own section, you can add or remove apps on bottom… Usual stuff

Settings (new)

I don’t have any notes what to write here but I believe I will spent most of my time writing about Settings. You will see why in what’s following.

So, on screenshot above you can see that settings are now Nougat style (some of you might be familiar with it if you were using Nexus Player with Nougat or similar device). You open this right hand settings view by clicking on Settings tile in Amlogic launcher. Keep in mind that this is only place from where you can open this. If you are using 3rd party launcher or stock Android launcher or whatever, you will not be able to open settings because there is no icon in app drawer which you can click to open it (like you had in Marshmallow, 2 Settings apps, one with tiles and one normal Android Settings app which you can see on phones or tablets).

From my perspective it can and should be done differently.

Settings (new) design failures

As I said, this my opinion. I will put few more screenshots of settings then I will write something about it.




So, from first three images we can see some consistency in following new design of settings app. Another 3 are just almost copy/paste from Marshmallow and just made to work. I am not designer, but this looks just wrong…

Settings (new) – bluetoothremote

I will put it here just to show how it looks. What it does – beats me. Maybe someone in comments will be able to demystify this for me.


I did not get any documentation on this feature. When you select Upgrade bluetoothremote from settings you get 2nd screen. Before I paired my BT headset this list was empty. And when I tried to pair my OnePlus 3 phone with box it could not see it. So, what it does – I don’t know 🙂

Settings (normal)

First, pictures:


There is not much to say here. Normal Android settings app opens, but as soon as you click on one of items (in this case About media box) app crashes which is visible on 2nd image. And yes, this normal settings app you can start from app drawer (list).

Web browser

Picture again:

Also, not much to say here. However this is not Amlogic’s fault. As I understand, Nougat does not come with default Browser app like we knew it before. Instead it comes with Browser2 which is basically WebView component tester. So if you want to browse on this, you will most probably have to install either Chrome or Firefox or whatever to normally browse web 🙂

Media playback

I am not much of tester when it comes to media, codec testing, but I can say that I did not come to any issues with video playback. If you want some extensive tests on that you’ll have to wait CNX to get one of boxes with Nougat installed 🙂

Crazy stuff to be sorted out – IR remote

I came across very interesting issue. I prepared my Nougat build with my IR remote codes (I took short way – I copied it from Marshmallow tree). It’s simple, Amlogic always used remote.conf which is placed inside /system/etc folder.

And that didn’t work. So two reasons crossed my mind:

  • I built Android as 64 bit OS which means remotecfg binary is also built as 64 bit binary. During my earlier work with 64 bit Linux based OS on S905 I had issue with that binary causing segmentation fault and fixed that issue on Linux. So even before building Nougat I checked remotecfg source to see if Amlogic fixed issue they had and I saw they did not, so I applied my patch there.
    Conclusion – remotecfg binary is not issue, it does not crash
  • Another thing that crossed my mind is that maybe Amlogic changed structure of remote.conf file (which they did in Marshmallow I think, to support multiple remotes). That check also came back as not causing issue.

So, I went back to check on debug port (UART) what is going on and on each press of button on remote I would get output:

And no, it is not typo 🙂

After that, I tried to find cur_custom string in remotecfg sources without luck. Then I went to check kernel side (IR remote driver). Indeed, kernel was throwing that error.

Digging little deeper I ended in looking at kernel device trees for Amlogic boards. What I found was… horrible is the word?

If you are familiar with kernel structure, device trees and stuff this will make sense to you. If not, well…. they blew it.

Kernel device tree is basically DTS file which includes some other platform related DTSI files. And in THAT DTSI files I found HARDCODED key mappings for exactly 3 remotes. Here is how it looks like:

Honestly, I’m pretty shocked by that. To include something like that in device tree for particular board (eg. gxm_q200_2g.dts) – well, ok. Not ok, but at least it’s not hardcoded to all device trees which include eg. mesongxm.dtsi.

If some of things will be fixed/changed from Amlogic side I don’t know. I hope if someone from Amlogic reads this post things may change to better.

As for me and my work, I’m not relying on all Amlogic changes they make and as I said in beginning – I made my private GIT server with my repositories and I bumped Android version. Btw, bumping Android version has nothing to do with bugs or issues mentioned here.

Some thoughts on Amlogic

It’s been a while from my last post here. Today I saw they released new version of Buildroot. More info about it here. They managed to file size of 1.3 GB with this. In their release notes which you can see here they mentioned few things that comes with Linux SDK release 1.5:

Merge kernel 3.10&3.14 into one src code

Now, within this 1.3 GB you don’t get GIT history, no no. To be able to download their version of Buildroot from their GIT server, here is what they say:

You should have the permission to download the git, you can contact with the FAE for help.

That means basically that you cannot get access to it unless you are manufacturer who is utilizing their SoC-s.

So, from my perspective and content of tarball with provided we have this:

  • Buildroot itself which is v2016.11 (in time of writing this post there are versions 2016.11.1, 2016.11.2 and 2017.02 available)
  • Hardware folder with separate drivers for 3.10 and 3.14 kernel that includes Mali GPU, WiFi modules, touch drivers, NAND/eMMC drivers and TVIN drivers which I assume that are used by both 3.10 and 3.14 kernel
  • Kernel folder which contains 3.10.33 and 3.14.29 versions
  • Multimedia folder which includes some alsa plugins, gstreamer plugins, libplayer (part of libplayer is so called amffmpeg which is Amlogic’s version of ffmpeg and it seems to be stuck at version 0.8 – at least that’s what is written in version.h:
  • And finally toolchain folder which contains toolchains 😀

When it comes to whole package, it nicely says which are supported boards:

  • S905: p200 and p201
  • S905X: p212
  • S905D: p230
  • S802: k200b
  • S805: m201 and m200
  • S812: n200

In release notes (PDF document I linked above) they also wrote instructions on how to download whole package using their GIT server to which you don’t have access.

There is also written how to potentially make your system unstable by downloading, building and installing GNU MPC version 0.9 because their old modified U-Boot for Meson 8 platforms can’t see libmpc other than

More safe way to do this would be maybe to symlink existing* to In my case on Ubuntu 14.04:

And guess what, it works just fine. On Ubuntu 14.04, Debian, openSUSE Leap 42.2… I would characterize Amlogic’s approach as laziness.

Laziness is not just that. If you’re developer and you look a bit into their sources (kernel for example, doesn’t really matter which one), you will find something like this:

You will also find commented code all over their kernel drivers. There are also cases where void function returns integer for example and stuff like that. It’s just something that I cannot understand

Now, enough of laziness… Let’s see what else we have in that PDF:

They have listed all configurations they support by their build system (I said build system because in the end with all of their changes and structure of it, it doesn’t look like Buildroot as you know it). These configurations are:

After this we have some instructions on how to install built system to sdcard or Nand/eMMC and how to boot it.

We also have nice instructions on how to enable WiFi and how to test LibPlayer and GStreamer1.

Most interesting part for me is Appendix D in this PDF.

It contains few commands on how to enable display output and test OpenGL ES acceleration. Just to clarify here, Amlogic SoCs have Mali GPUs (Mali 450 on S802, S805, S812, S905, S905X, S905D and Mali T820 on S912).

What is interesting here is that you cannot perform any tests from Appendix D on Amlogic S912. Why? Because there are no Mali T820 userspace libraries (framebuffer or X11) available. From what I found out, fact is that Amlogic did not license Linux userspace libraries for Midgard Mali GPUs and they do not have any intentions to to that. I think S912 SoC is good chip, especially if implementation is right (and I’m fortunate to have ODM which makes great hardware) but fact is, when it comes to Linux you can make headless Linux server for…. something. NAS…. I don’t think so, they are still using USB 2.0 controller in their SoC-s. They don’t have native SATA interface, or any kind of expansion like mini PCIe.

And finally there are few notes I keep in my head…

  • After S912 which was available in Q2 2016, there are no new SoC-s announced or any rumors about it
  • Did they finally realized that they are far behind with their 28nm process and that they have to invent something new and are working on it
  • They do have Android 7.1.1 Nougat SDK for their S905X and S912 SoC-s, so if they don’t have new SoC to show up, they will try to survive on old ‘fame’ with ODMs buying 1 or 2 year old SoC-s but with Nougat preinstalled?
  • Xiaomi released their own SoC recently (and rumors were that Xiaomi and Amlogic are tightly connected). Coincidence? Maybe…

Well, if you reached that far in reading this post, congratulations, you just read 864 words 🙂

Kernel for few Amlogic MX devices

Since I was asked multiple times about kernels for some devices I worked on I found some time and went trough archives.

Kernel (Android one) is located on my GitHub account – kernel-amlogic-mx.

Boards covered by this kernel:

  • Prestigio PMP5670C (meson6_pmp5670c_defconfig) with panel configuration and touchscreen driver
  • VissonTech ATV-102S/ATV-106/Tronsmart Prometheus (meson6_g18_atv102s_defconfig)
  • Zoomtak T6 (meson6_g18_dbxm6_defconfig) – does not include VFD driver
  • Shiningworth MX, Gbox Midnight MX2 and most of its clones (meson6_g18_dbxmx_defconfig)

As I said, this is Android kernel based on 2014-04-28 SDK. To compile it, you need rest of SDK (JellyBean 4.2.2) which can be found on Internet.

For kernel building only, you will need ARM Linaro toolchain from Amlogic download site and modules (Wifi, nand, Mali) which hopefully still can be found on another Amlogic download site. Keep in mind that Mali driver used in your kernel must match version of Mali binaries in userspace otherwise it won’t work.

Amlogic released new Linux SDK

Yes, it happened! On 4th of May, Amlogic released their new Linux SDK which includes Kernel 3.14.29 (I’ll talk about it later), Buildroot 2016.02, U-Boot and kernel drivers for their 64bit STB and TV SoCs.

All mentioned can be found on their GPL download site.

What is new in that Linux SDK you might ask… well, nothing special. Just few new driver implementations for CEC, eMMC/NAND, lightly modified WiFi drivers code, commits to kernel tree (which was originally forked from Linaro 3.14 which can be seen from kernel sources available eg. on Hardkernel’s Odroid C2 GitHub), few new reference boards introduced and more bugs!

It is amazing how these things happen. Current GPL release of Amlogic kernel is as is. GPL releases are released as tarballs (no way you will get full git history).

I will be whining for one old issue Amlogic does have on all of it’s platforms and on all released (GPL and non-GPL) and one I struggled with today for 2-3 hours until I figured out why simple Linux tar command is crashing and not doing it’s job (Error in ‘tar’: double free or corruption) when passing simple arguments to it like:

That simple command worked perfectly on all kernels they released before latest one (tested on same Buildroot version and with same tar sources). That latest kernel is mixture of everything. There are some normal AOSP 3.14 patches and there are some backports (Amlogic engineering way) from (get this!) 4.3 kernel.

Now, normal way of debugging this error would be…. Do I have everything enabled in my configuration files (Buildroot 2016.02 and their GPL Kernel) so my tar command can read SELinux contexts, POSIX ACLs and extended attributes? After I double checked my configuration I started rebuilding whole system because well, maybe something went wrong. 2nd try… Same error.

Ok, I forgot to enable GDB but I can build it without rebuilding whole system so I did that. Running same tar with it’s attributes from debugger gives me hint. Kernel kills tar without much useful information.
Thinking about it for 5 minutes or so I remembered that in git history from non-gpl released kernel there are changes to security subsystem (SELinux to be exact).

Figuring that if I already spent that much time trying to fix issue I have, I’ll spend additional 15-20 minutes rebuilding kernel with SELinux completely disabled. And guess what…. It worked! Wtf?!

Ok, so that was it. Cleaning Buildroot configuration, modifying Kernel config not to build security subsystem, rebuilding whole thing and that issue can be closed (for now).

Second issue I mentioned earlier is really disappointing. Amlogic M8 series (S802, S805 and S812) and GXBaby (S905) in Android (I did not check older platforms like MX but I am pretty sure it is same) do have issue with online SD quality streams that are using adaptive bitrate (via application developed for world wide operator).

Not only that I reported that issue to one of Amlogic engineers but also to person who (is or was? Not sure there because he seems to ignore me for some time now) my contact in Amlogic multiple times, I offered them everything they need (VPN account, account to service provider that is providing that OTT service…) and…. I got one big NOTHING. Not even reply telling me that they are not interested in fixing that particular issue or that they just don’t care about it (it’s about manners Amlogic guys!).

I think it’s enough whining for today so I will write something I find very positive.

Guys behind site are doing their best to bring Amlogic SoC support to mainline Kernel and U-Boot. More about it you can check on their site.

If there any comments or questions maybe, I will actually reply to them 🙂


Burning .IMG file to Amlogic M8 devices using sdcard

Recently I had situation where I had to write firmware to S805 device that had no USB OTG port which means using USB Burning Tool is not an option.

Since I saw in Amlogic SDKs and U-Boot sources that there is a way to burn USB Burning Tool image file using sdcard (first clue was aml_sdc_burn.ini file that exists in almost all reference board device trees in Amlogic Android SDK) I decided to ask Amlogic for official documentation that explains how it works technically, what are possible values for certain options etc (because digging trough code is not quickest option to see how it works). After 2 mails and none of them with useful information, I decided to do my own research.
Basically it works almost the same way as burning image using USB Burning Tool.

Technical description:

When you put aml_sdc_burn.ini and let’s say (default name) aml_upgrade_package.img to your sdcard and you power on your device using reset button (note: on some S805 devices there is no reset button; option if implemented by manufacturer would be using your IR remote with pressed correct button when powering on your device).
During that process U-Boot finds aml_sdc_burn.ini file on your sdcard and tries to do following:

  • Temporary set internal flag that makes sdcard first bootable device
  • Resets device and tries to load U-Boot from sdcard (I will go back to this part later)
  • If successful, bootloader is loaded from sdcard and executed (instead of one stored on NAND/eMMC or SPI chip)
  • When bootloader is started, USB (well, SDC) burning mode is activated and based on values in aml_sdc_burn.ini file IMG is burned to your device

Now, if you read carefully, you might notice that sdcard with only .ini and .img file will not result in anything but rebooting your device to existing OS. That’s because I didn’t prepare my sdcard to be bootable (or recovery sdcard).

If you are running Linux, I described how to create recovery sdcard in post How to create Amlogic recovery SD card from Linux.

If you’re on Windows machine, under Downloads -> Amlogic tools you have tool called BootCardMaker which will help you to create bootable sdcard. Just start BootCardMaker as Administrator (if you are running Windows newer than XP), select your sdcard drive letter, mark that you want to format your card, select your U-Boot (must be for your device!), click on button MAKE and follow instructions.

If either on Windows or Linux, after preparing your bootable sdcard, copy your .img and .ini file to it, safely remove sdcard from your computer and you are ready for procedure described above. During burn process you will have green droid on your screen with moving progress bar. Very important is that YOU DO NOT DISCONNECT YOUR DEVICE FROM POWER DURING PROCESS.

Information about aml_sdc_burn.ini file format

This is default example of file:

As you can see, file contains 2 sections – common and burn_ex.

Let’s focus on common section and it’s parameters:

erase_bootloader – This parameter can contain 2 values (0 and 1). 0 will not erase your bootloader while 1 will.

erase_flash – This parameter contains 5 valid values (0 – 4) and here is what it means:

0 – Do not erase flash
1 – Normal erase (same as in USB Burning Tool)
2 – Information not available, will update post when I find out meaning of value 2
3 – Erase all (erase NAND/eMMC content and bootloader which exists in protected area)
4 – Force erase all (this option unprotects all protected areas of NAND/eMMC/SPI, raw formats everything and reparitions storage)

reboot – This parameter can contain 2 values (0 and 1). 1 will reboot your device after process is finished while 0 will not 🙂

Now burn_ex section:

package – full file name of .IMG file that exists on sdcard to be burned

media – in this example, media parameter is commented. I did not find much info about that parameter, but it seems that it should point to raw partition image of media partition. Little confusing eh. For this parameter to be enabled and work as it should, bootloader needs to be prepared for extra media partition which is not enabled by default.

Final words

Ok, I hope that I helped someone with this.

Please be noted that all that is written above you are doing at your own risk. I do not take any responsibility for broken/bricked devices etc…

How to create Amlogic recovery SD card from Linux

Amlogic recovery SD card is used when device is bricked, when bootloader does not exist on boot device (SPI chip or NAND) or it is corrupted.

Linux (any distribution) is most convenient OS for creating that kind of card. Basically, card is created that way that first 3 cylinders on card are reserved for bootloader. FAT32 partition follows (starts on sector 3 to the end of sdcard).

Let’s say we want to create recovery card for MX board. MX uses u-boot.img as bootloader name. We will asume that our device is bricked and needs complete firmware reinstall.
So, we need: u-boot.img for that device and rest of firmware ( and recovery.img which is recovery kernel + tools, usually Android recovery system).

We will asume this:
Our sdcard is: /dev/sdb
First partition: /dev/sdb1
Mountpoint for sdcard: /home/stane/recoverysd

First we will unmount our sdcard if it is mounted

Next we will raw copy u-boot.img from our current folder to sdcard (not partition!)

Now we have to delete all existing partitions on sdcard and create only one that will start from 3rd cylinder. Most newer Linux distros uses also newer version of fdisk utility which consider cylinders for display/entry unit as deprecated, so before any action you have to enable it by issuing “u” in fdisk and pressing enter key.

So, lets start with fdisk. We will start it with following command:

in fdisk, as I said earlier we will first issue u command and hit enter which will result with message: Changing display/entry units to cylinders (DEPRECATED!)
Just ignore it and contine.

Next step is to delete all existing partitions from our sdcard. Hit d command and after that hit p command to see current partition status on your sdcard.
Repeat this step until all partitions are deleted.

After issuing p output should look like this:

with no partitions listed.
When we cleared our partition layout, its time to create new one.

To do that, issue n command and create primary partition (by selecting p option on next menu).
When fdisk asks for partition number, leave empty (1st is by default) and continue.
Now comes our cylinder part. Fdisk will ask you for First cylinder. Put there 3 and continue.
Next, it will ask for last cylinder. Leave default value (just press enter).

Ok, partition is created, but its raw for now. We have to assign filesystem to it (which will be FAT32). So, issue t command and after that b command (b is code for FAT32 partition type).

When done, with these steps, issue w command which will write changes to sdcard and will exit fdisk.

Ok, now we have to format our newly created partition which we will do with issuing command:

When partition is formatted, you have two options. Either you will re-insert your card to cardreader, or you will mount it manually to folder from which we unmounted it.

If you choose second option, issue command as follows:

When mounted, copy all your firmware files to sdcard and properly unmount it and eject from your cardreader. You can unmount it within your Linux distro file manager or with command:

Now your recovery sdcard is ready to use.

When you finished with recovery of your box, you’ll probably want to back your card to normal (because using it in another box, might brick it).

We are going to do that by raw copying few kilobytes of zeros to start of sdcard (after we unmounted it) with following command:

After procedure is finished, start fdisk as before (which will warn you that your drive/card is corrupted) and just issue w command. Fdisk will write changes to sdcard and exit.

After that, start fdisk again and create your new partition (none exists anymore) as you did before, just use default values. After that, format the file system on your sdcard and thats it.

Hope it helped someone 🙂