All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] Rockchip RK3288 u-boot with mainline kernel
@ 2016-12-01 19:00 Rick Bronson
  2016-12-01 21:01 ` Heiko Stuebner
  0 siblings, 1 reply; 14+ messages in thread
From: Rick Bronson @ 2016-12-01 19:00 UTC (permalink / raw)
  To: u-boot

Hi Heiko,

> I'm currently testing Simon's network patches and this option works
> quite nicely.

  Speaking of networking, I noticed that rk3288 networking is not quite
merged yet.  I would very much like to have networking so if you could
point me to any rk3288 networking patches, I'd appreciate it.

  Thanks much.

  Rick

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [U-Boot] Rockchip RK3288 u-boot with mainline kernel
@ 2016-12-06  0:56 Rick Bronson
  2016-12-07  3:48 ` Simon Glass
  0 siblings, 1 reply; 14+ messages in thread
From: Rick Bronson @ 2016-12-06  0:56 UTC (permalink / raw)
  To: u-boot

Hi Heiko,

  Thanks again for the help.

  Been testing the RK3288 Ethernet and it works pretty good.  One
thing I was wondering about was that I seemed to have to have:

CONFIG_NET_RANDOM_ETHADDR=y

  or I get:

Error: ethernet at ff290000 address not set.

  Is there a better way?

  Another issue we were having is when attached to a Gigabit
