networking issue on a banana pi [SOLVED]

[jyoung]

I tried using this boot.cmd

Code: Select all

setenv bootargs console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootwait panic=10
fatload mmc 0 40008000 uImage
bootm 40008000  

I've omitted the initrd, since I don't have one, and the line with sun7i-a20-bananapi.dtb.uimg, since I was unsure about that. When I try to boot, it seems to get a bit further, but then reports

Code: Select all

EHCI failed to shut down host controller.
Loading Kernel Image
FDT and ATAGS support not compiled in
resetting...

The FDT message seems related to sun7i-a20-bananapi.dtb.uimg, but I'm not sure about the ATAGS. In the uboot .config file I find

Code: Select all

# CONFIG_SUPPORT_PASSING_ATAGS is not set

So, perhaps rebuilding uboot with this enabled might solve this problem. I'm still looking for a way to generate sun7i-a20-bananapi.dtb.uimg. I think you're right, mkimage is probably the way to do it, but when I list all the image types that mkimage can generate, there isn't a clear fit

Code: Select all

mkimage -T list

Invalid image type, supported are:
	aisimage         Davinci AIS image
	atmelimage       ATMEL ROM-Boot Image
	copro            Coprocessor Image
	filesystem       Filesystem Image
	firmware         Firmware
	firmware_ivt     Firmware with HABv4 IVT
	flat_dt          Flat Device Tree
	fpga             FPGA Image
	gpimage          TI Keystone SPL Image
	imx8image        NXP i.MX8 Boot Image
	imx8mimage       NXP i.MX8M Boot Image
	imximage         Freescale i.MX Boot Image
	invalid          Invalid Image
	kernel           Kernel Image
	kernel_noload    Kernel Image (no loading done)
	kwbimage         Kirkwood Boot Image
	lpc32xximage     LPC32XX Boot Image
	mtk_image        MediaTek BootROM loadable Image
	multi            Multi-File Image
	mxsimage         Freescale MXS Boot Image
	omapimage        TI OMAP SPL With GP CH
	pblimage         Freescale PBL Boot Image
	pmmc             TI Power Management Micro-Controller Firmware
	ramdisk          RAMDisk Image
	rkimage          Rockchip Boot Image
	rksd             Rockchip SD Boot Image
	rkspi            Rockchip SPI Boot Image
	script           Script
	socfpgaimage     Altera SoCFPGA CV/AV preloader
	socfpgaimage_v1  Altera SoCFPGA A10 preloader
	standalone       Standalone Program
	stm32image       STMicroelectronics STM32 Image
	sunxi_egon       Allwinner eGON Boot Image
	sunxi_toc0       Allwinner TOC0 Boot Image
	tee              Trusted Execution Environment Image
	ublimage         Davinci UBL image
	vybridimage      Vybrid Boot Image
	x86_setup        x86 setup.bin
	zynqimage        Xilinx Zynq Boot Image
	zynqmpbif        Xilinx ZynqMP Boot Image (bif)
	zynqmpimage      Xilinx ZynqMP Boot Image

[jyoung]

Interesting, I just recompiled uboot with CONFIG_SUPPORT_PASSING_ATAGS=y, and now it's able to get as far as "Starting kernel ...". But, it hangs there.

[jyoung]

I just tried booting with the new uboot but with the old (working) kernel. The result is the same, "Staring kernel..." and then hangs. I think that this suggests that the issue is with uboot or the uboot configuration, and not with the kernel.

[jyoung]

I found a file called u-boot-dtb.img in the github folder, which sounds like it might be what we need. I tried again with a boot.cmd file that looks like

Code: Select all

setenv bootargs console=ttyS0,115200 console=tty2 root=/dev/mmcblk0p2 rootwait panic=10
fatload mmc 0 40008000 uImage
fatload mmc 0 4a000000 u-boot-dtb.img
bootm 40008000  - 4a000000

Note the - for the address of the initrd. The example from a few posts back had that line as

Code: Select all

bootm ${kernel_addr_r} [$ramdisk_addr_r}|-] [${fdt_addr_r}]

I didn't notice this before, but it looks like the address of the initrd is optional, but the fdt file is not. After generating a new boot.scr file, I now get a message

Code: Select all

ERROR: uImage is not a fdt - must RESET the board to recover.
EHCI failed to shut down host controller.
Loading Kernel Image
Staring kernel ...

Okay, it looks like u-boot-dtb.img may not have been the right choice. But the message also calls it a uImage, weirdly implying that it's trying to load it as a kernel.

[pingtoo]

