Boot fails with self-build u-boot


(Frank W.) #2

Your uboot is not getting loaded…all messages are from preloader.

Here you find instructions how to manually install uboot: http://www.fw-web.de/dokuwiki/doku.php?id=en/bpi-r2/uboot#update_uboot

btw. Where do you call make uboot/pack? If it is not on bpi-r you need crosscompile…which version of uboot do you use? Official version have build.sh


#3

OK, this was also my guess.

On a Debian x86_64 machine

From the output I see that it is cross compiling. $ ./build.sh NOTICE: new build.sh default select BPI-R2-720P and pack all boards supported boards: BPI-R2-720P

BPI-R2-720P configured. Now run `make`
This tool support following building mode(s):
--------------------------------------------------------------------------------
        1. Build all, uboot and kernel and pack to download images.
        2. Build uboot only.
        3. Build kernel only.
        4. kernel configure.
        5. Pack the builds to target download image, this step must execute after u-boot,
           kernel and rootfs build out
        6. update files for SD
        7. Clean all build.
--------------------------------------------------------------------------------
Please choose a mode(1-7): 1

 Now building...

make -C u-boot-mt mt7623_evb_config CROSS_COMPILE=arm-linux-gnueabihf- -j8
make[1]: Entering directory '/home/hashlog/Documents/BPI-R2-bsp/u-boot-mt'
Configuring for mt7623_evb board...
make[1]: Leaving directory '/home/hashlog/Documents/BPI-R2-bsp/u-boot-mt'

I’m using the repository of BPI-SINOVOIP.

commit d94f55022a9192cb181d380b1a6699949a36f30c
Merge: 363f3b1 cb2971d
Author: garywangcn <15818651704@163.com>
Date:   Thu Mar 29 08:13:39 2018 +0800

    Merge pull request #29 from JackZengBpi/master

    Save uboot envs to where it boots from

I tried now again to build u-boot with the build.sh script, but it leads me to the same result:

[PART] load "UBOOT" from 0x0000000000050000 (dev) to 0x81E00000 (mem) [SUCCESS]
[PART] load speed: 6232KB/s, 300000 bytes, 47ms
[BT_SD_PG] device info 0x8590 0x8A00 0xCB01 0x102
0:dram_rank_size:80000000
[PLFM] md_type[0] = 255
[PLFM] md_type[1] = 255

[PLFM] boot reason: 0
[PLFM] boot mode: 0
[PLFM] META COM0: 0
[PLFM] <0xFFB7CC10>: 0x0
[PLFM] boot time: 2922ms
[PLFM] DDR reserve mode: enable = 0, success = 0

[BLDR] jump to 0x81E00000
[BLDR] <0x81E00000>=0xEA00000F
[BLDR] <0x81E00004>=0xE59FF014

(Frank W.) #4

I don’t know,if this is the right image:

gunzip --stdout out/bpi-r2/100MBBPI-R2-720P-2k.img.gz | sudo dd of=/dev/sdc bs=1k seek=2 count=1022

maybe it is full sd-image and not only the uboot…in that case uboot is already moved to 2k-offset and you copy from wrong position (seek is for output => do not overwrite existing partitiontable on sd,but start reading from offset 0 in “if”)


#5

Even if I select Build all, uboot and kernel and pack to download images there is only 1 file in the ./out directory:

$ find ./out -type f
out/bpi-r2/100MB/BPI-R2-720P-2k.img.gz
$ ls -l out/bpi-r2/100MB/BPI-R2-720P-2k.img.gz
-rw-r--r-- 1 user user 161555 Apr 21 07:29 ./out/bpi-r2/100MB/BPI-R2-720P-2k.img.gz

The uncompressed image is exactly 1022k long.

So I tried to not seek to 2k in the beginning, but then there is not even output from the preloader. I will try everything again with your BPI-R2-4.4 repository, maybe then it is working.


(Frank W.) #6

please don’t look in out-dir…use the file from sd-folder. My repo does not differ in this part


#7

Oh, sorry my bad. I recompiled everything and got the following files

$ ls -l ./SD/
drwxr-xr-x 2 user user     4096 Apr 21 07:22 100MB
-rw-r--r-- 1 user user 70980997 Apr 21 07:22 4.4.70-BPI-R2-Kernel-net.tgz
-rw-r--r-- 1 user user 52909913 Apr 21 07:22 4.4.70-BPI-R2-Kernel.tgz
-rw-r--r-- 1 user user   160090 Apr 21 07:22 BOOTLOADER-bpi-r2.tgz
drwxr-xr-x 3 user user     4096 Apr 21 07:22 BPI-BOOT
-rw-r--r-- 1 user user  8335439 Apr 21 07:22 BPI-BOOT-bpi-r2.tgz
drwxr-xr-x 4 user user     4096 Apr 21 07:22 BPI-ROOT

