How to replace Linux kernel for Ubuntu version of OS on 410c board?

Products Support DragonBoard410c
#1

I am running the Ubuntu version of OS, i.e. installed it on 410c board from an uSD card while using the
dragonboard410c_sdcard_install_ubuntu-102.zip installation package.
It worked as expected (i.e. great :)).

Now, I would like to replace the given Linux kernel with a version which I have compiled
following the instructions from https://github.com/96boards/documentation/wiki/Dragonboard-410c-Boot-Image
The last command, i.e.
make O=build-${ARCH} -j4 Image dtbs
generated both the “boot/Image” and “boot/dts/qcom”

Then I used the “dtbTool -o dt.img -s 2048 $KDIR/arch/arm64/boot/dts/qcom/”
to make the “dt.img”.

Finally I used
export cmdline=“root=/dev/disk/by-partlabel/rootfs rw rootwait console=ttyMSM0,1
15200n8”
and
mkbootimg --kernel $KDIR/arch/arm64/boot/Image
–ramdisk $RDIR/initrd.img-4.2.0-linaro-lt-qcom
–output boot.img
–dt dt.img
–pagesize 2048
–base 0x80000000
–cmdline “$cmdline”

As a result the “boot.img” was generated.
I have mounted the previously used uSD card, and have found the “ubuntu/boot.img”.
Then I have replaced it with my own version, generated as specified above.

The new “installation uSD card” works as well as previously, but after removing the uSD card
the system did not boot.

Any suggestion how should I proceed with the (mere) replacement of the used Linux kernel?
… it seems, that the above steps may not be needed at all, but I don’t understand their
importance.

Thanks,
-zenon

#2

Hi Zenon,

It seems you didnt flash the image to the emmc.

sudo fastboot flash boot boot-db410c.img

Any reason for that?

#3

hi,

did you try to boot your board with the boot image you generated, before even trying to reflash the board? e.g. if you install our release with our SD install image, then you can use ‘fastboot’ to boot your locally generated image:

fastboot boot boot.img

You need to have USB connection between PC and the board, as explained in the user guide.

If your locally generated boot image doesn’t work, it’s not worth trying to go further and update the SD install, we need to figure out why it doesn’t work. And to debug boot issue you will very likely need a serial/UART console, so you will need the appropriate setup (USB/TTL cable, or debug mezzanine board).

cheers

note: I will be out from now until Monday morning. So do not count on my replies before that…

#4

Thank you much for the both replies … which have the common ground of the need to use
the “fastboot”.
True, I did not use fastboot … and I need to study how to get it, where to install it, etc.

I hoped, that having the Ubuntu version of OS will simplify the kernel experiments.
Apparently, not.

So, I am about to study the basics of using “fastboot”.
Actually, I got the impression, that the fastboot is being used only in the Android realm?
But maybe not.

Thanks,
-zenon

#5

I have problems with using the “fastboot”:

The “documentation” from the https://github.com/96boards/documentation/wiki/Dragonboard-410c-Installation-Guide-for-Linux-and-Android
suggests, that
“The DB410c must have been imaged with fastboot previously. There are two ways to do this:
by following the procedure outlined in the Create / Install a Rescue Image section of this document
by following the procedure in the Installing Image using an SD Card Image section of this document”

If I then understand it correctly, after I have followed the “Installation Image using and SD Card Image”
(more specifically: Installing Ubuntu OS from the SD card), the DB410c is supposed to support the
“fastboot”.

  1. I have set the S6 switch to 0-0-0-0
  2. Connected the uUSB to the host PC
  3. pressed and held the S4
  4. finally powered the DB410C up

But from the host PC the “fastboot devices” did not show any devices.

Any suggestions how to proceed further?

-zenon

#6

Steps 3 and 4 need to be done simultaneously (ie: power up the board while pressing S4 and continue pressing for about a second).

Also maybe try using the fastboot command as super user.


# sudo fastboot devices
# sudo fastboot flash boot boot-db410c.img

btw, remember that after replacing the kernel you will also have to install the new modules in the filesystem.

#7

Using “fastboot” from a host X86_64 PC is still unsuccessful.

In all attempts to activate the “fastboot” on the 410c board I was following
the specified steps, i.e.

  • having the uUSB cable connected from the micro-USB port to the host PC
  • having the S6 switches set to 0-0-0-0
  • pressing the S4 button and keeping it pressed
  • powering up the 410c
    (btw: How long should I keep the S4 being pressed??)
  • from the PC typed

    fastboot devices (note: I executed it as “root”)

No any devices we listed.

Any suggestions what am I missing?
Btw, I have tried 3 different “uUSB-2-USB” cables, and tried different USB sockets
on the PC. The same negative result.

-zenon

#8

you have to keep S4 pressed until the boot code detects that switch is on and enters the mode (that would be a couple of seconds at max but it doesn’t make a difference if you hold it for longer)

can you access the serial console from the low speed connector? you only need three wires and a USB to 5V TTL FTDI cable.

Once plugged you should see something like this on your minicom:

[...]
[200] udc_start()
[500] -- reset --
[500] -- portchange --
[570] -- reset --
[570] -- portchange --
[680] fastboot: processing commands
#9

