Jump to content

Compiling and booting mainline Linux for your S9XXX TV box


AndrewDB

Recommended Posts

Just wanted to report that I have been experimenting compiling the kernel for Oleg's various Armbian images for S9XXX TV boxes and have managed to compile and boot mainline kernel, but this required a small change in Oleg's S905_autoscript in /boot.

Basically I just added a  couple of lines that bootm the uImage if it is present. If there is no uImage it proceeds to booti Oleg's zImage:

 

setenv boot_start_ml bootm ${kernel_addr} ${initrd_addr} ${dtb_mem_addr}
if fatload mmc 0 ${kernel_addr} uImage; then if fatload mmc 0 ${initrd_addr} uInitrd; then if fatload mmc 0 ${env_addr} uEnv.ini; then env import -t ${env_addr} ${filesize};fi; if fatload mmc 0 ${dtb_mem_addr} ${dtb_name}; then run boot_start_ml; else store dtb read ${dtb_mem_addr}; run boot_start_ml;fi;fi;fi;

I wrote two documents - 1. HOWTO compile the Linux kernel (either Oleg's patched kernel or mainline kernel straight from kernel.org) and 2. How to install the Linux kernel - that can be found here: 

http://wiki.loverpi.com/faq:sbc:libre-aml-s805x-install-newly-compiled-kernel

 

Right now I am running mainline 4.19.20 on a S905 TV box:

andrew@mxqpro4k:~$ uname -a
Linux mxqpro4k 4.19.20-adb9ml #1 SMP PREEMPT Sun Feb 10 19:29:08 CET 2019 aarch64 aarch64 aarch64 GNU/
Linux

 

andrew@mxqpro4k:~$ uptime
22:25:55 up 23:52,  1 user,  load average: 0.00, 0.00, 0.00


Note that there are two distinct ways to compile the Linux kernel for any S9XXXX TV box: you can cross-compile the kernel on a PC running Linux, or you can natively compile the Linux kernel on the TV box itself. I am routinely doing native compiles, using distcc on a build farm to speed compilation.

Link to comment
Share on other sites

9 hours ago, AndrewDB said:

Just wanted to report that I have been experimenting compiling the kernel for Oleg's various Armbian images for S9XXX TV boxes and have managed to compile and boot mainline kernel, but this required a small change in Oleg's S905_autoscript in /boot.

Basically I just added a  couple of lines that bootm the uImage if it is present. If there is no uImage it proceeds to booti Oleg's zImage: 

Add two small patches to the sources and you won't have to use the old and bad uimage format. And you do not need to change anything in the startup scripts, complicating the startup process. These patches work with all my images and kernels (including the latest 5.0).  :)

Link to comment
Share on other sites

2 hours ago, balbes150 said:

Add two small patches to the sources and you won't have to use the old and bad uimage format. And you do not need to change anything in the startup scripts, complicating the startup process. These patches work with all my images and kernels (including the latest 5.0).  :)

Please Oleg tell me what these patches are and where to download them from! :thumbup:

Link to comment
Share on other sites

@AndrewDB very nice I will try later then for my KM8 follow your steps. But first what was your impression since I am running the kernel 3.14 here you saw any difference between the old 3.14 for 4.xx kernel series (more faster or just for have more updated and secure kernel or have more compatibility with the tv box) ?

Link to comment
Share on other sites

On 2/14/2019 at 12:57 PM, xispita said:

@AndrewDB very nice I will try later then for my KM8 follow your steps. But first what was your impression since I am running the kernel 3.14 here you saw any difference between the old 3.14 for 4.xx kernel series (more faster or just for have more updated and secure kernel or have more compatibility with the tv box) ?

The main difference I think is that late 4.XX kernels are much more suited to Ubuntu 18.04. The 3.14 kernel is basically the kernel Amlogic released back in 2015/2016, so it's very old.

But I have not been able to boot a 4.XX kernel yet on my Km8 P S912 boxes, still waiting to solder a UART cable and check what's going on.

 

Edit: finally managed to boot 4.xx kernels on the Km8-P S912 tv boxes, it was a problem with u-boot.

Edited by AndrewDB
More information added
Link to comment
Share on other sites

On 2/14/2019 at 12:34 AM, AndrewDB said:

Basically I just added a  couple of lines that bootm the uImage if it is present.

Hi @AndrewDB.

Thanks for the information you gave. I am trying to use the method you described to boot a ubuntu kernel in Oleg's recent S9XXX image Armbian_5.99_Aml-g12_Ubuntu_disco_default_5.3.0_20191125.img. I'm trying this because the ubuntu kernels include the zfs modules, which are slightly complicated to build otherwise.

I assumed the ubuntu kernel needed to be converted to a uImage, using the command you gave in your kernel installation howto. I correspondingly modified s905_autoscript.cmd as follows:

Obviously I just duplicated and adapted 7 lines from Olég's script. I remembered to convert it to s905_autoscript. The result is that my box still boots into Oleg's zImage, not into the ubuntu kernel which I named uImage-mainline. I'm pretty sure u-boot is executing my modified script, because it is correctly picking up the renamed uInitrd, uInitrd-balbes150 (there is no file called uInitrd any more).

Can you see any error in my script? Or could I be hitting the same problem as you had with the Km8-P S912 tv boxes?

I'm amazed that when the bootm fails (if it is really being executed and failing), the script carries on to the booti steps. I don't have a console to see if this is really what u-boot is doing.

As long as I'm asking basic questions, do you know where the value of dtb_mem_addr comes from? It seems to be defined only in emmc_autoscript, which is not executed before s905_autoscript, if I understand aml_autoscript correctly.

Thanks in advance.

For completeness, my box is a Beelink GT1 Mini (S905X2, 4GB/64GB).

As this is my very first post, I take the occasion to thank Oleg very much for all his work, making it possible for many of us to run Armbian on these tv boxes with very little knowledge.

 

Link to comment
Share on other sites

On 2/14/2019 at 1:41 PM, AndrewDB said:

Edit: finally managed to boot 4.xx kernels on the Km8-P S912 tv boxes, it was a problem with u-boot.

Hi. I know it's been a long time but do you remember what the problem was? I have not been able to boot any kernel using bootm, not even Oleg's kernel converted into a uImage following your instructions. Thanks.

Link to comment
Share on other sites

1 hour ago, PhilipT said:

Hi. I know it's been a long time but do you remember what the problem was? I have not been able to boot any kernel using bootm, not even Oleg's kernel converted into a uImage following your instructions. Thanks.

It should be possible to build a local kernel.  I have been doing it for a while now and have similar boxes (s905w, s905x2 and s905x3).  Here is what I have been doing.


Now let me see if I can remember all of the setup steps I did to get a working environment to build and deploy into.

1) My builds are against either 5.4 or 5.6 kernel.org sources (i.e. git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git)