switch/router it seemed to have a lot of trouble negociating and would
fail often.  So, for the time being, I've hooked it to a 100MBit
router.  Haven't seen any problems with that.  Just wondered if you
have observed this behavior?

  Thanks,

 Rick

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [U-Boot] Rockchip RK3288 u-boot with mainline kernel
@ 2016-12-03 18:07 Rick Bronson
  2016-12-03 21:24 ` Heiko Stuebner
  0 siblings, 1 reply; 14+ messages in thread
From: Rick Bronson @ 2016-12-03 18:07 UTC (permalink / raw)
  To: u-boot

Hi Heiko,

  Thanks very much for the link.  I got it, went to the branch,
applied my patches from main denx u-boot and got it to work!

  The only odd thing is, I have to do this:

regulator dev vcc_lan
regulator enable

  Or else I can't use the networking.

  When I boot up I see:

=> regulator status
Name                 Enabled            uV         mA Mode
...
vcc_lan              disabled            -          - -

  I've studied all of the various rk3288*.dts* examples but have no
idea why the vcc_lan does not start up upon boot.  My dtsi file is
below.  Thanks for any help.

  Cheers,

  Rick

#include "rk3288.dtsi"

/ {
	memory {
		device_type = "memory";
		reg = <0x0 0x80000000>;
	};

	ext_gmac: external-gmac-clock {
		compatible = "fixed-clock";
		clock-frequency = <125000000>;
		clock-output-names = "ext_gmac";
		#clock-cells = <0>;
	};

	gpio-keys {
		compatible = "gpio-keys";
		#address-cells = <1>;
		#size-cells = <0>;
		autorepeat;

		pinctrl-names = "default";
		pinctrl-0 = <&pwrbtn>;

		button at 0 {
			gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
			label = "GPIO Key Power";
			linux,input-type = <1>;
			gpio-key,wakeup = <1>;
			debounce-interval = <100>;
		};
	};

	leds {
		u-boot,dm-pre-reloc;
		compatible = "gpio-leds";

		power {
			u-boot,dm-pre-reloc;
			gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>;
			label = "sct36:blue:power";
			linux,default-trigger = "default-on";
			pinctrl-names = "default";
			pinctrl-0 = <&power_led>;
			default-state = "on";
		};

		work {
			u-boot,dm-pre-reloc;
			gpios = <&gpio7 0 GPIO_ACTIVE_HIGH>;
			label = "sct36:amber:user";
			linux,default-trigger = "rc-feedback";
			pinctrl-names = "default";
			pinctrl-0 = <&work_led>;
		};
	};

	vcc_sys: vsys-regulator {
		compatible = "regulator-fixed";
		regulator-name = "vcc_sys";
		regulator-min-microvolt = <5000000>;
		regulator-max-microvolt = <5000000>;
		regulator-always-on;
		regulator-boot-on;
	};

	/*
	 *
	 */
	vcc_sd: sdmmc-regulator {
		compatible = "regulator-fixed";
		regulator-name = "vcc_sd";
		regulator-min-microvolt = <3300000>;
		regulator-max-microvolt = <3300000>;
		startup-delay-us = <100000>;
		vin-supply = <&vcc_io>;
	};
};

&cpu0 {
	cpu0-supply = <&vdd_cpu>;
};

&emmc {
	broken-cd;
	bus-width = <8>;
	cap-mmc-highspeed;
	disable-wp;
	non-removable;
	num-slots = <1>;
	pinctrl-names = "default";
	pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_pwr>, <&emmc_bus8>;
	vmmc-supply = <&vcc_io>;
	vqmmc-supply = <&vccio_sd>;
	status = "okay";
};

&sdmmc {
	bus-width = <4>;
	cap-mmc-highspeed;
	cap-sd-highspeed;
	card-detect-delay = <200>;
	disable-wp;			/* wp not hooked up */
	num-slots = <1>;
	pinctrl-names = "default";
	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
	supports-sd;
	vmmc-supply = <&vcc_sd>;
	vqmmc-supply = <&vccio_sd>;
	status = "okay";
};

&gpu {
	mali-supply = <&vdd_gpu>;
	status = "okay";
};

&gmac {
	assigned-clocks = <&cru SCLK_MAC>;
	assigned-clock-parents = <&ext_gmac>;
	clock_in_out = "input";
	pinctrl-names = "default";
	pinctrl-0 = <&rgmii_pins>, <&phy_rst>, <&phy_pmeb>, <&phy_int>;
	phy-supply = <&vcc_lan>;
	phy-mode = "rgmii";
	snps,reset-active-low;
	snps,reset-delays-us = <0 10000 1000000>;
	snps,reset-gpio = <&gpio4 8 GPIO_ACTIVE_LOW>;
	tx_delay = <0x30>;
	rx_delay = <0x10>;
	status = "okay";
};

&hdmi {
	ddc-i2c-bus = <&i2c5>;
	status = "okay";
};

&i2c0 {
	status = "okay";
	clock-frequency = <400000>;

	rk808: pmic at 1b {
		compatible = "rockchip,rk808";
		reg = <0x1b>;
		interrupt-parent = <&gpio0>;
		interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
		pinctrl-names = "default";
		pinctrl-0 = <&pmic_int &global_pwroff>;
		rockchip,system-power-controller;
		wakeup-source;
		#clock-cells = <1>;
		clock-output-names = "xin32k", "rk808-clkout2";

		vcc1-supply = <&vcc_sys>;
		vcc2-supply = <&vcc_sys>;
		vcc3-supply = <&vcc_sys>;
		vcc4-supply = <&vcc_sys>;
		vcc6-supply = <&vcc_sys>;
		vcc7-supply = <&vcc_sys>;
		vcc8-supply = <&vcc_sys>;
		vcc9-supply = <&vcc_sys>;
		vcc10-supply = <&vcc_sys>;
		vcc11-supply = <&vcc_sys>;
		vcc12-supply = <&vcc_sys>;
		vddio-supply = <&vcc_io>;

		regulators {
			vdd_cpu: DCDC_REG1 {
				regulator-always-on;
				regulator-boot-on;
				regulator-min-microvolt = <750000>;
				regulator-max-microvolt = <1350000>;
				regulator-name = "vdd_arm";
				regulator-state-mem {
					regulator-off-in-suspend;
				};
			};

			vdd_gpu: DCDC_REG2 {
				regulator-always-on;
				regulator-boot-on;
				regulator-min-microvolt = <850000>;
				regulator-max-microvolt = <1250000>;
				regulator-name = "vdd_gpu";
				regulator-state-mem {
					regulator-on-in-suspend;
					regulator-suspend-microvolt = <1000000>;
				};
			};

			vcc_ddr: DCDC_REG3 {
				regulator-always-on;
				regulator-boot-on;
				regulator-name = "vcc_ddr";
				regulator-state-mem {
					regulator-on-in-suspend;
				};
			};

			vcc_io: DCDC_REG4 {
				regulator-always-on;
				regulator-boot-on;
				regulator-min-microvolt = <3300000>;
				regulator-max-microvolt = <3300000>;
				regulator-name = "vcc_io";
				regulator-state-mem {
					regulator-on-in-suspend;
					regulator-suspend-microvolt = <3300000>;
				};
			};

			vcc33_ldo1: LDO_REG1 {
				regulator-always-on;
				regulator-boot-on;
				regulator-min-microvolt = <3300000>;
				regulator-max-microvolt = <3300000>;
				regulator-name = "vcc33_ldo1";
				regulator-state-mem {
					regulator-on-in-suspend;
					regulator-suspend-microvolt = <3300000>;
				};
			};

			vdd_10: LDO_REG3 {
				regulator-always-on;
				regulator-boot-on;
				regulator-min-microvolt = <1000000>;
				regulator-max-microvolt = <1000000>;
				regulator-name = "vdd_10";
				regulator-state-mem {
					regulator-on-in-suspend;
					regulator-suspend-microvolt = <1000000>;
				};
			};

			vccio_sd: LDO_REG4 {
				regulator-always-on;
				regulator-boot-on;
				regulator-min-microvolt = <1800000>;
				regulator-max-microvolt = <3300000>;
				regulator-name = "vccio_sd";
				regulator-state-mem {
					regulator-on-in-suspend;
					regulator-suspend-microvolt = <3300000>;
				};
			};

			vcc33_sd: LDO_REG5 {
				regulator-always-on;
				regulator-boot-on;
				regulator-min-microvolt = <3300000>;
				regulator-max-microvolt = <3300000>;
				regulator-name = "vcc33_sd";
				regulator-state-mem {
					regulator-on-in-suspend;
					regulator-suspend-microvolt = <3300000>;
				};
			};

			vcc18_codec: LDO_REG6 {
				regulator-always-on;
				regulator-boot-on;
				regulator-min-microvolt = <1800000>;
				regulator-max-microvolt = <1800000>;
				regulator-name = "vcc18_codec";
				regulator-state-mem {
					regulator-on-in-suspend;
					regulator-suspend-microvolt = <1800000>;
				};
			};

			vdd10_lcd: LDO_REG7 {
				regulator-name = "vdd10_lcd";
				regulator-min-microvolt = <1000000>;
				regulator-max-microvolt = <1000000>;
				regulator-always-on;
			};

			vcc33_ccd: LDO_REG8 {
				regulator-always-on;
				regulator-boot-on;
				regulator-min-microvolt = <3300000>;
				regulator-max-microvolt = <3300000>;
				regulator-name = "vcc33_ccd";
				regulator-suspend-mem-disabled;
			};

			vcc_lcd: SWITCH_REG1 {
				regulator-always-on;
				regulator-boot-on;
				regulator-name = "vcc_lcd";
				regulator-state-mem {
					regulator-on-in-suspend;
				};
			};

			vcc_lan: SWITCH_REG2 {
				regulator-always-on;
				regulator-boot-on;
				regulator-name = "vcc_lan";
				regulator-state-mem {
					regulator-on-in-suspend;
				};
			};
		};
	};
};

&i2c2 {
	status = "okay";
	headset: nau8825 at 1a {
		compatible = "nuvoton,nau8825";
		#sound-dai-cells = <0>;
		reg = <0x1a>;
		interrupt-parent = <&gpio6>;
		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
		nuvoton,jkdet-enable = <1>;
		nuvoton,jkdet-pull-enable = <1>;
		nuvoton,jkdet-pull-up = <0>;
		nuvoton,jkdet-polarity = <1>;
		nuvoton,vref-impedance = <2>;
		nuvoton,micbias-voltage = <6>;
		nuvoton,sar-threshold-num = <4>;
		nuvoton,sar-threshold = <0xa 0x14 0x26 0x73>;
		nuvoton,sar-hysteresis = <0>;
		nuvoton,sar-voltage = <6>;
		nuvoton,sar-compare-time = <0>;
		nuvoton,sar-sampling-time = <0>;
		nuvoton,short-key-debounce = <3>;
		nuvoton,jack-insert-debounce = <7>;
		nuvoton,jack-eject-debounce = <7>;
		clock-names = "mclk";
		clocks = <&cru SCLK_I2S0_OUT>;
	};
};

&i2c5 {
	status = "okay";
};

&wdt {
	status = "okay";
};

&pwm0 {
	status = "okay";
};

&uart0 {
	status = "okay";
};

&uart1 {
	status = "okay";
};

&uart2 {
	status = "okay";
};

&uart3 {
	status = "okay";
};

&uart4 {
	status = "okay";
};

&tsadc {
	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
	status = "okay";
};

&usbphy {
	status = "okay";
};

&usb_host0_ehci {
	status = "okay";
};

&usb_host1 {
	status = "okay";
};

&usb_otg {
	status= "okay";
};

&vopb {
	status = "okay";
};

&vopb_mmu {
	status = "okay";
};

&vopl {
	status = "okay";
};

&vopl_mmu {
	status = "okay";
};

&pinctrl {
	pcfg_pull_none_drv_8ma: pcfg-pull-none-drv-8ma {
		drive-strength = <8>;
	};

	pcfg_pull_up_drv_8ma: pcfg-pull-up-drv-8ma {
		bias-pull-up;
		drive-strength = <8>;
	};

	pcfg_output_high: pcfg-output-high {
		output-high;
	};

	pcfg_output_low: pcfg-output-low {
		output-low;
	};

	buttons {
		pwrbtn: pwrbtn {
			rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
		};
	};

	leds {
		power_led: power-led {
			rockchip,pins = <0 11 RK_FUNC_GPIO &pcfg_pull_none>;
		};

		work_led: work-led {
			rockchip,pins = <7 0 RK_FUNC_GPIO &pcfg_pull_none>;
		};
	};

	pmic {
		pmic_int: pmic-int {
			rockchip,pins = <RK_GPIO0 4 RK_FUNC_GPIO &pcfg_pull_up>;
		};
	};

	sdmmc {
		/*
		 * Default drive strength isn't enough to achieve even
		 * high-speed mode on EVB board so bump up to 8ma.
		 */
		sdmmc_bus4: sdmmc-bus4 {
			rockchip,pins = <6 16 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
					<6 17 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
					<6 18 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
					<6 19 RK_FUNC_1 &pcfg_pull_up_drv_8ma>;
		};

		sdmmc_clk: sdmmc-clk {
			rockchip,pins = <6 20 RK_FUNC_1 &pcfg_pull_none_drv_8ma>;
		};

		sdmmc_cmd: sdmmc-cmd {
			rockchip,pins = <6 21 RK_FUNC_1 &pcfg_pull_up_drv_8ma>;
		};

	};

	gmac {
		phy_int: phy-int {
			rockchip,pins = <0 8 RK_FUNC_GPIO &pcfg_pull_up>;
		};

		phy_pmeb: phy-pmeb {
			rockchip,pins = <0 7 RK_FUNC_GPIO &pcfg_pull_up>;
		};

		phy_rst: phy-rst {
			rockchip,pins = <4 8 RK_FUNC_GPIO &pcfg_output_high>;
		};
	};

	usb {
		host_vbus_drv: host-vbus-drv {  /* note: 2 10 us USB2, 2 11 is USB3 */
			rockchip,pins = <2 10 RK_FUNC_GPIO &pcfg_pull_none>, <2 11 RK_FUNC_GPIO
&pcfg_pull_none>;
		};

		pwr_3g: pwr-3g {
			rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
		};
	};
};

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [U-Boot] Rockchip RK3288 u-boot with mainline kernel
@ 2016-11-29 22:50 Rick Bronson
  0 siblings, 0 replies; 14+ messages in thread
From: Rick Bronson @ 2016-11-29 22:50 UTC (permalink / raw)
  To: u-boot

Hi Heiko and Simon,

  Again, thank you both for your help, I really appreciate it!

  The good news is that I finally got it to boot fully into mainline
u-boot.  I switched gears and tried miniarm-rk3288_defconfig which
doesn't use the CONFIG_SPL_OF_PLATDATA option.  So now my build looks
like:

u-boot-denx:
	cd $@; make miniarm-rk3288_defconfig CROSS_COMPILE="${CROSS_COMPILE}"
	cd $@; make ${MK_PAR} all CROSS_COMPILE="${CROSS_COMPILE}"
	$@/tools/mkimage -n rk3288 -T rksd -d $@/spl/u-boot-spl-dtb.bin
tftpboot/u-boot-dtb.bin; cat $@/u-boot-dtb.bin >> tftpboot/u-boot-dtb.bin

  and my flash looks like:

UPGD=./Linux_Upgrade_Tool_v1.21/upgrade_tool
	sudo ${UPGD} db rkbin/rk32/rk3288_boot.bin
	sleep 1
	sudo ${UPGD} wl 64 tftpboot/u-boot-dtb.bin
	sudo ${UPGD} rd

  So I'm pretty excited :)

  The strange thing is I still don't have emmc or my LED turning on
  from the device tree entry in rk3288-miniarm.dtsi (which I modified
  for my LED [ on GPIO0_B3]):

		pwr-led {
			gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "default-on";
		};

  Below is what I see when I boot.

  Cheers,

  Rick


U-Boot SPL 2016.11-00138-g136179b-dirty (Nov 29 2016 - 14:19:08)


U-Boot 2016.11-00138-g136179b-dirty (Nov 29 2016 - 14:19:08 -0800)

Model: Miniarm-RK3288
DRAM:  2 GiB
MMC:   dwmmc at ff0c0000: 0
Card did not respond to voltage select!
*** Warning - MMC init failed, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot:  0
=> md 0xFF750000 4
ff750000: 00000000 00000000 00000000 00000000    ................
=> md 0xFF790000 4
ff790000: 00000000 00000000 00000000 00000000    ................
=>


> Hi Rick,
>
> On 29 November 2016 at 11:22, Rick Bronson <rick@efn.org> wrote:
> > Hi Heiko and Simon,
> >
> >   Thank you both for your help, I really appreciate it.
> >
> >   No, I do not have the Linux mainline running yet as I was focusing
> > on getting the mainline u-boot running since I saw some references
> > that implied I may need that to use the mainline Linux.  I did try the
> > mainline kernel with the vendor-fork u-boot but got nothing pas the
> > "Loading Linux...." line from u-boot.
> >
> >   I think what I will probably do is take the easy way out and use the
> > vendor-fork u-boot since that boots on this hardware.
> >
> >   But since I've invested some amount of time in the mainline u-boot
> > and it's drinving me mad that I can't seem to figure out what's wrong,
> > I do have one last question (hopefully).
>
> It would certainly make sense to invest in getting this running if you can.
>
> >
> >   I've got mainline u-boot getting this far (I added debug to show
> > what GPIO0 and 2 are outputting).
> >
> > --------------------
> > U-Boot SPL 2016.11-00138-g136179b-dirty (Nov 28 2016 - 13:29:59)
> > Trying to boot from MMC1
> > Card did not respond to voltage select! GPIO0=0x0 GPIO2=0x0
> > ...
> > --------------------
> >
> >   I've modified rk3288-firefly.dts (the closest thing to hardware I
> > have) to set the eMMC reset line high but as you see above, nothing is
> > set on any GPIO.  This leads me to believe that I do not understand
> > how the device tree is loaded/used in SPL.  Can anyone point me to
> > help on whether I should use u-boot-spl-nodtb or u-boot-spl-dtb (I've
> > tried both) or how to debug if I am in fact even reading my dtb.
>
> You should be able to use 'gpio status' to see the GPIO state once you
> get to U-Boot.
>
> But if your board is booting SPL from MMC how can it possibly fail to
> load U-Boot from MMC? The MMC GPIO must already work for you to get
> this far. Or are you loading SPL from something other than MMC?
>
> You want u-boot-spl.bin (which includes the device tree).
>
> >
> >   Thanks again,
> >
> >   Rick
> >
> > PS.  My Makefile is here if you are so inclined:
> > http://members.efn.org/~rick/pub/Makefile  See the targets u-boot-denx
> > and uboot_new_flash to see what I've tried.
>
> You could push your tree somewhere or a patch showing what changes you
> have made.
>
> Regards,
> Simon
>
> >>
> >> From heiko at sntech.de Tue Nov 29 08:45:02 2016
> >> To: u-boot at lists.denx.de
> >> Cc: Simon Glass <sjg@chromium.org>, Rick Bronson <rick@efn.org>,
> > "eddie.cai" <eddie.cai@rock-chips.com>,
> > linux-rockchip at lists.infradead.org
> >> Subject: Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
> >> Date: Tue, 29 Nov 2016 11:20:52 +0100
> >>
> >> Hi Rick,
> >>
> >> Am Montag, 28. November 2016, 15:09:05 schrieb Simon Glass:
> >> > + A few rockchip people and linux-rockchip
> >> >
> >> > Hi Rick,
> >> >
> >> > On 25 November 2016 at 11:20, Rick Bronson <rick@efn.org> wrote:
> >> > > Hi All,
> >> > >
> >> > >   I've got unsupported RK3288 hardware running the latest git
u-boot to
> >> > >
> >> > > SPL as explained in
> >> > > http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip. 
My goal
> >> > > is to run the mainline (ie. not Android) Linux kernel on this
hardware
> >> > >
> >> > > and wondered:
> >> > >  - Do I need to get the latest git u-boot to run before I can run
the
> >> > >
> >> > > mainline kernel?  Or can I use
> >> > > github.com/linux-rockchip/u-boot-rockchip.git, which I have running
> >> > > u-boot fully.
> >> >
> >> > It's up to you - obviously mainline is where the development should
> >> > be, but there is no requirement that I know of.
> >>
> >> correct, the (mainline-)kernel runs just fine on both the vendor-fork of
> > uboot
> >> as well as on mainline.
> >>
> >>
> >> > Does mainline run on your board?
> >> >
> >> > >  - The device tree seems to be in two places, once via:
> >> > >         resource_tool --image=resource2.img --pack linux/logo.bmp
> >> > >         ${DTS}.dtb
> >> > >
> >> > >   that gets put into the resource file and then again at the end
of the
> >> > >
> >> > > kernel via CONFIG_ARM_APPENDED_DTB.  Do I need both?  When I do both
> >> > > I get things like:
> >> >
> >> > > Unknow param: MACHINE_MODEL:rk30sdk!
> >> > > Unknow param: MACHINE_ID:007!
> >>
> >> ARM_APPEND_DTB is meant for boards where the bootloader cannot load the
> >> devicetree (to old or so) and also cannot be reasonably exchanged. So
the
> >> append-mechanism was invented to allow bundling the devicetree with the
> > actual
> >> kernel image, so that to the bootloader it looks like just any other
kernel
> >> image.
> >>
> >> So you essentially only need one or the other. Also at least mainline
uboot
> >> also supports the FIT image type, where you can bundle the devicetree
in a
> >> more generalized way.
> >>
> >> For your message I would guess the kernel didn't find a usable
devicetree
> >> somehow and was falling back to ATAGS-based board selection?
> >>
> >>
> >
> >
> >

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [U-Boot] Rockchip RK3288 u-boot with mainline kernel
@ 2016-11-29 18:22 Rick Bronson
  2016-11-29 21:40 ` Simon Glass
  0 siblings, 1 reply; 14+ messages in thread