Following your suggestion, I have finally used the serial console connection,
and verified that the sequence, ended with
“[680] fastboot: processing commands”
was displayed.
Then, “miraculously”, the “fastboot devices” had shown the non-empty output
and I could use “minicom -D /dev/ttyUSB0” to connect to the console.
Then I have tested the “fastboot boot boot.img”, where the “boot.img” was generated
with my new kernel.
Unfortunately (as partly expected) the booting sequence ended with a “panic”.

I need to explain here, that the kernel which I have generated had the following different
characteristics, when compared to the default kernel:

  1. It used 64k pages, instead of the default 4k pages
  2. It did not provide support for MODULES.
    This “feature” was not necessary. I merely had some problems in the past with the
    kernel generation, and when I have seen, that “/proc/modules” did not have any entries
    in default systems, then I have just dropped MODULES support.

I am going now to generate kernel with 4k pages, somehow mimicking the default kernel.
I will generate its “boot.img” file and will see what will happen.

Any other suggestions?

-zenon

#10

If you are new to kernel development I’d suggest you start by using the kernel and config used on the release to make sure you can re-create the environment. Then do your development one bit at a time.

#11

I have returned to experiments with the kernel with 4k pages.

I have “boot.img” extracted from the “/media/OS/ubuntu” directory, which is part of the Ubuntu
installation file dragonboard410c_sdcard_install_ubuntu-102.zip
and “boot.new.img”, which I have generated.

When I run “fastboot boot boot.img”, the system boots OK.
However, the “fastboot boot boot.new.img” ends with a kernel panic.

Here is what I have done to generate the “fastboot.new.img”:

  1. Used the “config” from the DB410c , which booted after applying the above “_sdcard_install_ubuntu”.
    Copied the “config” to “.config”, and run “make ARCH=arm64 menuconfig”.
    Did not change anything, but acknowledged the “make” making changes to “.config”.
  2. Used “make O=build-${ARCH} Image dtbs” to generate Image and "boot/dts/qcom”

Then I used the “dtbTool -o dt.img -s 2048 $KDIR/arch/arm64/boot/dts/qcom/”
to make the “dt.img”.

Finally I used
export cmdline=”root=/dev/disk/by-partlabel/rootfs rw rootwait console=ttyMSM0,1
15200n8″
and
mkbootimg –kernel $KDIR/arch/arm64/boot/Image
–ramdisk $RDIR/initrd.img-4.2.0-linaro-lt-qcom
–output boot.new.img
–dt dt.img
–pagesize 2048
–base 0x80000000
–cmdline “$cmdline”

As a result the “boot.new.img” was generated.

When I have executed “fastboot boot boot.new.img” then the reported “panic” resulted.

NOTE: On October 22, 11:34, ldts-jro had written:
"

sudo fastboot flash boot boot-db410c.img

btw, remember that after replacing the kernel you will also have to install the new modules in the filesystem.
"
So, it looks like I really need to install the new modules in the filesystem, despite the info
that “Building the kernel modules (optional, only if you need them)”.
I presume, I don’t need to “fastboot flash boot boot.new.img” yet, before having bootable version.

Do I really need to generate new modules?
Is it a way to copy such modules to the RFS already installed without destroying the original ones?
(just to keep the possibility to boot with the original kernel, “just-in-case”)

THANKS MUCH for your help,

-zenon

#12

You can use the kernel.config from the release download area (the link included is for 15.09)

At the bottom of the page pointed to by the previous link you can also find instructions on how to download the kernel and checkout the 15.09 tag (just read the section “How to get and customize the kernel source code”).

if you follow those instructions, you will be able to boot your modified kernel.

When you change your kernel you should also replace the modules: a module is an extension of the kernel that typically contains driver code so you need them (unless you modify your kernel config and compile all the drivers as part of the kernel). In any case dont be afraid of replacing modules: they are just files in the filesystem.

They live /lib/modules/.

When you compile your kernel you could install all the modules somewhere in the machine that you are building.

cd linux.git
make O=build-${ARCH} modules
mkdir build-${ARCH}-modules
make O=build-${ARCH} INSTALL_MOD_PATH=build-${ARCH}-modules modules_install
make O=build-${ARCH} INSTALL_MOD_PATH=build-${ARCH}-modules firmware_install
cd $kernel/build-${ARCH}/build-${ARCH}-modules/lib/modules/
tar czf modules.tgz *

Then copy/untar modules.tgz on the dragon board at /lib/modules.

Of course everything is easier if you are setup to work over NFS but you can optimize your work environment later on as you go.

Error occurs druing procedures of installing Debian
#13

You can also use this other link for some more details.

#14