I suspect that the u-boot image is contained in the BOOTLOADER-bpi-r2.tgz file.

$ tar --list -f SD/BOOTLOADER-bpi-r2.tgz
usr/lib/u-boot/bananapi/
usr/lib/u-boot/bananapi/bpi-r2/
usr/lib/u-boot/bananapi/bpi-r2/BPI-R2-720P-2k.img.gz

So I then used that file and followed the commands from the wiki.

$ tar -C ./SD/ -xaf ./SD/BOOTLOADER-bpi-r2.tgz
$ gunzip --stdout ./SD/usr/lib/u-boot/bananapi/bpi-r2/BPI-R2-720P-2k.img.gz | dd bs=2k seek=2 count=1022 of=/dev/disk3

Unfortunately, same result as before


(Frank W.) #8

Bootloader-tar is right…can you test please use gunzip without --stdout?

Uboot is built without errors?


#9

I attached the complete output of the build process. There is not a single warning nor error.

$ ls -l ./SD/
drwxr-xr-x 2 user user     4096 Apr 22 09:27 100MB
-rw-r--r-- 1 user user 70972376 Apr 22 09:27 4.4.70-BPI-R2-Kernel-net.tgz
-rw-r--r-- 1 user user 52914535 Apr 22 09:27 4.4.70-BPI-R2-Kernel.tgz
-rw-r--r-- 1 user user   160285 Apr 22 09:27 BOOTLOADER-bpi-r2.tgz
drwxr-xr-x 3 user user     4096 Apr 22 09:27 BPI-BOOT
-rw-r--r-- 1 user user  8335424 Apr 22 09:27 BPI-BOOT-bpi-r2.tgz
drwxr-xr-x 4 user user     4096 Apr 22 09:27 BPI-ROOT

$ tar -C ./SD/ -xzvf ./SD/BOOTLOADER-bpi-r2.tgz
usr/lib/u-boot/bananapi/
usr/lib/u-boot/bananapi/bpi-r2/
usr/lib/u-boot/bananapi/bpi-r2/BPI-R2-720P-2k.img.gz

$ gunzip ./SD/usr/lib/u-boot/bananapi/bpi-r2/BPI-R2-720P-2k.img.gz
./SD/usr/lib/u-boot/bananapi/bpi-r2/BPI-R2-720P-2k.img.gz:       84.6% -- replaced with ./SD/usr/lib/u-boot/bananapi/bpi-r2/BPI-R2-720P-2k.img

$ ls -l ./SD/usr/lib/u-boot/bananapi/bpi-r2/
-rw-r--r-- 1 hashlog hashlog 1046528 Apr 22 09:27 BPI-R2-720P-2k.img

$ dd if=./SD/usr/lib/u-boot/bananapi/bpi-r2/BPI-R2-720P-2k.img bs=1k seek=2 count=1022 of=/dev/disk3

Unfortunately, same result as before :frowning:

output.txt.gz (53,0 KB)


(Frank W.) #10

Is this really the right device? Devicename looks strange.

You got no warnings because the code is already built (to o-files) and is only linked to target-binaries. that means there are no errors before…you can make make clean to see warnings again (full compile) but this does not solve your problem…have you tried unmodified uboot?


#11

Yes. I’m using dd from a macbook, which is assigning /dev/disk# as identifier.

Anyway, cleaned everything, rebuild everything and attached the output. Now there are warnings, but no error. Still no u-boot after copying it to the sd card.

What do you mean with “unmodified uboot”? The one included in the ubuntu-image is working. I did not modify anything in u-boot repository from SINOVOIP yet. I just compiled the image and copied it to the sd card.

In the meantime I downloaded the bootloader from you google drive and copied it to the sd card. With your bootloader there is no problem. Did you cross-compile or compile it natively on the bpi-r2? Am I maybe using the wrong cross-compiler arm-linux-gnueabihf-gcc?

log.txt.gz (56,8 KB)


(Frank W.) #12

I used crosscompiler gnueabihf like mentioned in the documentations. Maybe anything in repo has changed…i remember a change of any start-address,but think it was lede-bootloader…

Have you installed u-boot-tools (mkimage)? Normally it will result in an error if not installed

@garywang have you an idea?


(gary) #13

We can user BPI-Tool or RAW command in uboot to update uboot itself.


(Frank W.) #14

Is it possible that you have no preloader on your sdcard (only uboot) and on emmc only preloader (no uboot)?

Then system will look on sdcard for preloader,does not find it,looks on emmc load preloader,but there is no uboot…


#15

Yes, u-boot-tools are installed

Wouldn’t that write u-boot to the integrated emmc? This is not what I’m trying to achieve. I want to build u-boot from the repository on my own and load it to the SD card. Then boot the bananpi from the self-compiled u-boot.

I didn’t try to write anything to the emmc yet. So I’m pretty sure it should be empty. Just to really make sure I zeroed (dd if=/dev/zero ..) the sd card and turned on the bpi-r2. Nothing happened. I think the emmc is empty.


