Update both u-boot and Linux kernel

Hello, Having received BPi-W2 I tried the images with the legacy [email protected]:~# cat /proc/version Linux version 4.9.119-BPI-W2-Kernel ([email protected]) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #4 SMP PREEMPT Mon Apr 29 15:13:32 CST 2019

Very quickly I understood, that ethernet ports are not built properly in the kernel and they are not functional. I was able setting up the docker image https://hub.docker.com/r/sinovoip/bpi-build-linux-4.4/ and build the kernel from sources [email protected]:/Source# git clone https://github.com/BPI-SINOVOIP/BPI-W2-bsp.git

I was stuck on the final stage of [email protected]:/Source/BPI-W2-bsp# cat README.md How to update both u-boot and Linux kernel

I plugged into the host USB my SD Card with the Debian image for W2 in order to update u-boot and Linux kernel. The SD Card appears on the host system as : STORAGE_DEVICE sdb disk 60G ├─sdb1 part vfat 256M BPI-BOOT └─sdb2 part ext4 6.8G BPI-ROOT

Accessing the docker “optimistic_nash” instance with --privileged=true : [email protected]:~# docker exec -it --privileged=true optimistic_nash /bin/bash executes without errors.

But the bpi-update fails from within the Docker container instance : [email protected]:/Source/BPI-W2-bsp/SD# bpi-update -c bpi-w2.conf -d /dev/sdb CONFFILE=bpi-w2.conf Wait for download bpi-w2.conf … https://github.com/BPI-SINOVOIP/BPI-files/raw/master/others/for-bpi-tools/conf/board/bpi-w2.conf OK!!\n DEVICE=/dev/sdb BPIFILE=/root/.bpi-update.lst Wait for download index file … OK!!\n lsblk: /dev/sdb: not a block device INFO: /dev/sdb NOT THE removable device!! EXIT!!

I think, that Docker container is unable getting an access to mount /dev/sdb. Indeed : [email protected]:/# mount /dev/sdb2 /mnt/sdb2/
mount: permission denied

I am running out the options how to fix it. What is the right solution except for sending the BPi-W2 back?

1 Like

access to external SD Card has finally been resolved by creating an identical container : [email protected]:~# docker commit optimistic_nash mybpi-buildimage and then running it with --privileged : [email protected]:~# docker run -it --privileged mybpi-buildimage bash

Now the problem comes after building the kernel from the sources. The build runs successfully : BPI-W2-bsp# ./build.sh Please choose a mode(1-7): 1 Now building… Build success!

The SD directory contains necessary files : BPI-W2-bsp/SD# ls -al bpi-w2/ 100MB/ BPI-BOOT/ linux-headers-4.9.119-BPI-W2-Kernel.tgz 4.9.119-BPI-W2-Kernel.tgz BPI-BOOT-bpi-w2.tgz

I plug my SD Card with the previously written image to it, which I want to update with the newly built kernel. The card is well identified by the system as /dev/sdb

Anyway, the following command doesn’t update the kernel on the target SD Card with the image : BPI-W2-bsp/SD# bpi-update -c bpi-w2.conf -d /dev/sdb

What am I missing? Alternatively, what is a manual kernel update procedure on the the target image?

Interresting journey. It only seems that you are lost, infact you are learning an awful lot :slight_smile:

Make another journey where you build yourself an image based upon a known good recipe. It will learn you how good your build tool chain is.

After having build yourself a working image of classic version, go build a (b)leading edge version.

What follows are some formatting tests, using backtick ` and triple backtick.

This string has single backtick on each side.

Now text

BPI-W2-bsp/SD# ls -al bpi-w2/

between triple backticks ( ``` )

SINOVOIP doesn’t make the task easier with poor basic tasks documentation. Obscure bpi-update bpi-bootsel may be helpful for the well tested systems, but would rather become an obstacle when deploying new systems, which the BPi-W2 is. Probably a more detailed custom kernel and u-boot deployment document is necessary.

I’ve tried several kernel branches for now: mainline, next, legacy BPI-SINOVOIP. In the absence of Realtek’s support, accessibility to the board features is very poor. Even basic ethernet NIC’s are not operational, even with the legacy BPI-SINOVOIP, which is supposed meeting this basic task. I do not even mention the video Mali T820 support, which is probably far from being thought of.

I think sending the card back to supplier, as it can not be used the goal it is sold for. Even worse, I can hardly imagine any application it can be used for in the current state.

1 Like

Yes, we can spend our money only once. Hopefully reports @y52 about a refund.

But I hope more on “rebuild works for me, why not for you?” from @sinovoip