bastel Wrote: ------------------------------------------------------- > No, but I had one connected, that's why u-boot > finds 2 storage devices, while linux finds > neither. > I will try (later today) to supply external power > to the hdd and see if it boots then (depends if > the 5v power both usb and hdd or just hdd). Maybe > a powered hub in between will workby bodhi - Debian
bastel, I see you're booting with USB connect HDD. Have you tried with a USB thumb drive?by bodhi - Debian
@Tomas, > I will try it then. Is there a list of features > your kernel patch includes fo NSA325 devices? > Not specific, they are common for all Kirkwood devices. > [ 4.891585] Bad eraseblock 100 at > 0x000000c80000 > [ 4.901493] Bad eraseblock 200 at > 0x000001900000 These bad blocks are way out, not in first 1M, so it is safe to flash u-boot.by bodhi - uBoot
@Tomas, Very perceptive! you are right in a way. Since mainline kernel support Kirwood FDT, you can basically install it and use the appropriate DTS to boot the kernel. However, the NSA325 DTS is not in the mainine yet, so you need to use the NSA325 DTS I've included in the patch in the kernel thread and boot with it. This will give you a basic NSA325 supports. But in the Kirkwood patch sby bodhi - uBoot
@enki, Yes, I'll add more details when I can.by bodhi - uBoot
bastel, Problem is with USB dirve, make sure you have USBROOT label correctly on USB rootfs partition.by bodhi - Debian
Buttzy, Should only flash the image in this post: http://forum.doozan.com/read.php?3,12381,17420#msg-17420by bodhi - Debian
Buttzy, That's very strange. Perhaps your serial connection has something to do with it? Usually: uboot.2013.10-tld-1.nsa325.mtd0.kwb sometimes stop at 70%. uboot.2013.10-tld-1.nsa325.uart.kwb always loaded 100% for me and many others, but not for some users. uboot.2013.10-tld-1-test.nsa325.uart.kwb never failed to load 100%.by bodhi - Debian
Buttzy10169 Wrote: ------------------------------------------------------- > bodhi, > > I have tried both versions of the uboot in that > thread and so far have not been able to get it to > boot. > > I think the highest I got on it was about 30% > yesterday. You meant that you have tried uboot.2013.10-tld-1-test.nsa325.uart.kwb ?by bodhi - Debian
Tomas, Stock u-boot does not have >2 TB HDD GPT support. So in order to boot with GPT 3TB HDD, you will need new u-boot. And no, you can't install mainline Debian, because it is not available for NSA325.by bodhi - uBoot
Tomas, uboot.2013.10-tld-1 does have capability of booting 3TB GPT. No need to use hybrid MBR. These features are supported: - both FDT and non-FDT kernel booting - supports EFI/GPT partition > 2TB (SATA and USB) either for booting or just attached. - boot Ext4 rootfs - SNTP (Simple NTP to set date time during U-Boot booting) - bootz (boot with zImage).by bodhi - uBoot
Buttzy, The NSA325 u-boot is here in this thread: http://forum.doozan.com/read.php?3,12381,17420#msg-17420 You should try UART booting with the small test version at the end of the above post (uboot.2013.10-tld-1-test.nsa325.uart.kwb) Once you can UART booting with the small u-boot image, then you can flash the real version (U-Boot 2013.10-tld-1) without worrying. > As in is thereby bodhi - Debian
enki, You should use both, if you are booting with multiple drives. The USB scanning is for u-boot to find uImage on USB drive(s), the rootfs label is for the kernel to find rootfs in any drive. They are 2 separate steps.by bodhi - uBoot
@Eddie & Buttzy, Have you guys tried to boot with the new NSA325 u-boot?by bodhi - Debian
enki , > It seems "get-apt install mdadm" re-built > "/boot/initrd.img-3.10.4-kirkwood-tld-1" as the > time stamp is "Jan 3 16:04"! and suddenly my GFN > is not booting correctly anymore, not with the > NTFS hdds connected in at the boot sequence. GFN > boots successfully only with the USB memory in and > no hdds, so GFN gets an IP addrby bodhi - uBoot
@WarheadsSE, From what I can tell (without close scrutity) the DTS has all definition that you have in your patch for non-FDT kernel (nsa_325_setup.c). GPIO 47 was defined, and showed up in the running device-tree. Buttzy has attached the proc device tree in this post: http://forum.doozan.com/read.php?2,12096,19109#msg-19109 I'm attaching in this post the 3.17 patch which includes theby bodhi - Debian
@Eddie, Buttzy is having the same problem here: http://forum.doozan.com/read.php?2,12096,19102#msg-19102 Unfortunately, I'm away and dont have access to my NSA325. So I can only look for the problem in source code. Perhaps you should downgrade to 3.16 temporarily if you need the 2nd HDD.by bodhi - Debian
Buttzy10169 Wrote: ------------------------------------------------------- > Bodhi, > > But even with the boot that I got that boot log > from the second sata is not showing up in Debian. Ah, I see. This is all you got: [ 2.942640] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300) [ 2.982679] ata1.00: ATA-8: Hitachi HDS722020ALA330, JKAOA28A, max UDMA/133 [by bodhi - Debian
Buttzy, I looked at the DTS. This looks OK (is actually HDD2_POWER, GPIO 47) > + sata1_power: regulator@3 { > + compatible = "regulator-fixed"; > + reg = <3>; > + regulator-name = "SATA1 Power"; > + regulator-min-microvolt = <5000000>; > + regulator-max-microvolt = <5000000>; > + regulator-always-on; > + regby bodhi - Debian
bastel Wrote: ------------------------------------------------------- > I posted it in the u-boot thread, but now I think > it rather belongs here: > http://forum.doozan.com/read.php?3,12381,19091#msg > -19091 > I have the same problem, usb is not powered after > kernel start, thus usb boot device is missing. If you have serial console log, please post here.by bodhi - Debian
Thanks Buttzy! I'll take a closer look. My NSA325 has only one HDD installed, so I might have missed this.by bodhi - Debian
ldoolitt, linux-image-3.14.0-kirkwood-tld-1 is the kernel image which is included in my kernel released tarball linux-3.14.0-kirkwood-tld-1-bodhi.tar.bz2. Debian-3.14.0-kirkwood-tld-1-rootfs-bodhi.tar.bz2 is the rootfs tarball. The 1st post of this thread describes the process how to install kernel and/or rootfs. These are my ongoing released Kirkwood kernel builds. tld-xx is my own conveby bodhi - Debian
JohnW, Glad you've figured it out! Indeed, we always need the original nanddump command to restore it with nandwrite correctly.by bodhi - uBoot
WyoGuy, I've started a new thread: http://forum.doozan.com/read.php?3,19093 This problem occured when the booting is still in phase 1: QuoteIt never appears to go through the partitions that it found and look for the "rootfs" label at all as far as I can tell. However, I do see three messages saying: "Wrong Image Format for bootm command" (making me think thaby bodhi - uBoot
I've released 2 new u-boot envs image (for Kirkwood and Oxnas) that will automate the booting process in a multiple-partition multiple-drive configuration. There is no need to set it up manually if you've installed new u-boot and flashed this default env image. Kirkwood U-Boot default environment image Oxnas U-Boot default environment image The discussion below are kept here forby bodhi - uBoot
JohnW, > As we all know on the Pogoplug V4, the original > U-Boot envs are stored at address A5000 (dec > 675840) in mtd0. Not true. > > However when backing up mtd0 from Debian, the > original envs are now located at A0000 (dec > 655360). How come? > It is at A0000.by bodhi - uBoot
FelipeC, See this thread: http://forum.doozan.com/read.php?3,16789,16789#msg-16789by bodhi - uBoot
ldoolitt, > I know from first-hand experience that mounting > partitions based on disk labels can have huge > advantages when multiple devices can be present, > such as USB or SATA. I'm not convinced a pogoplug > with a single SD slot qualifies. It does not matter SD, USB, or SATA. See my post in the other thread: http://forum.doozan.com/read.php?3,19055,19082#msg-by bodhi - uBoot
WyoGuy, Glad you got it working! However, FWIW, the physical placement of the drives is not a real solution. It will work in your current configuration, but once you start adding another drive to the hub, all bets are off. The only foolproof solution is to use a label. Using UUID also works quite well, but also has a flaw in that replacement of the physical boot drive will mess up the UUIDby bodhi - uBoot
ldoolitt, > 2. How to boot from mmcblk0p1 in the presence of > mmcblk0p2. This is covered in the link I posted above about using partition label.by bodhi - uBoot