2) I used the kernel config files from a corresponding balbes150 build against the same kernels (so the correct options are being compiled in)

3) I applied the text_offset.patch mentioned above in this thread so that I didn't need to modify the boot command in the autoscript files

4) I modified my uEnv.txt file for the location of the dtb (which I have been putting in /boot manually, instead of a /dtb directory)

5) I think that is all, but I am probably missing something important

 

Given your goal above, I would start simple (just getting a user built kernel running) then start adding in the other features you are looking for (zfs in your case).  

# Sync git with kernel head
git pull

# make the necessary components
make LOCALVERSION= -j4 Image modules dtbs
sudo make modules_install
sudo make dtbs_install

# convert image for install
sudo cp /boot/uImage /boot/uImage.bak
sudo mkimage -A arm64 -O linux -C none -T kernel -a 0x01080000 -e 0x01080000 -d arch/arm64/boot/Image /boot/uImage

# copy over the new dtb file(s) (because the default dtb directory is versioned, this copy prevents the need to edit the uEnv.txt file every time the version number changes)
sudo cp /boot/dtbs/<linux_kernel_version>/amlogic/<whatever-dtb-you-need.dtb> /boot

# prepare the initrd
sudo cp /boot/uInitrd /boot/uInitrd.bak
sudo update-initramfs -c -k <linux_kernel_version>

# reboot
sudo shutdown -r now

#if everything worked you are now running the new kernel

# cleanup as needed
sudo rm -r /boot/dtbs/<old_kernal_versions>
sudo rm -r /boot/initrd.img-<old_kernel_versions>
sudo rm -r /lib/modules/<old_kernel_versions>

 

Link to comment
Share on other sites

1 hour ago, SteeMan said:

Given your goal above, I would start simple (just getting a user built kernel running) then start adding in the other features you are looking for (zfs in your case). 

Thanks for your detailed answer.

I do have a solution along the lines you suggested - I recompiled a balbes150 kernel with CONFIG_PREEMPT_VOLUNTARY=y and then built ZFS from source. This recompiled kernel boots as usual, using booti with the zImage.

(I presume you put the mkimage ... uImage in your instructions for my benefit, as it's not needed with the text_offset patches.)

But I am still wondering if I can find a way to boot an unmodified ubuntu kernel using the method described by AndrewDB, so I wouldn't have to do any compiling at all to get zfs (just a mkimage). Unfortunately I have not succeeded in booting ANY kernel (balbes, recompiled balbes, ubuntu) using bootm and the uImage, whereas this is presumably the only way to boot an unmodified ubuntu kernel.

Link to comment
Share on other sites

5 hours ago, balbes150 said:

I'll think.

Thanks.

However I'm not certain this would allow zfs to be compiled from source (or dkms) without needing to recompile a full kernel tree, as there may anyway be a problem with the kernel headers package, see https://github.com/ayufan-rock64/linux-build/issues/252#issuecomment-588348845 (and many other posts).

 

Edit: Apologies for not being clear enough: I meant there appears to be a problem with some class of arm64 linux-headers packages in general, not yours specifically.

Edited by PhilipT
Clarification
Link to comment
Share on other sites

On 4/16/2020 at 6:49 PM, PhilipT said:

I'm not certain this would allow zfs to be compiled from source (or dkms)

@balbes150 Again sorry for the uncertainty. I have tested (with your 5.3 kernel on ubuntu eoan) and I found that with the change CONFIG_PREEMPT_VOLUNTARY=y and installing the resulting linux-image and linux-headers packages, zfs (0.8.3) can be compiled from source. (i.e. I mean that a full compiled kernel source tree is not needed for zfs compilation.)

 

zfs-dkms did not work. This is presumably due to the wider problem with dkms.

 

(A note for any other beginners who read this: To do the above test I generated new linux-image and linux-headers deb packages from kernel source. I don't know how Oleg builds those packages. I used "make bindeb-pkg" in the kernel source. It took me a while to realise that the resulting linux-image package installs a compressed kernel image, and just copying that to /boot/zImage does not work. The image had to be uncompressed to be able to be booted, i.e. "zcat /boot/vmlinuz-version >/boot/zImage".)

Link to comment
Share on other sites

  • Werner locked this topic
Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines