[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian on Synology Armada 370/XP NAS boxes



On 17/05/14 10:52, Ian Campbell wrote:
On Sat, 2014-05-17 at 00:17 +0200, Alexander Pohl wrote:
With the flash-kernel method there should be no need to reflash grub,
unless the factory one is horribly broken somehow.
I think that is the case here (factory image is horribly broken) as I am
not able to get the kernel to boot (see my other post).
It would be very unusual for a u-boot to be so broken that it couldn't
bootm with an appended DTB (assuming it boots the factory kernel OK).

Things to check:
       * Appending the correct DTB for the platform?
       * Using the correct load address to mkimage?
       * Loading the resulting uImage at a good address?
       * Setting bootargs correctly? (in particular console=)

The correct load address for mkimage can be obtained by grabbing the
factory kernel and running mkimage -l on it. The rest should be easy to
figure out by looking at the factory environment with printenv (feel
free to post it if you want advice).


- I've appended armada-370-mirabox.dtb to linux-image-3.13-1-armmp-lpae from jessie. I don't know if that is correct or not.
- mkimage output, load address and entry point same as stock image:

Stock image:
    Image Name:   Linux-3.2.40
    Created:      Thu Mar  6 07:18:20 2014
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2100800 Bytes = 2051.56 kB = 2.00 MB
    Load Address: 00008000
    Entry Point:  00008000

New image with appended dtb:
    Image Name:   vmlinuz-3.13-1-armmp-lpae
    Created:      Fri May 16 23:50:43 2014
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2785152 Bytes = 2719.88 kB = 2.66 MB
    Load Address: 00008000
    Entry Point:  00008000

- I've used the standard tftp load address 0x2000000 for the kernel. Didn't load initrd yet, but I would use address 0x3000000 to load the initrd image when the kernel boots - The bootargs settings I did not modify. I think the problem could be the console setting. If the kernel cannot find the console, there are no kernel messages. Any ideas what the correct bootargs parameters could be? Do I need the other arguments ip, initrd and syno_hw_version in the bootargs line apart from the root and rw parameters?

printenv output:

CASset=min
MALLOC_len=5
autoload=no
baudrate=115200
bootargs=console=ttyS0,115200 ip=off initrd=0x8000040,8M root=/dev/md0 rw syno_hw_version=DS213jv10
ihd_num=2 netif_num=1 flash_size=8
bootargs_end=:10.4.50.254:255.255.255.0:KW40:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=bootm 0xf40c0000 0xf4390000
bootdelay=3
cacheShare=no
console=console=ttyS0,115200
disL2Cache=yes
disaMvPnp=no
eeeEnable=no
enaAutoRecovery=yes
enaClockGating=no
enaFPU=no
enaWrAllo=no
eth1addr=00:50:43:02:00:00
eth1mtu=1500
ethact=egiga0
ethaddr=00:50:43:02:02:00
ethmtu=1500
ethprime=egiga0
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.1.50
loadaddr=0x02000000
loads_echo=0
mvNetConfig=mv_net_config=1,(00:50:43:11:11:11,0:1:2:3:4),mtu=1500
mv_pon_addr=00:50:43:00:00:02
netbsd_en=no
netmask=255.255.255.0
netretry=no
pcieTune=no
pexMode=rc
pxe_files_load=:default.arm-armada370-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
rcvrip=169.254.100.100
rootpath=/srv/oneiric
sata_delay_reset=0
sata_dma_mode=yes
serverip=192.168.1.15
setL2CacheWT=no
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
usb0Mode=host
usb1Mode=host
usb2Mode=device
usbActive=1
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81
The flash is only 64 Mbit. Is that too small to fit a Debian kernel and
initrd?
That's 8M, should be OK, I think. Looking at a random armhf system the
3.10 kernel was 2.2M and had a 5.6M initrd, and that's with modules=most
rather than modules=dep.

  That is also the reason why I like the idea of chain loading
another boot loader such as grub, which is for sure small enough to fit
into the flash.
This is a lovely idea in theory, but it will take a lot of work upstream
to make it actually work in practice (I know, I've tried, it's a
nightmare).

Ian.



Reply to: