Re: [Bulk] Flattened Device Tree on SheevaPlug and Linux 3.15
On Mon, 2014-06-23 at 19:31 +0100, Michael Howard wrote: On 23/06/2014 10:36, Stuart Winter wrote: Hello Hi, Can't help you with much and may be off mark with the following but, My kernel has the support for appended DTBs so I also tried appending the FDT blob to the uImage - again for both eSATA and regular Sheevaplug: cat dtbfile.dtb uImage isn't the 'dtb' supposed to be appended to the zImage and then the uImage created with mkimage? Correct. 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/1403597782.1829.4.ca...@dagon.hellion.org.uk
Re: Flattened Device Tree on SheevaPlug and Linux 3.15
Hi Stuart,
I'm sorry this is going to be a non-answer as I haven't tried device tree
boot on my sheevaplug. Just wanted to answer this - I don't believe that
the sheevaplug is actually an eSATA version - it doesn't have an eSATA port
-- maybe there's just support on board.
IIRC the original sheevaplugs have the bus present on the SoC but it's not
connected to anything, so there's no harm in treating them the same in
software, even though the ports aren't there.
On Mon, Jun 23, 2014 at 10:36 AM, Stuart Winter giantbees...@gmail.com
wrote:
Hello
I'm hoping someone can help point out the way to make U-Boot work with
Flattened Device Tree on the SheevaPlug.
I have the same Linux 3.15.1 kernel binary running on the OpenRD client,
but the OpenRD client has support baked into the kernel (presumably
because the OpenRD client has no newer version of U-Boot that can support
FDT).
On the SheevaPlug I upgraded from the original Marvell u-boot to the
version here:
http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/
I don't believe that the sheevaplug is actually an eSATA version - it
doesn't have an eSATA port -- maybe there's just support on board.
U-Boot 2011.12 (Mar 11 2012 - 18:59:46)
Marvell-Sheevaplug - eSATA - SD/MMC
SoC: Kirkwood 88F6281_A0
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 512 MiB
In:serial
Out: serial
Err: serial
Net: egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot: 0
Marvell
It has a standard setup from having re-flashed u-boot, apart from I added
setenv machid=a76
Marvell print
baudrate=115200
bootcmd=${x_bootcmd_kernel}; setenv bootargs ${x_bootargs}
${x_bootargs_root}; ${x_bootcmd_usb}; ${x_bootcmd_sata}; bootm 0x640;
bootdelay=3
ethact=egiga0
ethaddr=00:50:43:cc:34:2b
machid=a76
stderr=serial
stdin=serial
stdout=serial
x_bootargs=console=ttyS0,115200
mtdparts=orion_nand:512k(uboot),4m@1m(kernel),507m@5m(rootfs) rw
x_bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs
x_bootcmd_kernel=nand read 0x640 0x10 0x40
x_bootcmd_sata=ide reset;
x_bootcmd_usb=usb start;
Environment size: 545/131068 bytes
Marvell dhcp;tftpboot 0x588
slackwarearm-current/dtb/kirkwood-sheevaplug.dtb
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 43
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 43
DHCP client bound to address 192.168.1.19
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.19
Filename 'pxelinux.0'.
Load address: 0x80
Loading: #
done
Bytes transferred = 11826 (2e32 hex)
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.19
Filename 'dtb/kirkwood-sheevaplug.dtb'.
Load address: 0x588
Loading: #
done
Bytes transferred = 9779 (2633 hex)
Marvell tftpboot 0x0110 initrd-kirkwood.img
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.19
Filename 'slackwarearm-current/uinitrd-kirkwood.img'.
Load address: 0x110
Loading: #
[ .. snip .. ]
done
Bytes transferred = 18873744 (11ffd90 hex)
Marvell tftpboot 0x0080 uImage-kirkwood
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.19
Filename 'slackwarearm-current/uImage-kirkwood'.
Load address: 0x80
Loading: #
[..snip..]
done
Bytes transferred = 2547312 (26de70 hex)
Marvell
Marvell setenv bootargs earlyprintk console=ttyS0,115200n8 kbd=uk
nic=auto:eth0:dhcp root=/dev/ram rw
Marvell bootm 0x0080 0x0110 0x588
## Booting kernel from Legacy Image at 0080 ...
Image Name: Linux-3.15.1-kirkwood
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:2547248 Bytes = 2.4 MiB
Load Address: 8000
Entry Point: 8000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 0110 ...
Image Name: Installer
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size:18873680 Bytes = 18 MiB
Load Address:
Entry Point:
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Using machid 0xa76 from environment
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Error: unrecognized/unsupported machine ID (r1 = 0x0a76).
Available machine support:
ID (hex)NAME
089bLaCie d2 Network v2
089eLaCie 5Big Network v2
089cLaCie 2Big Network v2
0b44Marvell OpenRD Ultimate Board
0939Marvell OpenRD Client Board
0915Marvell OpenRD Base Board
0691Marvell RD-88F6192-NAS Development Board
0692Marvell RD-88F6281 Reference Board
0b1eHP t5325 Thin Client
085bQNAP TS-119/TS-219
09c6
Fwd: [Bulk] Flattened Device Tree on SheevaPlug and Linux 3.15
isn't the 'dtb' supposed to be appended to the zImage and then the uImage created with mkimage? Thanks -- it dawned on me that this was the case after I had sent the mail, so I assume it will boot once I add it to the zImage - I'll test it shortly. However, I still don't know why U-Boot doesn't seem to be supplying the FTD blob when it's been loaded itself. I also tried building the latest U-Boot release myself but couldn't get it to run on the SheevaPlug (loading into RAM then using 'go' in u-boot) so haven't made any progress. I thought the necessity to upgrade to the DENX version of U-Boot was because of FTD, but the Marvell version could have been used if the kernel uses an appended FTD blob instead.
Re: [Bulk] Flattened Device Tree on SheevaPlug and Linux 3.15
On 23/06/2014 10:36, Stuart Winter wrote: Hello I'm hoping someone can help point out the way to make U-Boot work with Flattened Device Tree on the SheevaPlug. Marvell setenv bootargs earlyprintk console=ttyS0,115200n8 kbd=uk nic=auto:eth0:dhcp root=/dev/ram rw Marvell bootm 0x0080 0x0110 0x588 I'm not sure about the load address your using for the fdt blob (0x588). ## Booting kernel from Legacy Image at 0080 ... Image Name: Linux-3.15.1-kirkwood Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2547248 Bytes = 2.4 MiB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 0110 ... Image Name: Installer Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size:18873680 Bytes = 18 MiB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK At this point you should see the FDT blob being reported as loading/successfully loaded. Even if the address is ok, you should still see the confirmation iirc. -- -- 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/53a96122.8090...@dewberryfields.co.uk
Re: Flattened Device Tree on SheevaPlug and Linux 3.15
Sorry, Forgot the ML... On 24/06/2014 13:45, drEagle wrote: Hi, Never tried for now the fdt commands; zimage cat method works just fine on kirkwood and armada. On 23/06/2014 11:36, Stuart Winter wrote: ... Does anybody have any idea why it doesn't work or how to make it work? I would prefer to load the FDT blob using u-boot rather than appending it to the Kernel blob since the version of u-boot on this Sheeva should support it. What about the uboots fdt commands [1] ? Don't you need to tell uboot to use fdt ? fdt addr $fdt_addr $fdt_size fdt resize fdt chosen may be more commands also. You can also use a multi+monolithic image. $ mkimage . -d zimage:initrd:fdt uImage-multi [1] http://www.denx.de/wiki/view/DULG/UBootCmdFDT [2] http://www.denx.de/wiki/pub/U-Boot/Documentation/multi_image_booting_scenarios.pdf -- 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/53a96d51.2060...@doukki.net
Re: Flattened Device Tree on SheevaPlug and Linux 3.15
On Tue, 2014-06-24 at 14:21 +0200, drEagle wrote: Sorry, Forgot the ML... On 24/06/2014 13:45, drEagle wrote: Hi, Never tried for now the fdt commands; zimage cat method works just fine on kirkwood and armada. On 23/06/2014 11:36, Stuart Winter wrote: ... Does anybody have any idea why it doesn't work or how to make it work? I would prefer to load the FDT blob using u-boot rather than appending it to the Kernel blob since the version of u-boot on this Sheeva should support it. What about the uboots fdt commands [1] ? AFAIK that's mostly about modifying an in memory FDT, but it doesn't actual deal with passing it to the kernel, which is done by passing the address as the third argument to bootm or bootz. Don't you need to tell uboot to use fdt ? You need to tell it to pass it to the kernel as above, yes. But for most platforms u-boot itself doesn't use (i.e. consume for its own hardware detection purposes) the fdt apart from that. 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/1403614260.30061.19.ca...@kazak.uk.xensource.com
Re: Fwd: [Bulk] Flattened Device Tree on SheevaPlug and Linux 3.15
On Tue, 2014-06-24 at 11:40 +0100, Stuart Winter wrote: However, I still don't know why U-Boot doesn't seem to be supplying the FTD blob when it's been loaded itself. Not sure what you mean here. u-boot needs to be told to pass an fdt (which must already be in RAM) by passing the address as the third argument to bootm or bootz. If you don't have an initrd (the second argument) then use -. I thought the necessity to upgrade to the DENX version of U-Boot was because of FTD, For some of these plug devices the factory u-boot is buggy wrt cache maintenance which makes kernels from the last year or two fail to boot. I don't know if that applies to the sheevaplug or not, but it does to e.g. dreamplug and other marvel based things so it's not impossible that it does. but the Marvell version could have been used if the kernel uses an appended FTD blob instead. -- 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/1403614412.30061.22.ca...@kazak.uk.xensource.com
Re: Dreamplug - debian installer
On Thu, 2014-06-19 at 07:58 +0100, Michael Howard wrote: On 18/06/2014 19:41, Ian Campbell wrote: On Wed, 2014-06-18 at 17:46 +0100, Michael Howard wrote: Anybody tried a standard 'debian-installer' install recently on the Dreamplug? Not recently. I'm about to leave on a trip so I won't have time to try anything until next week. No problem. Doesn't work here on any recent u-boot with any version of debian with _any_ of my three dreamplugs. All I end up with is Starting kernel ... Which u-boot versions and with which specific kernel versions have you tried? The factory supplied u-boot has a bug and doesn't work with most modern kernels. I tried U-Boot 2012.04.01, I tried the latest from debian repo 2014x, I tried 2011.12.3 (as linked on http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/) and I cant remember the exat version of the original one that I tried but it was 2013x. Thanks. And which kernels have you used, exact download URLs would be handy. 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/1403614547.30061.23.ca...@kazak.uk.xensource.com
Re: Dreamplug - debian installer
On 24/06/2014 13:55, Ian Campbell wrote: On Thu, 2014-06-19 at 07:58 +0100, Michael Howard wrote: On 18/06/2014 19:41, Ian Campbell wrote: On Wed, 2014-06-18 at 17:46 +0100, Michael Howard wrote: Anybody tried a standard 'debian-installer' install recently on the Dreamplug? Not recently. I'm about to leave on a trip so I won't have time to try anything until next week. No problem. Doesn't work here on any recent u-boot with any version of debian with _any_ of my three dreamplugs. All I end up with is Starting kernel ... Which u-boot versions and with which specific kernel versions have you tried? The factory supplied u-boot has a bug and doesn't work with most modern kernels. I tried U-Boot 2012.04.01, I tried the latest from debian repo 2014x, I tried 2011.12.3 (as linked on http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/) and I cant remember the exat version of the original one that I tried but it was 2013x. Thanks. And which kernels have you used, exact download URLs would be handy. Ian. As I was trying a fresh install I first used the current images (kernel initrd) from wheezy. I then tried jessie and when that failed I tried the last images from squeeze. All failed at the same point. I can't remember the last time I did a 'fresh' install to say when it last worked here. Cheers, Mike. -- -- 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/53a98925.2020...@dewberryfields.co.uk
Re: Information needed from owners/users of Debian on ARM/kirkwood base QNAP devices (should take 1min to gather)
Ian Campbell ijc at hellion.org.uk writes: TL;DR: Please run the attached kirkwood-qnap script on your ARM based QNAP systems as ./kirkwood-qnap --info and report the results in this thread along with the model/kind of your QNAP device (as precisely as you can). $ ./kirkwood-info.sh .: 87: Can't open /usr/share/flash-kernel/functions :-) This is a TS-119 (the nice fanless model with an extruded aluminium chassis) running a rather old Debian installation, hence the error above. Maybe the following will tell you what you need to know: phil@uganda:~$ uname -a Linux uganda 2.6.33.2 #1 Tue Apr 20 18:50:54 BST 2010 armv5tel GNU/Linux phil@uganda:~$ lspci 00:00.0 Memory controller: Marvell Technology Group Ltd. 88F6281 [Kirkwood] ARM SoC (rev 02) phil@uganda:~$ lspci -n 00:00.0 0580: 11ab:6281 (rev 02) phil@uganda:~$ cat /proc/cpuinfo Processor : Feroceon 88FR131 rev 1 (v5l) BogoMIPS: 1199.30 Features: swp half thumb fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part: 0x131 CPU revision: 1 Hardware: QNAP TS-119/TS-219 Revision: Serial : phil@uganda:~$ ls /sys/bus/mdio_bus/devices/ 0:08 -- 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/loom.20140624t170349-...@post.gmane.org
Re: Flattened Device Tree on SheevaPlug and Linux 3.15
the FTD blob when it's been loaded itself. Not sure what you mean here. u-boot needs to be told to pass an fdt (which must already be in RAM) by passing the address as the third argument to bootm or bootz. If you don't have an initrd (the second argument) then use -. The DTB was loaded like this: dhcp;tftpboot 0x588 dtb/kirkwood-sheevaplug.dtb And its memory location supplied as the 3rd argument -- this is how I have it working on the TrimSlice. bootm 0x0080 0x0110 0x588 I could try another memory location I suppose but I'm not sure that this is the cause of the reason for its absence, since I use identical memory locations on both the Trimslice and SheevaPlugs for the initrd, kernel and FTD. -- Stuart Winter Slackware ARM: http://arm.slackware.com -- 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/alpine.lnx.2.11.1406241616420@bourbon.biscuit.org.uk
Re: Flattened Device Tree on SheevaPlug and Linux 3.15
On Tue, 2014-06-24 at 16:19 +0100, Stuart Winter wrote: the FTD blob when it's been loaded itself. Not sure what you mean here. u-boot needs to be told to pass an fdt (which must already be in RAM) by passing the address as the third argument to bootm or bootz. If you don't have an initrd (the second argument) then use -. The DTB was loaded like this: dhcp;tftpboot 0x588 dtb/kirkwood-sheevaplug.dtb And its memory location supplied as the 3rd argument -- this is how I have it working on the TrimSlice. bootm 0x0080 0x0110 0x588 I could try another memory location I suppose but I'm not sure that this is the cause of the reason for its absence, since I use identical memory locations on both the Trimslice and SheevaPlugs for the initrd, kernel and FTD. Did you try the appending method and have it work? Do e.g. the kernels currently in testing and/or experimental work for you? BTW in your original message you said: The 'Machine:' line should indicate the model number (according to various posts I've found around FTD and U-Boot). I think that's only the case for non-FDT boardfile booting. For booting via FDT the Machine: Marvell Kirkwood (Flattened Device Tree) which you report seems correct to me. One other thing you could try is clearing machid in the environment, it isn't supposed to be used for fdt booting and perhaps its presence is confusing something. Other than that I think we are into report it upstream territory. The guys who work on kirkwood upstream are usually pretty responsive, I've found. -- Stuart Winter Slackware ARM: http://arm.slackware.com -- 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/alpine.lnx.2.11.1406241616420@bourbon.biscuit.org.uk -- 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/1403624166.3875.4.ca...@kazak.uk.xensource.com
Encrytion on a QNAP
Hello, since I have to reinstall my NAS on a new HDD, I thought it would be a good idea to set up encryption this time. But I'm not sure how exactly I should start on this. I think the standard way to do this is using the dm-crypt facilities built into the Debian installer. Now, will this work with a headless machine where I can't enter anything on boot time? If it's possible to disable SWAP and encrypt /home, could it be mounted remotely after boot? And what about services that run on those volumes, they should surely start after the mount, shouldn't they? Finally, is this even a good idea? Will it cost too much performance? I'm using a TS-119 and am not sure if any crypto would be accelerated. Thanks, Lee
Re: Flattened Device Tree on SheevaPlug and Linux 3.15
On 24/06/2014 14:51, Ian Campbell wrote: On Tue, 2014-06-24 at 14:21 +0200, drEagle wrote: What about the uboots fdt commands [1] ? AFAIK that's mostly about modifying an in memory FDT, but it doesn't actual deal with passing it to the kernel, which is done by passing the address as the third argument to bootm or bootz. It's more simple that I was thinking. Don't you need to tell uboot to use fdt ? You need to tell it to pass it to the kernel as above, yes. But for most platforms u-boot itself doesn't use (i.e. consume for its own hardware detection purposes) the fdt apart from that. Thanks for the information. -- 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/53a9b269.2000...@doukki.net
Re: Encrytion on a QNAP
On Tue, 2014-06-24 at 17:18 +0200, Lee Williams wrote: Hello, since I have to reinstall my NAS on a new HDD, I thought it would be a good idea to set up encryption this time. But I'm not sure how exactly I should start on this. I think the standard way to do this is using the dm-crypt facilities built into the Debian installer. Now, will this work with a headless machine where I can't enter anything on boot time? That was my thought too. Out of the box? Probably not. If it's possible to disable SWAP and encrypt /home, The installer will allow this I think (you'll need to ignore the warning about no swap) could it be mounted remotely after boot? You'd likely have to arrange for all that yourself and you'd be going pretty far of the beaten track I think, which probably means hacking something up yourself (even after googling for prior art would be my guess) but if you are willing to spend the time making it work it ought to be possible in theory. And what about services that run on those volumes, they should surely start after the mount, shouldn't they? They would certainly normally start after the mount, but if you were deferring the mount somehow then you might need to arrange to defer those services too. Or otherwise to stall the boot process until things were remotely enabled somehow. Finally, is this even a good idea? Will it cost too much performance? I'm using a TS-119 and am not sure if any crypto would be accelerated. TS-119 is kirkwood based I think, so there is some hardware acceleration (md5, sha-1, aes) and an associated kernel driver (mv_cesa). I don't know to what extent that is useful for dm-crypt etc though (md5 obviously not so much ;-)). 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/1403632594.1829.25.ca...@dagon.hellion.org.uk
Re: Information needed from owners/users of Debian on ARM/kirkwood base QNAP devices (should take 1min to gather)
On Wed, 2014-06-18 at 10:59 +0100, David Pottage wrote: On 17/06/14 08:49, Ian Campbell wrote: Hello, TL;DR: Please run the attached kirkwood-qnap script on your ARM based QNAP systems as ./kirkwood-qnap --info and report the results in this thread along with the model/kind of your QNAP device (as precisely as you can). The script does not need to be run as root and gathers information about the hardware platform and kernel version only, it is non-destructive (even if run without the --info, so don't worry). I have a Qnap TS-110 that I was using with Debian for a while, but I have upgraded to better hardware and re-fashed the TS-110 back to the Qnap firmware. Would it be useful to run these tests under the qnap firmware if I can get a shell, or would that not be helpfull? I don't want to switch to Debian just for this test. It might have been interesting but I don't think it would work with the script as it is, so probably not worth the effort for you, thanks though. 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/1403632712.1829.26.ca...@dagon.hellion.org.uk
Re: Information needed from owners/users of Debian on ARM/kirkwood base QNAP devices (should take 1min to gather)
On Tue, 2014-06-24 at 15:12 +, Phil Endecott wrote: Ian Campbell ijc at hellion.org.uk writes: TL;DR: Please run the attached kirkwood-qnap script on your ARM based QNAP systems as ./kirkwood-qnap --info and report the results in this thread along with the model/kind of your QNAP device (as precisely as you can). $ ./kirkwood-info.sh .: 87: Can't open /usr/share/flash-kernel/functions :-) Heh, I should have thought to mention that! This is a TS-119 (the nice fanless model with an extruded aluminium chassis) running a rather old Debian installation, hence the error above. Maybe the following will tell you what you need to know: Yes, thanks. 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/1403632824.1829.27.ca...@dagon.hellion.org.uk
Re: Information needed from owners/users of Debian on ARM/kirkwood base QNAP devices (should take 1min to gather)
On Tue, 2014-06-17 at 08:49 +0100, Ian Campbell wrote: Hello, TL;DR: Please run the attached kirkwood-qnap script on your ARM based QNAP systems as ./kirkwood-qnap --info and report the results in this thread along with the model/kind of your QNAP device (as precisely as you can). The script does not need to be run as root and gathers information about the hardware platform and kernel version only, it is non-destructive (even if run without the --info, so don't worry). Thanks to everyone who provided info. I've not yet managed to go through everything but it seems like I've got plenty of data and on first glance things seem to be working as intended, which is good. Cheers, 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/1403632964.1829.30.ca...@dagon.hellion.org.uk
Re: Encrytion on a QNAP
On Tue, Jun 24, 2014 at 7:56 PM, Ian Campbell i...@hellion.org.uk wrote: On Tue, 2014-06-24 at 17:18 +0200, Lee Williams wrote: Lee, are you on the list or should we continue to cc? Hello, since I have to reinstall my NAS on a new HDD, I thought it would be a good idea to set up encryption this time. But I'm not sure how exactly I should start on this. I think the standard way to do this is using the dm-crypt facilities built into the Debian installer. Now, will this work with a headless machine where I can't enter anything on boot time? That was my thought too. Out of the box? Probably not. If you have serial console, it will work OOTB. I've done it on the SheevaPlug and it worked just fine entering the passphrase on the console. If it's possible to disable SWAP and encrypt /home, The installer will allow this I think (you'll need to ignore the warning about no swap) You can encrypt swap too, but you use the option to generate a random key at every boot (the option is available in the installer). There are plenty of guides around, just Google it. could it be mounted remotely after boot? You'd likely have to arrange for all that yourself and you'd be going pretty far of the beaten track I think, which probably means hacking something up yourself (even after googling for prior art would be my guess) but if you are willing to spend the time making it work it ought to be possible in theory. I've done this too, and it's not even hard. What you do is put dropbear in the initrd so you can ssh to the box pre-boot-time and enter the passphrase. Look e.g. at https://www.google.com/search?q=dropbear%20in%20initrd And what about services that run on those volumes, they should surely start after the mount, shouldn't they? They would certainly normally start after the mount, but if you were deferring the mount somehow then you might need to arrange to defer those services too. Or otherwise to stall the boot process until things were remotely enabled somehow. Finally, is this even a good idea? Will it cost too much performance? I'm using a TS-119 and am not sure if any crypto would be accelerated. TS-119 is kirkwood based I think, so there is some hardware acceleration (md5, sha-1, aes) and an associated kernel driver (mv_cesa). I don't know to what extent that is useful for dm-crypt etc though (md5 obviously not so much ;-)). If you use the installer, as I have, your performance will suffer severely. I used it for a torrent box, which was fine, but if you e.g. plan to stream HD content it's another story completely. I never tried custom kernels or the like. Good luck Björn 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/1403632594.1829.25.ca...@dagon.hellion.org.uk
Re: Dreamplug - debian installer
On 24/06/2014 18:01, Ian Campbell wrote: On Tue, 2014-06-24 at 15:20 +0100, Michael Howard wrote: As I was trying a fresh install I first used the current images (kernel initrd) from wheezy. I then tried jessie and when that failed I tried the last images from squeeze. All failed at the same point. I can't remember the last time I did a 'fresh' install to say when it last worked here. I've just tried booting the wheezy installer from ftp://ftp.debian.org/debian/dists/wheezy/main/installer-armel/current/images/kirkwood/netboot/marvell/dreamplug/ with U-Boot 2012.04.01 (Jun 01 2012 - 02:17:08) which is the u-boot from the Wheezy u-boot package u-boot_2012.04.01-2_armel.deb and it works for me (log at the end). I've asked you a couple of times now for the exact images you are using and you've given inexact answers each time (e.g. wheezy which doesn't tell me what I need to know), so I don't know if this matches what you are using or not. Actually, you asked me once. I considered that 'the current images (kernel initrd) from wheezy' etc, would be understandable to you, however, as it clearly isn't, here, have a url; http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/netboot/marvell/dreamplug/uImage I'm sure you can work out the rest. I think if you want further help you are going to need to provide details, including the actual logs of what you typed in u-boot, what the output was etc. I don't need further help. I was actually trying to help, but hey ho! -- -- 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/53a9d393.90...@dewberryfields.co.uk