Found a better source https://linux-sunxi.org/Manual_build_howto

Summary of what I learn from above and I think it will apply for your case, (this is about mainline Linux, no info for U-Boot)

• Command to use for building mainline linux for Banana Pi (sunxi-a20)
  
• kernel manual config:
  • make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
• Kernel:
  • ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make -j4 zImage
• Modules:
  • ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make -j4 modules
    ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make modules_install
• DTB:
  • ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make -j4 dtbs
    in linux build dir/arch/arm/boot/dts/
    filename: sun7i-a20-bananapi.dtb
• boot.scr
  • mkimage -C none -A arm -T script -d boot.cmd boot.scr
• boot.cmd for mainline kernel

  Code: Select all

  setenv bootargs console=ttyS0,115200n8 console=tty1 root=/dev/mmcblk0p2 rootwait panic=10
  fatload mmc 0:1 0x49000000 sun7i-a20-bananapi.dtb
  fatload mmc 0:1 0x46000000 zImage
  bootz 0x46000000 - 0x49000000

• extlinux.conf

  Code: Select all

  TIMEOUT 3
  DEFAULT default
  MENU TITLE Boot menu
  
  LABEL default
  	MENU LABEL Default
          LINUX /zImage
          FDT /sun7i-a20-bananapi.dtb
          APPEND root=/dev/mmcblk0p2 rootwait console=ttyS0,115200n8 console=tty1 panic=10
  
  LABEL exit (leave extlinux(pxe) mode and drop to use boot.scr
  	MENU LABEL Local boot script (boot.scr)
          LOCALBOOT 1

• You can drop the "ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-" from command line if you are building inside BananaPi.
• root=dev/mmcblk0p2, if your rootfs is somewhere else please change accordingly.
• I have not yet figure out what is the error "EHCI failed to shut down host controller."
• .dtb file can be placed directly, it have same header as uImage so it can be use where it is expected.

[jyoung]

Okay, what about the load address for sun7i-a20-bananapi-m1-plus.dtb? In this example, it's different from the address for uImage. Running

Code: Select all

mkimage -l sun7i-a20-bananapi-m1-plus.dtb

just returns

Code: Select all

Image contains unit addresses @, this will break signing
FIT description: unavailable
Created:         unavailable
Can't find images parent node '/images' (FDT_ERR_NOTFOUND)

It's a binary, so opening it in a text editor doesn't reveal the address. As a guess, I tried 0x49000000. Here's the boot.cmd file

Code: Select all

setenv bootargs console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootwait panic=10
fatload mmc 0:1 0x49000000 sun7i-a20-bananapi-m1-plus.dtb
fatload mmc 0:1 0x40008000 uImage
bootm 0x40008000 - 0x49000000

Now, the boot sequence seems to go a bit further. I get

Code: Select all

## Flattened Device Tree blot at 49000000
Booting using the fdt blob at 0x49000000
EHCI failed to shut down host controller.
Loading Kernel Image
Loading Device Tree to 49ff6000, end 49fff684 ... OK
Starting kernel ....

And then it hangs.

[jyoung]

Wait, that setup was still using the old (working) kernel. I just tried swapping in the new kernel, and it booted! I am logged in now, and uname -a confirms that it's running the new kernel.

Do we know if 0x49000000 is universally correct for any *.dtb, or was it just a lucky guess that because it worked for sun7i-a20-bananapi.dtb it would also work for sun7i-a20-bananapi-m1-plus.dtb?

Also, I'm not sure what the forum etiquette is, but I think we should change the thread's title. The bug that originally prompted it was a failure to connect to the network (which is now working!), but the solution was almost entirely to do with the boot loader.

[pingtoo]

Why sun7i-a20-bananapi-m1-plus.dtb?

I think it should be sun7i-a20-bananapi.dtb.

Do you also have the usb-uart hookup? Some message will only display on serial port, so may be there are more there.

try add setenv bootm_boot_mode=sec into boot.cmd or rebuild u-boot with CONFIG_ARMV7_LPAE=n (search for "Use LPAE page table format" in menuconfig)

[pingtoo]

OK, since it is working you can ignore my previous post, they are target for old sunxi kernel.


If you are satisfy current situation, just modify title and add [solved] to title,

[pingtoo]

[quote="jyoung"]Do we know if 0x49000000 is universally correct for any *.dtb, or was it just a lucky guess that because it worked for sun7i-a20-bananapi.dtb it would also work for sun7i-a20-bananapi-m1-plus.dtb?]/quote]

0x49000000 I guest it just an address far enough so the kernel will not overlap especially for zImage,

[jyoung]

I have the USB UART adapter, but I haven't tried it out yet since the new uboot was able to display. Is there a good wiki or tutorial on how to use it? From what I'm seeing, the procedure would be to connect the adapter to the appropriate pins (excluding the 5V pin), start minicom on my desktop, and then boot up the BPI, yes?

[pingtoo]

I have the USB UART adapter, but I haven't tried it out yet since the new uboot was able to display. Is there a good wiki or tutorial on how to use it? From what I'm seeing, the procedure would be to connect the adapter to the appropriate pins (excluding the 5V pin), start minicom on my desktop, and then boot up the BPI, yes?

You can follow https://bananapi.gitbook.io/bpi-m1/en/b ... tinterface

[jyoung]

If I'm reading this tutorial right minicom has to be started on the BPI, yes? But, we're looking for messages at boot time, correct? Would the boot loader broadcast through the serial port before minicom is started? Sorry for the confusion, I've never used these tools before.

Also, as of now there are no longer any signs that anything is wrong with the system. It is kind of weird that the old kernel won't load with the new boot loader. On the other hand, it is really old, and I'm not sure that we need to trouble shoot it.

[NeddySeagoon]

jyoung,

If the kernel has serial port support, you need to tell it to put the console on whatever it calls the serial port.
It can go onto the normal HDMI console too.

I use

Code: Select all

console=tty0 console=ttyS0,115200n8 console=ttyAMA0,115200n8

on the kernel command line.
console=tty0 is the normal console.
console=ttyS0,115200n8 console=ttyAMA0,115200n8 is the serial port to use, here there are two as the nane changes from ttyS0 to ttyAMA0. the 115200n8 is the serial part setup.

That much gets you kernel messages on the serial port but not a login prompt.
For a login prompt /etc/inittab needs

Code: Select all

# SERIAL CONSOLES
s0:12345:respawn:/sbin/agetty -L 115200 ttyAMA0 vt100

see the comments in the file.

115200n8 in 115200 baud. No stop bit and 8 data bits.
minicom needs to be set up to match, or you wont lie what you see, if you see anything :)

Play with minicom and the USB/Serial port before you try to talk to anything else.
Connect The Tx and RX wires on the adaptor together. This is called a loopback test.

What you type into minicom will go out of the Tx wire and back in the RX wire and appear in minicom as an 'echo'
If you get two copies, you probably have 'local echo' in minicom set to on. Turn that off.
The BPI will echo everything you send it when all is well.

If you separate the Tx and Rx wires your typing will not be echoed.

[pingtoo]

If I'm reading this tutorial right minicom has to be started on the BPI, yes? But, we're looking for messages at boot time, correct? Would the boot loader broadcast through the serial port before minicom is started? Sorry for the confusion, I've never used these tools before.

Also, as of now there are no longer any signs that anything is wrong with the system. It is kind of weird that the old kernel won't load with the new boot loader. On the other hand, it is really old, and I'm not sure that we need to trouble shoot it.

minicom is to run on you other computer where usb end is connected, not on BPI

if you really want to use the old kernel, you can see the other post that I asked you to put in the bootm_boot_mode=sec in boot.cmd.

I think by default serial port does not have tty listen for incoming, so once past u-boot and kernel boot up into multi-user mode, you will find that minicom stop working. So please follow Neddy advise setup /etc/inittab to have agetty listen on the serial device. As for the kernel command line, it is optional, if you don't setup as suggested, then you will not see linux kernel messages on serial console until the agetty running.

[jyoung]

Hi Folks,

Sorry I dropped this thread. I got busy with work, and I've been meaning to revisit. Since it's basically dead, I'll post a summary here for future readers and mark it as SOLVED. pingtoo, I'm extremely grateful for all your dedicated help!

These are the steps that succeeded for this project:

clone https://github.com/andy-shev/u-boot

run make

copy ./arch/arm/dts/sun7i-a20-bananapi-m1-plus.dtb to the boot partition

write the binary to the u-boot-sunxi-with-spl.bin bootable drive

Code: Select all

dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1024 seek=8

sun7i-a20-bananapi-m1-plus.dtb to the boot partition

on the boot partition, write a boot.cmd configuration file, here's mine

Code: Select all

setenv bootargs console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootwait panic=10
fatload mmc 0:1 0x49000000 sun7i-a20-bananapi-m1-plus.dtb
fatload mmc 0:1 0x40008000 uImage
bootm 0x40008000 - 0x49000000

generate a bootmkimage -C none -A arm -T script -d boot.cmd boot.scr