Jump to content

Armada: U-Boot problem with newly compiled image


Recommended Posts

I'm just trying to create a new image for the ClearFog Pro, b/c I need some special kernel modules built-in. Compiling kernel 4.4.4 with my settings works great, but I have problems to boot the image.

 

This is my build command:

sudo ./compile.sh BRANCH=next BOARD=armada KERNEL_ONLY=no BUILD_DESKTOP=no PROGRESS_DISPLAY=plain RELEASE=jessie

But u-boot complains about starting with the following message. Even the u-boot `help` command doesn't work.

...
Board configuration detected:Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x00     |
| egiga1 |   SGMII   |   In-Band    |
| egiga2 |   SGMII   |   In-Band    |
egiga0 [PRIME], egiga1, egiga2
Hit any key to stop autoboot:  0
Unknown command 'ext2load' - try 'help'
Unknown command 'source' - try 'help'
Unknown command 'tftpboot' - try 'help'
Unknown command 'tftpboot' - try 'help'
Unknown command 'setenv' - try 'help'
Unknown command 'bootz' - try 'help'
Marvell>>

When I'm using the latest available download image `Armbian_5.00_Armada_Debian_jessie_4.4.1.zip` then u-boot works and the image is booting well.

 

Same problem occurs when I'm creating the kernel and u-boot packages only and install the u-boot package within the running `Armbian_5.00_Armada_Debian_jessie_4.4.1.zip` image:

dpkg -i linux-u-boot-next-armada_5.05_armhf.deb
reboot

Any help or pointers greatly appreciated.

Link to comment
Share on other sites

Hello, I don't want to hijack this thread but yesterday I've build two images, that did not boot. Instead the server logged some tftp requests. It was the first time I used EXTENDED_DEBOOTSTRAP="yes".

 

The stuff that belongs to /boot was in /boot/boot. After copying the content from /boot/boot to /boot and setting the links, the images work as expected.

 

Quintus23M may have the same problem, see: "Board configuration detected:Net:" in his first post.

 

My configuration:

BUILD_DESKTOP="no"
BOARD="bananapim2" ### 2nd board is a BPi-M1
BRANCH="next"
RELEASE="jessie"
PROGRESS_DISPLAY="plain"
PROGRESS_LOG_TO_FILE="yes"
EXTENDED_DEBOOTSTRAP="yes"

Configuration is similar to Quintus23M: Ubuntu 14.04, Virtual Box, OS X

 

Server log:

tftpd[1359]: tftpd: trying to get file: AC100202.img
tftpd[1357]: tftpd: serving file from /srv/tftp
dhcpd[955]: DHCPDISCOVER from xx:yy:...
tftpd[1359]: tftpd: trying to get file: boot.scr.uimg
tftpd[1359]: tftpd: serving file from /srv/tufts

mounted image:

$: ls boot/
boot
$: ls boot/boot/
bin	  boot.scr	      script.bin	      zImage
boot.bmp  config-4.4.4-sunxi  System.map-4.4.4-sunxi
boot.cmd  dtb		      vmlinuz-4.4.4-sunxi
Link to comment
Share on other sites

Hello, I don't want to hijack this thread but yesterday I've build two images, that did not boot. Instead the server logged some tftp requests. It was the first time I used EXTENDED_DEBOOTSTRAP="yes".

 

The stuff that belongs to /boot was in /boot/boot. After copying the content from /boot/boot to /boot and setting the links, the images work as expected.

Thanks for the report, this will be fixed shortly

Link to comment
Share on other sites

This problem only occurs when I'm using my 2014 MBP (with VirtualBox). On an Window 7 PC with VMware Workstation 10 it produces a correct U-Boot package with exactly the same Vagrantfile and provision script...

So, I do have a workaround now.

Link to comment
Share on other sites

This problem only occurs when I'm using my 2014 MBP (with VirtualBox). On an Window 7 PC with VMware Workstation 10 it produces a correct U-Boot package with exactly the same Vagrantfile and provision script...

 

So, I do have a workaround now.

 

That is odd. Virtualbox has issues ... actually hard to say where the issue is. I experienced once corruption similar to this but (host too) reboot solved it.

Link to comment
Share on other sites

Just checked it with using VMware Fusion 7.1.3 on my MBP, same problem as with VirtualBox 5.0.14. U-Boot binary seems to be corrupt. Maybe this Mac is quite too fast...

U-boot code is somehow fragile. We needed to patch it for first u-boot build and if you are using different / newer compiler ... you need to patch it again. I haven't dig into more. I hope it will be possible to merge upstream to latest mainline u-boot.

Link to comment
Share on other sites

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

Important Information

Terms of Use - Privacy Policy - Guidelines