#16

@frank-w I see in your post “How to extend the uboot menu” that apparently you can compile and use your own uboot. Could you please post every step (from cloning the git repository, until insterting the SD card into the bpi-r2) here?


(Frank W.) #17

basicly there are no more steps as described in my wiki

  • git clone https://github.com/frank-w/BPI-R2-4.4.git
  • cd BPI-R2-4.4
  • ./build.sh => 1
  • gunzip SD/100MB/BPI-R2-720P-2k.img.gz
  • sudo dd if=SD/100MB/BPI-R2-720P-2k.img of=/dev/sdb bs=1k seek=2 count=1022
  • sync + umount automounted partitions
  • remove card and insert in r2
  • boot r2

i looked into how the BPI-R2-720P-2k.img was created…preloader is included on sdcard preloader (preloader_iotg7623Np1_emmc.bin) is at 0x800 and uboot (uboot.bin) on 0x50000 (you can dd an 1MB-image from your card and look with bless or similar hexeditor)

i don’t know if there must be an partition defined…if you use an empty card…you can use my partition-scheme to test it out: http://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:storage#manual_copy_of_os


#18

Since it was still not working I changed my plans. I took my old clamshell pc, installed linux, and did all your steps and it worked :ok_man: I just hadded to add the section from 0-2k from the ubuntu image, in order to be able to boot. I guess there is some kind of preloader on it to initialize the CPU and the memory.

dd if=ubuntu.img bs=1k count=2 of=/dev/sdb

I attached the part that I used for the sd card (0-2k). Do you have any idea what this is?

I still have no idea what went wrong in my previous tries. I’m still investigating and if I find something I will report it.

header_0-2k.img (2 KB)


(Frank W.) #19

maybe the first 512kB are needed to boot see https://en.wikipedia.org/wiki/Master_boot_record

the first 10 bytes containing a magic string “SDMMC_BOOT” followed by 10Bytes (00 00 01 00 00 00 00 02 00 00) i don’t know (maybe position of preloader/uboot to jump to) followed by many FF (fill-bytes??). On byte 440 (1b8h) there is the “32-bit disk signature” followed by 0000h (for rw-state). After that Partition-Table starts (MBR 4x16byte) followed by MBR end-marker 55AAh

so i assume that it is enough copy the first 20 bytes to get SDcard to boot (partitiontable should not be involved in boot-process before uboot).

also some infos about that area of the sd/emmc: Boot process\FreeBSD porting

i have wrote down the steps after creating bootable emmc with only these steps, but emmc has bootloader in separate partition (boot0-block) so maybe in SD-Card there is more needed. in my image i used original image with erased partitions.

btw. preloader is before uboot >=2k


#20

Unfortunately it is not. There are 32 bytes after the MBR (starting at 0x200) that are required for booting. Let’s refer to it as BRLYT

$ dd if=2017-09-04-ubuntu-16.04-mate-desktop-bpi-r2-sd-emmc-v1.2.0.img bs=1 skip=512 count=32 | xxd
32+0 records in
32+0 records out
32 bytes copied, 0.000135552 s, 236 kB/s
00000000: 4252 4c59 5400 0000 0100 0000 0008 0000  BRLYT...........
00000010: 0008 0000 4242 4242 0800 0100 0008 0000  ....BBBB........
00000020: 0008 0000 0100 0000 0000 0000 0000 0000  ................

Putting only those 3 parts (SDMMC_BOOT, BRLYT, uBoot) to the SD card is sufficient to make it boot. There is no need for a partition table.

# copy SDMMC_BOOT
$ dd of=/dev/sdb bs=1 count=20 if=2017-09-04-ubuntu-16.04-mate-desktop-bpi-r2-sd-emmc-v1.2.0.img 
# copy BRLYT
$ dd of=/dev/sdb bs=1 seek=512 skip=512 count=48 if=2017-09-04-ubuntu-16.04-mate-desktop-bpi-r2-sd-emmc-v1.2.0.img 
# copy uboot
$ dd of=/dev/sdb bs=1k seek=2 count=1022 if=./SD/100MB/BPI-R2-720P-2k.img

Indeed those are fill-bytes. I replaced them with 0x00 and it’s still loading uboot.

I can also confirm, that the partition table is not part of the boot process. My SD has no partition table on (i zeroed everythin) and it is still loading uboot.

Questions that are still open for me:

  1. What do the bytes from 0-20 (SDMMC) do?
  2. What is the BRLYT part?
  3. Where are the addresses stored to jump from the preloader (SDMMC) to BRLYT and from BRLYT to 0x800 (uBoot)?

(Frank W.) #21

Seems that the 10 bytes after sdmmc_boot pointing to brlyt 0x200 and brlyt to preloader at 0x800+2k (also 0x800). Preloader loads uboot at 0x50000+2k