Kirkwood U-boot - Getting all supported Kirkwoods on-board

Now if we could get it to support uEnv.txt .

WarheadsSE Wrote:
-------------------------------------------------------
> Now if we could get it to support uEnv.txt .

It is already in my latest local build for 2014.07 (have not realeased or pushed to GitHub yet). The load command is common to all boxes, so I've been holding off on that and it wil be automatically picked up when we rebase this to 2014.07.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 09/12/2014 04:04PM by bodhi.

Right, I mean we should get the default environments to do this load.

Understood. But uEnv.txt loading will work only if the load command is available in U-boot. It was not enabled in u-boot-kirkwood 2013.10 branch.

There was a conflict between the generic FS load/ls with the jffs2 flsload/ls and I did not try to resolve it in 2013.10 branch. I've fixed it in my local 2014.07 build to enable load command, and will push a new version to the 2014.07 branch.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@WarheadsSE,

So do you want to do the rebase first, and then merge. Or, do you expect we will stay with 2013.10 branch for the NSAxxx for a long while?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I would say lets get this in, then bringing it up to 2014.x shouldn't be all that hard.

I've got an NSA325 and tried to boot the uart uboot.
It starts to load the uart uboot but fails.
I noticed something during tese tests. I start kwboot and then power on the NSA325.
As I watched the progress I noticed that the power led comes on for a short time then goes off. As close as I can tell that's when the kwboot fails with the xmodem protocol error.
Has anyone else seen the power led come on, then off and then on again???
If I just monitor the console output from the box there's NO output until sometime (a few seconds) after the power led comes on and stays on.
I also noticed that when I stop u-boot before it loads the image, the box resets spontaneously after about 15 seconds.
Could this be a case of the watchdog firing??
I see this behaviour when I'm using a Prolific Technology, Inc. PL2303 Serial Port which does NOT connect to the +3.3 volts from the NSA325.

See the attached file.

When I use a KEYSPAN usb to rs232 adapter and a MAX3232P adapter (which I've used for years with various routers and prototype boards) I get:

i1720 NSA325 # ./kwboot -t -B 115200 /dev/ttyUSB0 -b ./uboot.2013.10-tld-1.nsa325.uart.kwb -p
Sending boot message. Please reboot the target.../
Sending boot image...
xmodem: Bad message
i1720 NSA325 #

every time. It seems that the short loss of 3.3volts to the MAX2323 kills the process. Of course it would, the 3.3v from the box will stop transmission.

Herb

@herb,

The new u-boot kills the watchdog at the moment u-boot starts. To download the latest pre-release nsa325 u-boot:
http://forum.doozan.com/read.php?3,12381,17420#msg-17420

What you saw were the watchdog behaviour and have been discussed and analyzed thoroughly in this thread:
http://forum.doozan.com/read.php?2,14351

Quote

Has anyone else seen the power led come on, then off and then on again

This is the expected behavior for the NSA325.

The correct way to start UART booting is:

- Prepare the kwboot command on the terminal, but don't execute yet.
- Push the power button, wait until it comes OFF, and when it's ON again, hit return to execute kwboot command.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 09/14/2014 04:23PM by bodhi.

@WarheadsSE,

Yeah. It's kind of a pain to revisit the default envs for other boxes :) Some are OK, but a majority need to be rewritten. Perhaps now is the time to do it.

I've looked at what Kevin did for Arch mainline U-boot, and I think it is really nice and flexible. I've tempted to cut and paste those in, but decided otherwise. I'd like to keep the envs as simple and easy to modify as possible for people who want to hack them without much knowledge about u-boot.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@WarheadsSE,

Attached here is the latest changes I've made to the nsa325 u-boot. This has the uEnv.txt loading capability implemented and scripted in the default envs. I hope this is all we need to go forward to the GitHub update?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I will try to have a look in the next few days.

got the same behaviour as herb above.

Basically trying to load uboot using UART and waiting for the power on-off-on sequence as described by bodhi I get watchdog reset in about 30sec. This means it loads 56-58% with end result ... xmodem protocol error

SO

is the sequence to update uboot:
1 - make debian bootable using stock uboot
2 - from within debian using nand flash, update uboot (without checking, although it appears tested somehow ...)
3 - update debian/env to match updated uboot

is the sequence to get latest kernel/uboot etc correct?

By updating debian I mean, installing:
linux-3.16.0-kirkwood-tld-2-bodhi.tar.bz2
Debian-3.16.0-kirkwood-tld-2-rootfs-bodhi.tar.bz2

as written by Bodhi on this post:
http://forum.doozan.com/read.php?2,12096



Edited 1 time(s). Last edit at 10/03/2014 04:55AM by rasto.

rasto,

> is the sequence to update uboot:
> 1 - make debian bootable using stock uboot
> 2 - from within debian using nand flash, update
> uboot (without checking, although it appears
> tested somehow ...)
> 3 - update debian/env to match updated uboot
>
> is the sequence to get latest kernel/uboot etc
> correct?
>
> By updating debian I mean, installing:
> linux-3.16.0-kirkwood-tld-2-bodhi.tar.bz2
> Debian-3.16.0-kirkwood-tld-2-rootfs-bodhi.tar.bz2
>
>
> as written by Bodhi on this post:
> http://forum.doozan.com/read.php?2,12096

Yes. And Debian first on a USB thumb drive, with no other disk attached (to survive the watchdog).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@WarheadsSE,

Do you have the DTS for the NSA325? I'm starting to build kernel 3.17 and I realized that we need NSA325, Pogo V4, and Netgear Stora DTS to build the common Kirkwood armv5 kernel. Between mainline and ALARM, the other boxes DTS are already available.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Nope, don't have a DTS.

bodhi Wrote:
-------------------------------------------------------
> @WarheadsSE,
>
> Do you have the DTS for the NSA325? I'm starting
> to build kernel 3.17 and I realized that we need
> NSA325, Pogo V4, and Netgear Stora DTS to build
> the common Kirkwood armv5 kernel. Between
> mainline and ALARM, the other boxes DTS are
> already available.


I've created a Pogo v4 device tree (also working for mobile) from ALARM board files a while ago. It's for 3.16, but should work on 3.17 without modifications. However, there are two minor problems:

• ALARM board file had a SPI flash definition. However, Pogo v4 does not have any flash chip on board; the chip definition is in the dts, but I think it should be dropped.
• I couldn't get the usb power enable regulator to work without it breaking serial connection. I think the regulator pin is wrong, but I don't know the right one. I wrapped these parts in comments. Powering a usb hdd works fine though.

In case you're interested, here's kirkwood-pogoplug-v4.dts:

/dts-v1/;

#include "kirkwood.dtsi"
#include "kirkwood-6192.dtsi"

/ {
	model = "Pogoplug v4";
	compatible = "cloudengines,pogoplug-v4", "cloudengines,pogoplug-mobile", "marvell,kirkwood-88f6192", "marvell,kirkwood";

	memory {
		device_type = "memory";
		reg = <0x00000000 0x8000000>;
	};

	chosen {
		bootargs = "console=ttyS0,115200";
		stdout-path = &uart0;
	};

	mbus {
		pcie-controller {
			status = "okay";

			pcie@1,0 {
				status = "okay";
			};
		};
	};

	ocp@f1000000 {
		pinctrl: pin-controller@10000 {
			pmx_led_green: pmx-led-green {
				marvell,pins = "mpp22";
				marvell,function = "gpio";
			};
			pmx_led_red: pmx-led-red {
				marvell,pins = "mpp24";
				marvell,function = "gpio";
			};
			pmx_button_eject: pmx-button-eject {
				marvell,pins = "mpp29";
				marvell,function = "gpio";
			};
			/*pmx_usb_power_enable: pmx-usb-power-enable {
				marvell,pins = "mpp29";
				marvell,function = "gpio";
			};*/
		};

		spi@10600 {
			status = "okay";

			m25p05@0 {
				#address-cells = <1>;
				#size-cells = <1>;
				compatible = "m25p05-nonjedec";
				reg = <0>;
				spi-max-frequency = <20000000>;
				mode = <0>;
			};
		};

		serial@12000 {
			status = "ok";
		};

		sata@80000 {
			status = "okay";
			nr-ports = <1>;
			phys = <&sata_phy0>;
			phy-names = "port0";
		};

		mvsdio@90000 {
			pinctrl-0 = <&pmx_sdio>;
			pinctrl-names = "default";
			status = "okay";
			cd-gpios = <&gpio0 27 GPIO_ACTIVE_HIGH>;
			/* No WP GPIO */
		};
	};

	gpio-leds {
		compatible = "gpio-leds";
		pinctrl-0 = <&pmx_led_red &pmx_led_green>;
		pinctrl-names = "default";

		health {
			label = "status:green:health";
			gpios = <&gpio0 22 GPIO_ACTIVE_LOW>;
			default-state = "keep";
		};
		fault {
			label = "status:red:fault";
			gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
		};
	};

	gpio_keys {
		compatible = "gpio-keys";
		#address-cells = <1>;
		#size-cells = <0>;
		pinctrl-0 = <&pmx_button_eject>;
		pinctrl-names = "default";

		button@1 {
			label = "Eject Button";
			linux,code = <KEY_EJECTCD>;
			gpios = <&gpio0 29 GPIO_ACTIVE_LOW>;
		};
	};

	/*regulators {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <0>;
		pinctrl-0 = <&pmx_usb_power_enable>;
		pinctrl-names = "default";

		usb_power: regulator@1 {
			compatible = "regulator-fixed";
			reg = <1>;
			regulator-name = "USB Power";
			regulator-min-microvolt = <5000000>;
			regulator-max-microvolt = <5000000>;
			enable-active-high;
			regulator-always-on;
			regulator-boot-on;
			gpio = <&gpio0 29 GPIO_ACTIVE_HIGH>;
		};
	};*/
};

&nand {
	status = "okay";

	partition@0 {
		label = "u-boot";
		reg = <0x0000000 0x200000>;
		read-only;
	};

	partition@200000 {
		label = "uImage";
		reg = <0x200000 0x300000>;
	};

	partition@500000 {
		label = "uImage2";
		reg = <0x500000 0x300000>;
	};

	partition@800000 {
		label = "failsafe";
		reg = <0x800000 0x800000>;
	};

	partition@1000000 {
		label = "root";
		reg = <0x1000000 0x7000000>;
	};
};

&mdio {
	status = "okay";

	ethphy0: ethernet-phy@0 {
		reg = <0>;
	};
};

&eth0 {
	status = "okay";
	ethernet0-port@0 {
		phy-handle = <&ethphy0>;
	};
};

Would like to hear about any improvements (do you know why ALARM included this SPI nor flash chip or how to fix the regulator?).

ebbix,

Cool! thanks for posting this. I've also noticed about the SPI flash but have not looked into that, and sorry no idea about the USB regulator. If I find anything I will post.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

ebbix,

I've looked for why the SPI flash is included. It was included in the stock u-boot and kernel. I think it was just there in the CE build and CE did not remove it. We've seen the same with wifi driver on the Mobile. And ALARM devs must have used whatever in the GPL and rebuilt u-boot and kernel from that. I think we should remove it, too.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@ebbix,

Thanks, the DTS works great! I've removed SPI definition, recompiled the DTB and ran it without problem. The only minor thing is the 14 non-existent pinctrl that showed up in dmesg

[    1.019198] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 36
[    1.019220] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 37
[    1.019236] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 38
[    1.019253] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 39
[    1.019270] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 40
[    1.019287] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 41
[    1.019303] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 42
[    1.019320] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 43
[    1.019337] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 44
[    1.019353] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 45
[    1.019369] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 46
[    1.019386] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 47
[    1.019403] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 48
[    1.019419] kirkwood-pinctrl f1010000.pin-controller: unknown pinctrl group 49
[    1.019924] kirkwood-pinctrl f1010000.pin-controller: registered pinctrl driver

I have not digged in deep, but I thought it is strange because you are using kirkwood-6192.dtsi. It would make sense if it were 6182.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Yep, these groups aren't available on 6192, using 6181 fixes it. That actually was the main dtsi I was using before upstream added 6192 file.
As far as I recall the problem was in pinctrl-kirkwood.c, line 424. nmodes is the same for all kirkwood devices although 6192 requires a lower number - resulting in these warnings. But in my opinion, they really aren't any problem, so you could simply ignore them.

Concerning SPI flash: as far as I read some Netgear NAS actually has SPI flash onboard. However, it is used to store its USB 3.0 controller configuration and is not connected to the system SPI bus at all. Maybe that's what happened on early development boards? Do you have a working stock kernel? If so, you could try writing some random values to this SPI flash via sysfs and read it back. If null bytes are the only thing you receive, the chip most probably doesn't exist.

ebbix,

> Concerning SPI flash: as far as I read some
> Netgear NAS actually has SPI flash onboard.
> However, it is used to store its USB 3.0
> controller configuration and is not connected to
> the system SPI bus at all. Maybe that's what
> happened on early development boards? Do you have
> a working stock kernel? If so, you could try
> writing some random values to this SPI flash via
> sysfs and read it back. If null bytes are the only
> thing you receive, the chip most probably doesn't
> exist.

Interesting! I don't have working stock kernel, but I have a spared Pogo Mobile and a set of orginal mtd dumps.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi

I've got an NSA325 and it runs arch linux fine. I've switched to debian but the watchdog always kicks in on boot - can someone point me to a kernel image that disables the watchdog please? I've tried loads without success.

Many thanks
Gareth

@Gareth,

If you are running with stock u-boot then use Kernel 3.16.0-kirkwood-tld-2 (Updated 02 Sept 2014) in my kernel thread.

Newer kernel in the thread will need newer u-boot.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

thanks for taking the time to reply. I've just installed that kernel but the watchdog still triggers.

If I boot the old arch kernel first and then reboot into the debian kernel (without poweroff) and it works - but none of the debian kernels seem to switch the watchdog off not even the one you just suggested it seems. Tearing my hair out :-)

I tried using the uboot over UART but it refused to take using kwboot.

Best
Gareth

Gareth,

- Try booting kernel 3.16 with USB thumb drive only.
- UART booting the NSA325 is quirky. You need to press power button, wait for it to turn off, then on again, and then execute kwboot within 1 second.

All else fails, you can post the entire serial console log here.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 01/12/2015 02:19PM by bodhi.

@drdevil: I could send you a working 3.18.2 Kernel with arch-patches. But it would be better if you use bodhi's u-boot for nsa325, too. I am using a micro usb-stick for wheezy.

Actually, I would like Gareth to try 3.16-tld-2 or earlier if booting stock u-boot, and 3.17-tld-1 if booting new u-boot. It would help others to know what to do when they have watchdog problem. It's great that 3.18 works, however it will benefit only a few :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi

I'm afraid I haven't got a huge amount of time at the moment to play around with it - at present I've left the serial console attached and am booting arch then rebooting into debian when the power fails. I've tried 3.16-tld-2 on the hard disk but the watchdog still fires - I'm not too keen to use up a USB stick to fix the problem.

So balou1974, if you have a precompiled kernel and modules with the arch patch I'd be very grateful - I haven't had time to set up the cross compile environment myself thus far.

bodhi - I had a good try following your suggestions re flashing a new uboot but couldn't get the uart to trigger even once. I dont want to risk bricking it without verifying it works first so looks like I'm stuck on an old u-boot.

Best
Gareth

Gareth,

Whatever works for you is good!

The reason I'd suggested USB because if you can't boot 3.16-tld-2 on HDD then chance is that you will still have the same problem no matter which kernel you can try. The Arch patch is basically the same as my patch. In fact, that's where my NSA325 section of the patch came from (WarheadsSE is the developer for all things non-FDT NSA325). I've just not been thorough enough to make this fact clear in all posts.

Sometime a particular HDD model spinning up speed is too slow that the kernel can't get to the part where it can shutdown the watchdog before it fires. The new u-boot kills it during boot, so the kernel does not have to.

UART booting with NSA325 works consistenly, with some quirks. If you'd like, when you have time to get back to this, just post the entire log of how you tried it and failed, and I'll help.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 01/14/2015 05:26AM by bodhi.

bodhi

Thanks for your offer of help - may take that up on the weekend! The system is booting well into the init scripts and getting pretty close to the login prompt - so I'm not sure why the kernel isn't switching off the watchdog. The arch kernel works flawlessly.

I tried to trip GPIO 14 in userspace but it wasn't allowed - I also had a quick look at the patches and had assumed this was done pre-kernel init (although I'm not at all familiar with the board modules).

Best
Gareth