From: Rick Bronson @ 2016-11-29 18:22 UTC (permalink / raw)
  To: u-boot

Hi Heiko and Simon,

  Thank you both for your help, I really appreciate it.

  No, I do not have the Linux mainline running yet as I was focusing
on getting the mainline u-boot running since I saw some references
that implied I may need that to use the mainline Linux.  I did try the
mainline kernel with the vendor-fork u-boot but got nothing pas the
"Loading Linux...." line from u-boot.

  I think what I will probably do is take the easy way out and use the
vendor-fork u-boot since that boots on this hardware.

  But since I've invested some amount of time in the mainline u-boot
and it's drinving me mad that I can't seem to figure out what's wrong,
I do have one last question (hopefully).

  I've got mainline u-boot getting this far (I added debug to show
what GPIO0 and 2 are outputting).

--------------------
U-Boot SPL 2016.11-00138-g136179b-dirty (Nov 28 2016 - 13:29:59)
Trying to boot from MMC1
Card did not respond to voltage select! GPIO0=0x0 GPIO2=0x0
...
--------------------

  I've modified rk3288-firefly.dts (the closest thing to hardware I
have) to set the eMMC reset line high but as you see above, nothing is
set on any GPIO.  This leads me to believe that I do not understand
how the device tree is loaded/used in SPL.  Can anyone point me to
help on whether I should use u-boot-spl-nodtb or u-boot-spl-dtb (I've
tried both) or how to debug if I am in fact even reading my dtb.

  Thanks again,

  Rick