An intermittent update:

  1. I have (temporarily) continued using the linux kernel sources, which I downloaded
    a week ago following the instructions from https://github.com/96boards/documentation/wiki/Dragonboard-410c-Boot-Image
    It happens, that these sources are for “4.3.0-rc5”.
    I suspect, these sources have “problems”, when the kernel uses 64k pages.
    See points 2 & 3 for substantiation of this suspect.

  2. I have generated “.config” with 64k pages and used the “Image”, “dtbs”, “modules” and “modules_install”
    make targets.
    Then I have generated the “dt.img” and “boot.64k.img”, using the “dtbTool” and “mkbootimg”.
    In the “cmdline” specification I have used the “root=/dev/disk/by-partlabel/rootfs”
    as this was mounted at “/” on successful, default, Ubuntu OS.
    I have extracted the “/lib/modules/4.3.0-rc5” contents of the “modules.tgz”.

  3. Now, for “fastboot boot boot.img” I had two images to test
    A) the “boot.img” extracted from the Ubuntu installation uSD disk
    B) the “boot.64k.img” generated as explained above

    The “fastboot boot boot.img” successfully booted the Ubuntu OS with the “4.2.0-linaro-lt-qcom” kernel
    The “fastboot boot boot.64k.img” was ending with a kernel panic.

    I have compared the boot logs of the both experiments, and have found the spot at which the new
    kernel (version 4.3.0-rc5, with 64k pages set by myself) had failed.
    The significant kernel problem was at the point shown by the snippets below:
    The successful, default system boot had included
    ===
    …
    [ 2.100445] qcom-tsens 4a8000.thermal-sensor: tsens calibration failed
    [ 2.101165] Bluetooth: HCI UART driver ver 2.3
    [ 2.106391] Bluetooth: HCI UART protocol H4 registered
    [ 2.110852] Bluetooth: HCI UART protocol BCSP registered
    [ 2.115937] Bluetooth: HCI UART protocol Three-wire (H5) registered
    [ 2.121615] usbcore: registered new interface driver btusb
    [ 2.128019] sdhci: Secure Digital Host Controller Interface driver
    [ 2.132990] sdhci: Copyright(c) Pierre Ossman
    [ 2.139209] sdhci-pltfm: SDHCI platform and OF driver helper
    [ 2.152079] l5: supplied by s4
    [ 2.152402] sdhci_msm 7824900.sdhci: Failed getting OCR mask: 0
    [ 2.200332] mmc0: SDHCI controller on 7824900.sdhci [7824900.sdhci] using ADM
    A 64-bit
    [ 2.205863] sdhci_msm 7864900.sdhci: Got CD GPIO
    …
    ===

The failing system had generated the following:

…
[ 3.418098] qcom-tsens 4a8000.thermal-sensor: tsens calibration failed
[ 3.421277] Bluetooth: HCI UART driver ver 2.3
[ 3.427212] Bluetooth: HCI UART protocol H4 registered
[ 3.431654] Bluetooth: HCI UART protocol BCSP registered
[ 3.436757] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 3.442380] usbcore: registered new interface driver btusb
[ 3.449907] sdhci: Secure Digital Host Controller Interface driver
[ 3.453771] sdhci: Copyright(c) Pierre Ossman
[ 3.460054] sdhci-pltfm: SDHCI platform and OF driver helper
[ 3.470536] Unable to handle kernel NULL pointer dereference at virtual addre
ss 00000020
[ 3.470566] pgd = fffffe0001c80000
[ 3.478160] [00000020] *pgd=0000000090030003, *pud=0000000090030003, *pmd=000
0000090030003, *pte=006000000b000707
[ 3.491439] Internal error: Oops: 96000006 [#1] PREEMPT SMP
…

The above “Oops” was ending with the kernel panic, of course.

My questions now:
Q1. Is the kernel source 15.09, pointed afresh by “ldts-jro”, fixing this bug?
Q2. Or, maybe I need just to use the “4.2.0-linaro-lt-qcom” kernel version, which was successful
with its 4k pages kernel?
If yes, then where can I grab the related kernel sources?

Thanks!

 -zenon
#15

An update with a Success report:

When I have used the 15.09 kernel source, it was generating the 4.2 version of a kernel,
which did not cause any panic.
I have generated a kernel version with 64k pages, along with all modules.

Then, I have installed the modules at “/lib/modules/4.2.0” and used the “fastboot”
to use the new generated “boot.img”.
It booted without any panic.

Well, there were problems with some modules (apparently), as the graphics interface
was getting killed by the “oom” killer.
But the network communication remained intact (so I could connect to the board with
“ssh linaro@its-ip-address”).

I have tried to run some applications, like the Google’s “d8” javascript shell, but
in the most circumstances it had been killed as well by “out of memory” killer.

I have verified the /proc/meminfo and got
MemTotal: 929216 kB
MemFree: 547328 kB
MemAvailable: 571328 kB

The board has just 1GB of LPDDR3 memory, so one cannot increase the “MemTotal” by SW tricks.

Oh, well …

Anyway, MANY MANY thanks for great support by both “ldts-jro” and initial hints from “ndec”.
I have learned a lot while experimenting.
The final conclusion: The 4.3.0 kernel version is buggy.
The 4.2.0 kernel version seems to be working OK.

Btw, one maybe should add in the chapter about the kernel compilation, that the LKM generation
is likely a MUST in the case of a new kernel.
The statement “Building the kernel modules (optional, only if you need them)” is highly misleading.

Thanks again,

-zenon