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.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/537a6521.6070...@gmail.com