PS.  My Makefile is here if you are so inclined:
http://members.efn.org/~rick/pub/Makefile  See the targets u-boot-denx
and uboot_new_flash to see what I've tried.
>
> From heiko at sntech.de Tue Nov 29 08:45:02 2016
> To: u-boot at lists.denx.de
> Cc: Simon Glass <sjg@chromium.org>, Rick Bronson <rick@efn.org>,
"eddie.cai" <eddie.cai@rock-chips.com>,
linux-rockchip at lists.infradead.org
> Subject: Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
> Date: Tue, 29 Nov 2016 11:20:52 +0100
>
> Hi Rick,
>
> Am Montag, 28. November 2016, 15:09:05 schrieb Simon Glass:
> > + A few rockchip people and linux-rockchip
> >
> > Hi Rick,
> >
> > On 25 November 2016 at 11:20, Rick Bronson <rick@efn.org> wrote:
> > > Hi All,
> > >
> > >   I've got unsupported RK3288 hardware running the latest git u-boot to
> > >
> > > SPL as explained in
> > > http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip.  My goal
> > > is to run the mainline (ie. not Android) Linux kernel on this hardware
> > >
> > > and wondered:
> > >  - Do I need to get the latest git u-boot to run before I can run the
> > >
> > > mainline kernel?  Or can I use
> > > github.com/linux-rockchip/u-boot-rockchip.git, which I have running
> > > u-boot fully.
> >
> > It's up to you - obviously mainline is where the development should
> > be, but there is no requirement that I know of.
>
> correct, the (mainline-)kernel runs just fine on both the vendor-fork of
uboot
> as well as on mainline.
>
>
> > Does mainline run on your board?
> >
> > >  - The device tree seems to be in two places, once via:
> > >         resource_tool --image=resource2.img --pack linux/logo.bmp
> > >         ${DTS}.dtb
> > >
> > >   that gets put into the resource file and then again at the end of the
> > >
> > > kernel via CONFIG_ARM_APPENDED_DTB.  Do I need both?  When I do both
> > > I get things like:
> >
> > > Unknow param: MACHINE_MODEL:rk30sdk!
> > > Unknow param: MACHINE_ID:007!
>
> ARM_APPEND_DTB is meant for boards where the bootloader cannot load the
> devicetree (to old or so) and also cannot be reasonably exchanged. So the
> append-mechanism was invented to allow bundling the devicetree with the
actual
> kernel image, so that to the bootloader it looks like just any other kernel
> image.
>
> So you essentially only need one or the other. Also at least mainline uboot
> also supports the FIT image type, where you can bundle the devicetree in a
> more generalized way.
>
> For your message I would guess the kernel didn't find a usable devicetree
> somehow and was falling back to ATAGS-based board selection?
>
>

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [U-Boot] Rockchip RK3288 u-boot with mainline kernel
@ 2016-11-25 18:20 Rick Bronson
  2016-11-28 22:09 ` Simon Glass
  0 siblings, 1 reply; 14+ messages in thread
From: Rick Bronson @ 2016-11-25 18:20 UTC (permalink / raw)
  To: u-boot

Hi All,

  I've got unsupported RK3288 hardware running the latest git u-boot to
SPL as explained in
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip.  My goal
is to run the mainline (ie. not Android) Linux kernel on this hardware
and wondered:

 - Do I need to get the latest git u-boot to run before I can run the
mainline kernel?  Or can I use
github.com/linux-rockchip/u-boot-rockchip.git, which I have running
u-boot fully.

 - The device tree seems to be in two places, once via:

	resource_tool --image=resource2.img --pack linux/logo.bmp ${DTS}.dtb

  that gets put into the resource file and then again at the end of the
kernel via CONFIG_ARM_APPENDED_DTB.  Do I need both?  When I do both
I get things like:

....
Unknow param: MACHINE_MODEL:rk30sdk!
Unknow param: MACHINE_ID:007!
....

  Thanks much for any help.

  Rick Bronson

^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-12-07  3:48 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-01 19:00 [U-Boot] Rockchip RK3288 u-boot with mainline kernel Rick Bronson
2016-12-01 21:01 ` Heiko Stuebner
  -- strict thread matches above, loose matches on Subject: below --
2016-12-06  0:56 Rick Bronson
2016-12-07  3:48 ` Simon Glass
2016-12-03 18:07 Rick Bronson
2016-12-03 21:24 ` Heiko Stuebner
2016-11-29 22:50 Rick Bronson
2016-11-29 18:22 Rick Bronson
2016-11-29 21:40 ` Simon Glass
2016-11-29 22:11   ` Heiko Stübner
2016-11-25 18:20 Rick Bronson
2016-11-28 22:09 ` Simon Glass
     [not found]   ` <CAPnjgZ3-ugQ_tmYsvg_cpxwv-aHzcKncn0BXD_R8C=Y7qjySFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-29 10:20     ` Heiko Stübner
2016-11-29 10:20       ` Heiko Stübner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.