Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Debian on Synology Armada 370/XP NAS boxes
327 views
Skip to first unread message
Alexander Pohl
May 14, 2014, 1:20:02 PM5/14/14
to
Hi,
Is there hope to have support for Debian on Synology NAS boxes with Armada 370/XP processors added in the future? The new generation of Synology NAS boxes is almost entirely based on ARM Armada SoC's, so if Debian adds support for this platform it would be possible to install on many more NAS models. For example, models based on these processors are the hugely popular DS213j and lately DS114, DS214, DS214+, DS414 and RS214.
Ideally, one would have to supply an u-boot version which has the Grub API enabled and then to chain load Grub from there, which in turns loads Debian initramfs and kernel images. This way keeping the system up to date with newer kernels would be easy as this is all handled by Grub.
The problem for development and testing I see is that the u-boot image supplied by Synology does not have the Grub API enabled, so one has to flash a new version of u-boot first, which is targeted for the specific platform. The bootrom of the DS213j does not support the uart boot method implemented in kwboot, so if the update of the u-boot image fails one is left with a bricked unit. One could try to program the SPI flash in-circuit, but this might not work.
Could you please elaborate on the reasons why Synology boxes are not yet supported by the Debian installer images and where the problems are to implement support in the future.
Many thanks,
Alexander
Is there hope to have support for Debian on Synology NAS boxes with Armada 370/XP processors added in the future? The new generation of Synology NAS boxes is almost entirely based on ARM Armada SoC's, so if Debian adds support for this platform it would be possible to install on many more NAS models. For example, models based on these processors are the hugely popular DS213j and lately DS114, DS214, DS214+, DS414 and RS214.
Ideally, one would have to supply an u-boot version which has the Grub API enabled and then to chain load Grub from there, which in turns loads Debian initramfs and kernel images. This way keeping the system up to date with newer kernels would be easy as this is all handled by Grub.
The problem for development and testing I see is that the u-boot image supplied by Synology does not have the Grub API enabled, so one has to flash a new version of u-boot first, which is targeted for the specific platform. The bootrom of the DS213j does not support the uart boot method implemented in kwboot, so if the update of the u-boot image fails one is left with a bricked unit. One could try to program the SPI flash in-circuit, but this might not work.
Could you please elaborate on the reasons why Synology boxes are not yet supported by the Debian installer images and where the problems are to implement support in the future.
Many thanks,
Alexander
Andrew McGlashan
May 14, 2014, 3:10:03 PM5/14/14
to
Hi,
On 15/05/2014 3:16 AM, Alexander Pohl wrote:
> Could you please elaborate on the reasons why Synology boxes are not yet
> supported by the Debian installer images and where the problems are to
> implement support in the future.
I know this is the debian-arm list, but how about a suggestion for an
alternative box in the NAS type category......
I've had good success, after working through some issues, with Thecus
N4800Eco [0] boxes. I've installed 4x 4TB disks (5TB drives [2] are
compatible, most likely 6TB will be fine too) and they have a 1GB
/special/ SATA device that presents as /dev/sda. Would that suit your
needs?
What I've done is install Debian Wheezy with /boot and grub on the 1GB
drive -- created a 2 way mirror with a small LVM volume that has root on
it and also a dd backup of the 1GB drive (when unmounted). Oh and the
LVM is on a crypt volume -- I am using dropbear to mount it via ssh
using a key file so I can manually enter my luks key.
So far I think this is really good, but it is a pretty new box still and
I'm not quite ready to put it to real work just yet ... aside from doing
extensive testing of the installed hard disk drives using the dropbear
environment with badblocks testing of all SATA devices.
Whilst it did take some working out, the end solution is pretty good and
the box uses a decent Intel CPU [2], much easier with non ARM CPUs and
with LTS support happening for Squeeze, well if that works out, then
Wheezy too on amd64 arch .... this should be a nice longish term
solution -- sure beats the pants off the old D-Link DNS-343 unit it will
replace.
I did a backup of the original Thecus software on the 1GB drive's
content, but I never used the device with the Thecus supplied software
at all.
[0] http://www.thecus.com/product.php?PROD_ID=83
[1]
http://www.thecus.com/download/compatibility/hdd/N4520SERIES_N2800_N4800_N4800Eco_N5550_N4510U_N7510_HDD_SSD_list.pdf
[2] Intel(R) Atom(TM) CPU D2701 @ 2.13GHz
Cheers
A.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5373BEE1...@affinityvision.com.au
On 15/05/2014 3:16 AM, Alexander Pohl wrote:
> Could you please elaborate on the reasons why Synology boxes are not yet
> supported by the Debian installer images and where the problems are to
> implement support in the future.
alternative box in the NAS type category......
I've had good success, after working through some issues, with Thecus
N4800Eco [0] boxes. I've installed 4x 4TB disks (5TB drives [2] are
compatible, most likely 6TB will be fine too) and they have a 1GB
/special/ SATA device that presents as /dev/sda. Would that suit your
needs?
What I've done is install Debian Wheezy with /boot and grub on the 1GB
drive -- created a 2 way mirror with a small LVM volume that has root on
it and also a dd backup of the 1GB drive (when unmounted). Oh and the
LVM is on a crypt volume -- I am using dropbear to mount it via ssh
using a key file so I can manually enter my luks key.
So far I think this is really good, but it is a pretty new box still and
I'm not quite ready to put it to real work just yet ... aside from doing
extensive testing of the installed hard disk drives using the dropbear
environment with badblocks testing of all SATA devices.
Whilst it did take some working out, the end solution is pretty good and
the box uses a decent Intel CPU [2], much easier with non ARM CPUs and
with LTS support happening for Squeeze, well if that works out, then
Wheezy too on amd64 arch .... this should be a nice longish term
solution -- sure beats the pants off the old D-Link DNS-343 unit it will
replace.
I did a backup of the original Thecus software on the 1GB drive's
content, but I never used the device with the Thecus supplied software
at all.
[0] http://www.thecus.com/product.php?PROD_ID=83
[1]
http://www.thecus.com/download/compatibility/hdd/N4520SERIES_N2800_N4800_N4800Eco_N5550_N4510U_N7510_HDD_SSD_list.pdf
[2] Intel(R) Atom(TM) CPU D2701 @ 2.13GHz
Cheers
A.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5373BEE1...@affinityvision.com.au
Paul Wise
May 14, 2014, 7:10:02 PM5/14/14
to
Have you attempted an install? The new Debian buildds/porterboxen have
Marvell Armada 370/XP CPUs and are running
linux-image-3.13-1-armmp-lpae with minimal config differences to
wheezy-backports.
https://db.debian.org/machines.cgi?host=abel
Looking at your list and at the upstream Linux kernel device tree
files, it appears that the only ones with device tree files are the
Kirkwood based ones so perhaps the Armada 370/XP based ones need some
upstream Linux work. The best way to tell would be to try booting the
Linux armmp or armmp-lpae kernel from jessie or wheezy-backports.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/CAKTje6HRL9scBXPGygzEoBio7S7R3tCeXGSqF4kiZwU=VgG...@mail.gmail.com
Marvell Armada 370/XP CPUs and are running
linux-image-3.13-1-armmp-lpae with minimal config differences to
wheezy-backports.
https://db.debian.org/machines.cgi?host=abel
Looking at your list and at the upstream Linux kernel device tree
files, it appears that the only ones with device tree files are the
Kirkwood based ones so perhaps the Armada 370/XP based ones need some
upstream Linux work. The best way to tell would be to try booting the
Linux armmp or armmp-lpae kernel from jessie or wheezy-backports.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ian Campbell
May 15, 2014, 6:50:02 AM5/15/14
to
On Wed, 2014-05-14 at 19:16 +0200, Alexander Pohl wrote:
> Ideally, one would have to supply an u-boot version which has the Grub
> API enabled and then to chain load Grub from there,
Ideally perhaps but in reality there are various issues with running
> Ideally, one would have to supply an u-boot version which has the Grub
> API enabled and then to chain load Grub from there,
grub on u-boot (the u-boot API is pretty broken, grub is not relocatable
etc), I at least have given up on that path.
> which in turns loads Debian initramfs and kernel images. This way
> keeping the system up to date with newer kernels would be easy as this
> is all handled by Grub.
support should just be a case of figuring out the correct stanza for the
machine. It supports various modes, including copying kernel+flash to
dedicated flash partitions (either raw or with a filesystem), writing a
boot.scr, appending a device-tree as necessary etc. It should be
possible to integrate with the factory u-boot.
Even if you are keen to go the grub route I would suggest getting things
working via flash-kernel first to enable these systems to be used, and
then treat the grub thing as a future thing.
u-boot folks seem to be standardising on parsing the extlinux/syslinux
config file format for this stuff, I might take a look at whether the
extlinux-update script can be made available on ARM at some point (it's
currently in an x86 only package).
> The problem for development and testing I see is that the u-boot image
> supplied by Synology does not have the Grub API enabled, so one has to
> flash a new version of u-boot first, which is targeted for the
> specific platform. The bootrom of the DS213j does not support the uart
> boot method implemented in kwboot, so if the update of the u-boot
> image fails one is left with a bricked unit. One could try to program
> the SPI flash in-circuit, but this might not work.
unless the factory one is horribly broken somehow.
> Could you please elaborate on the reasons why Synology boxes are not
> yet supported by the Debian installer images and where the problems
> are to implement support in the future.
patches.
Ian.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alexander Pohl
May 16, 2014, 2:00:02 PM5/16/14
to
On 15/05/14 01:09, Paul Wise wrote:
> Have you attempted an install? The new Debian buildds/porterboxen have
> Marvell Armada 370/XP CPUs and are running
> linux-image-3.13-1-armmp-lpae with minimal config differences to
> wheezy-backports.
Yes, I tried to load many different kernel images but no luck. After
> Have you attempted an install? The new Debian buildds/porterboxen have
> Marvell Armada 370/XP CPUs and are running
> linux-image-3.13-1-armmp-lpae with minimal config differences to
> wheezy-backports.
"Starting kernel ..." nothing happens. I added the u-boot header with
this command:
$ mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000
-n "vmlinuz-3.13-1-armmp-lpae" -d vmlinuz-3.13-1-armmp-lpae uImg
Then I transferred the image with tftpboot and booted with "bootm"
## Booting kernel from Legacy Image at 02000000 ...
Image Name: vmlinuz-3.13-1-armmp-lpae
Created: 2014-05-16 17:21:51 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2785152 Bytes = 2.7 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
I didn't provide an initrd image or device tree blob. I think the
version of u-boot Synology provides is not capable of booting a device
tree enabled kernel. The source of u-boot is available in their GPL
download, but I do not know how to make it work or what the device tree
blob is for.
When the DS213j boots with syno kernel and initrd it looks like this:
## Booting kernel from Legacy Image at f40c0000 ...
Image Name: Linux-3.2.40
Created: 2013-08-16 18:17:29 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1860000 Bytes = 1.8 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at f4390000 ...
Image Name: synology_armada370_213j 3776
Created: 2013-08-23 14:11:07 UTC
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 2903840 Bytes = 2.8 MiB
Load Address: 08000000
Entry Point: 08000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Linux version 3.2.40 (root@build4) (gcc version 4.6.4
(Linaro GCC branch-4.6.4. Marve
ll GCC Dev 201307-2124.aa2fad08 ) ) #3776 Sat Aug 17 02:17:23 CST 2013
[ 0.000000] CPU: Marvell PJ4Bv7 Processor [561f5811] revision 1
(ARMv7), cr=18c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction
cache
[ 0.000000] Machine: Marvell Armada-370
[ 0.000000] Using UBoot passing parameters structure
[ 0.000000] >>>>>>>Tag MAC 00:02:02:43:50:00
[ 0.000000] >>>>>>>Tag MAC 00:00:00:00:00:00
[ 0.000000] Memory policy: ECC disabled, Data cache writealloc
etc.
Any ideas how to make the stock u-boot to accept a Debian kernel?
Thanks,
Alexander
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alexander Pohl
May 16, 2014, 6:10:03 PM5/16/14
to
On 16/05/14 19:57, drEagle wrote:
> You can try to append the dtb to the kernel.
>
> Adapt the correct dtb file for you need.
>
> $ cat ./vmlinuz ./armada-370-mirabox.dtb >> ./zImage-mirabox
> $ mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n linux+dtb -d ./zImage-mirabox ./uImage
> $ mkimage -A arm -O linux -T ramdisk -C none -a 0x00000000 -e 0x00000000 -n "debian installer ramdisk" -d ./initrd.gz ./9016-4EF8/uInitrd
>
> Then do the boot as usual.
I tried appending the dtb to the kernel. Unfortunately it does not make
the kernel boot. I think I have to replace the crippled u-boot version
with my own fully featured version without bricking my box.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/53768B22...@gmail.com
>
> Adapt the correct dtb file for you need.
>
> $ cat ./vmlinuz ./armada-370-mirabox.dtb >> ./zImage-mirabox
> $ mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n linux+dtb -d ./zImage-mirabox ./uImage
> $ mkimage -A arm -O linux -T ramdisk -C none -a 0x00000000 -e 0x00000000 -n "debian installer ramdisk" -d ./initrd.gz ./9016-4EF8/uInitrd
>
> Then do the boot as usual.
I tried appending the dtb to the kernel. Unfortunately it does not make
the kernel boot. I think I have to replace the crippled u-boot version
with my own fully featured version without bricking my box.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alexander Pohl
May 16, 2014, 6:20:02 PM5/16/14
to
not able to get the kernel to boot (see my other post).
The flash is only 64 Mbit. Is that too small to fit a Debian kernel and
initrd? 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. Kernel and initrd images can then be loaded from hard
disk. I know the real u-boot can load images from ext2 partitions as
well, but that would require the saveenv command to work to be able to
store the alterations to the boot command line permanently, which is not
enabled on factory u-boot.
>> Could you please elaborate on the reasons why Synology boxes are not
>> yet supported by the Debian installer images and where the problems
>> are to implement support in the future.
> AFAIK there are none. These things happen when interested people send
> patches.
>
> Ian.
>
--
Enzstrasse 12b
76344 Eggenstein-Leopolshafen
Telefon: 07247 9690526
Mobil: 0176 34724208
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ian Campbell
May 17, 2014, 5:00:01 AM5/17/14
to
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
> > 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).
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).
> The flash is only 64 Mbit. Is that too small to fit a Debian kernel and
> initrd?
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.
to make it actually work in practice (I know, I've tried, it's a
nightmare).
Ian.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alexander Pohl
May 19, 2014, 4:20:02 PM5/19/14
to
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
> 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).
>
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:
Entry Point: 00008000
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.
Entry Point: 00008000
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-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/537A6521...@gmail.com
>> 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-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ian Campbell
May 21, 2014, 2:40:01 PM5/21/14
to
On Mon, 2014-05-19 at 22:10 +0200, Alexander Pohl wrote:
> 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.
Me neither, is "mirabox" the name of the platform you are using? I don't
> 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.
think it is (mirabox isn't a synology product, is it?).
But even if it isn't the right board it is the right SoC so I'd expect
serial might possibly work, but maybe your platform uses a different
UART.
Nothing stood out as wrong in the rest of your mail so I'm afraid you
next step will likely have to be finding or writing a proper DTB for
your platform. Probably you'll have more luck with asking about that
upstream than here. Once the upstream kernel works on the system Debian
support is mostly pretty simple.
Ian.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages