Porting barebox (devicetree) to Variscite iMX6 SOM

Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

I figured I'd just throw this out to everyone..

Is there any really good source of information or directions on the
correct steps involved in getting a devicetree based barebox image
built and then correctly programmed onto an SD Card? I feel like I am
missing something somewhere.

I have been involved in getting barebox working on a Variscite i.MX6
SOM with the intent to send it to Sascha, et al. for inclusion in the
tree (once I get it actually working....).

Back in August, I managed to get the Variscite board booting with an
earlier version of barebox and my additions using the "old-style"
methodology in the arch/arm/boards file and the older style DCD header
info. Unfortunately, this version was prior to the inclusion of GPMI
NAND support and other features we needed.

So...I have now been attempting to migrate things to the most current
barebox releases and transfer everything I have done into the newer
style formats aimed at devicetree -- and I haven't been able to get it
to work yet.

So far, I started from the imx_v7_defconfig,  created what I think are
appropriate dts/dtsi files that describe my baseboard and SOM, updated
my board.c and lowlevel.c files (hopefully correctly -- there just
isn't much code in these files anymore with devicetree), created a
flash-header-variscite.imxcfg file using the DCD information I had
already verified worked in the old format (based on the u-Boot DCD
info from Variscite), updated the appropriate Makefiles to build the
new modules, added the appropriate entry to images/Makefile.imx, etc.

I then built it and programmed the resulting .img file into an SD Card
but I get nothing apparent in terms of a response (no serial console,
no blinking LED, etc).

I do NOT have an env partition at the moment but have it set to build
a default environment into barebox itself (which tends to be how we
prefer to have it for our current SD card boot mechanism -- which is
aimed primarily at recovery and upgrade anyway).

Are there any steps I'm missing or anything major I'm doing wrong? Do
I need to be manually specifying a dtb file to include?

Any and all help would be greatly appreciated!

Thanks again,
Michael Burkey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Alexander Aring]

Hi Michael,

I think I would speak for all "Is there any chance to show some code?"
Maybe just send it as "rfc".

On Wed, Dec 11, 2013 at 12:07:17PM -0500, Michael Burkey wrote:
> I figured I'd just throw this out to everyone..
> 
...
> 
> Are there any steps I'm missing or anything major I'm doing wrong? Do
> I need to be manually specifying a dtb file to include?
>
In my opinion (please correct me somebody if I am wrong) you need to
specify a dtb file in your config. Look for "BUILTIN_DTB_NAME".

- Alex

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Sascha Hauer]

On Wed, Dec 11, 2013 at 12:07:17PM -0500, Michael Burkey wrote:
> I figured I'd just throw this out to everyone..
> 
> Is there any really good source of information or directions on the
> correct steps involved in getting a devicetree based barebox image
> built and then correctly programmed onto an SD Card? I feel like I am
> missing something somewhere.

I'm afraid there's not apart from the mail I have written to the list :/

> 
> I have been involved in getting barebox working on a Variscite i.MX6
> SOM with the intent to send it to Sascha, et al. for inclusion in the
> tree (once I get it actually working....).
> 
> Back in August, I managed to get the Variscite board booting with an
> earlier version of barebox and my additions using the "old-style"
> methodology in the arch/arm/boards file and the older style DCD header
> info. Unfortunately, this version was prior to the inclusion of GPMI
> NAND support and other features we needed.
> 
> So...I have now been attempting to migrate things to the most current
> barebox releases and transfer everything I have done into the newer
> style formats aimed at devicetree -- and I haven't been able to get it
> to work yet.
> 
> So far, I started from the imx_v7_defconfig,  created what I think are
> appropriate dts/dtsi files that describe my baseboard and SOM, updated
> my board.c and lowlevel.c files (hopefully correctly -- there just
> isn't much code in these files anymore with devicetree), created a
> flash-header-variscite.imxcfg file using the DCD information I had
> already verified worked in the old format (based on the u-Boot DCD
> info from Variscite), updated the appropriate Makefiles to build the
> new modules, added the appropriate entry to images/Makefile.imx, etc.
> 
> I then built it and programmed the resulting .img file into an SD Card
> but I get nothing apparent in terms of a response (no serial console,
> no blinking LED, etc).

What I did for various boards is to setup an UART early to have serial
output. For i.MX6 this is something along these lines (taken from
arch/arm/boards/phytec-pfla02/lowlevel.c):

static inline void setup_uart(void)
{
	void __iomem *ccmbase = (void *)MX6_CCM_BASE_ADDR;
	void __iomem *uartbase = (void *)MX6_UART4_BASE_ADDR;
	void __iomem *iomuxbase = (void *)MX6_IOMUXC_BASE_ADDR;

	writel(0x4, iomuxbase + 0x01f8);

	writel(0xffffffff, ccmbase + 0x68);
	writel(0xffffffff, ccmbase + 0x6c);
	writel(0xffffffff, ccmbase + 0x70);
	writel(0xffffffff, ccmbase + 0x74);
	writel(0xffffffff, ccmbase + 0x78);
	writel(0xffffffff, ccmbase + 0x7c);
	writel(0xffffffff, ccmbase + 0x80);

	writel(0x00000000, uartbase + 0x80);
	writel(0x00004027, uartbase + 0x84);
	writel(0x00000704, uartbase + 0x88);
	writel(0x00000a81, uartbase + 0x90);
	writel(0x0000002b, uartbase + 0x9c);
	writel(0x00013880, uartbase + 0xb0);
	writel(0x0000047f, uartbase + 0xa4);
	writel(0x0000c34f, uartbase + 0xa8);
	writel(0x00000001, uartbase + 0x80);

	putc_ll('>');
}

(Enable CONFIG_DEBUG_LL, CONFIG_DEBUG_IMX6Q_UART and set
CONFIG_DEBUG_IMX_UART_PORT to the number of your UART, '4' in this
example).

> 
> I do NOT have an env partition at the moment but have it set to build
> a default environment into barebox itself (which tends to be how we
> prefer to have it for our current SD card boot mechanism -- which is
> aimed primarily at recovery and upgrade anyway).

This shouldn't be a problem at this stage.

> 
> Are there any steps I'm missing or anything major I'm doing wrong? Do
> I need to be manually specifying a dtb file to include?

The important thing is that you have your own entry function. For the
pfla02 this is:

| extern char __dtb_imx6q_phytec_pbab01_start[];
| 
| ENTRY_FUNCTION(start_phytec_pbab01_1gib, r0, r1, r2)
| {
| 	uint32_t fdt;
| 
| 	arm_cpu_lowlevel_init();
| 
| 	arm_setup_stack(0x00920000 - 8);
| 
| 	if (IS_ENABLED(CONFIG_DEBUG_LL))
| 		setup_uart();
| 
| 	fdt = (uint32_t)__dtb_imx6q_phytec_pbab01_start - get_runtime_offset();
| 
| 	barebox_arm_entry(0x10000000, SZ_1G, fdt);
| }
| 

(replace __dtb_imx6q_phytec_pbab01_start with your devicetree and
start_phytec_pbab01_1gib with your boardname)

To generate an image with the entry point above you need this in images/Makefile.imx:

| pblx-$(CONFIG_MACH_PHYTEC_PFLA02) += start_phytec_pbab01_1gib
| CFG_start_phytec_pbab01_1gib.pblx.imximg = $(board)/phytec-pfla02/flash-header-phytec-pfla02-1gib.imxcfg
| FILE_barebox-phytec-pbab01-1gib.img = start_phytec_pbab01_1gib.pblx.imximg
| image-$(CONFIG_MACH_PHYTEC_PFLA02) += barebox-phytec-pbab01-1gib.img

If you have this and don't get link errors then you have the correct
devicetree compiled in.

Be sure to pass the correct memory size (SZ_1G in this example). Try to
generate an disassembly file:

make images/start_phytec_pbab01_1gib.pbl.s

It should look like:

| 
| images/start_phytec_pbab01_1gib.pbl:     file format elf32-littlearm
| 
| 
| Disassembly of section .text:
| 
| 00000000 <start_phytec_pbab01_1gib>:
|    0:   e28f9001        add     r9, pc, #1
|    4:   e12fff19        bx      r9
|    8:   f000 f822       bl      50 <start_phytec_pbab01_1gib+0x50>
|    c:   e7fe            b.n     c <start_phytec_pbab01_1gib+0xc>
|    e:   e7fe            b.n     e <start_phytec_pbab01_1gib+0xe>
|   10:   e7fe            b.n     10 <start_phytec_pbab01_1gib+0x10>
|   12:   e7fe            b.n     12 <start_phytec_pbab01_1gib+0x12>
|   14:   e7fe            b.n     14 <start_phytec_pbab01_1gib+0x14>
|   16:   e7fe            b.n     16 <start_phytec_pbab01_1gib+0x16>
|   18:   e7fe            b.n     18 <start_phytec_pbab01_1gib+0x18>
|   1a:   e7fe            b.n     1a <start_phytec_pbab01_1gib+0x1a>
|   1c:   e7fe            b.n     1c <start_phytec_pbab01_1gib+0x1c>
|   1e:   e7fe            b.n     1e <start_phytec_pbab01_1gib+0x1e>
|   20:   65726162        .word   0x65726162
|   24:   00786f62        .word   0x00786f62
|         ...
|   30:   55555555        .word   0x55555555
|   34:   55555555        .word   0x55555555
|   38:   55555555        .word   0x55555555
|   3c:   55555555        .word   0x55555555
|   40:   55555555        .word   0x55555555
|   44:   55555555        .word   0x55555555
|   48:   55555555        .word   0x55555555
|   4c:   55555555        .word   0x55555555
|   50:   f000 f84c       bl      ec <__start_phytec_pbab01_1gib>

The important thing about this is that it must start with the function
you have specified as ENTRY_FUNCTION.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

Sascha, thanks for the pointers(especially on the UART and debugging)
-- I had included the code from your PFLA02 board file but hadn't
enabled the extra debugging config options.

The good news is, based on your email, I think I have everything
right. The bad news is, it still doesn't work! (initial board
bring-ups are always just SO much fun - NOT) Everything links, no
error messages or warnings, I get an img file out, etc -- just no luck
in it actually doing anything. (PS...I am currently booting from SD
Card but intend on having some things in GPMI NAND eventually)

Based on this and from Alex's suggestion, I am just going to include
my actual modified source files in this email/post just in case anyone
sees anything blindingly obvious.

Thanks again!
Michael Burkey


----------------------------
boards\variscite-mx6\board.c
----------------------------
/*
 * Copyright (C) 2013 Michael Burkey
 * Based on code by Sascha Hauer, Pengutronix
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; either version 2 of
 * the License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation.
 *
 */

#include <common.h>
#include <gpio.h>
#include <init.h>
#include <of.h>

#include <mach/imx6.h>

static int variscite_custom_init(void)
{
	if (!of_machine_is_compatible("variscite,imx6q-custom"))
		return 0;

	return 0;
}
device_initcall(variscite_custom_init);

static int variscite_custom_core_init(void)
{
	if (!of_machine_is_compatible("variscite,imx6q-custom"))
		return 0;

	imx6_init_lowlevel();

	return 0;
}
postcore_initcall(variscite_custom_core_init);

-------------------------------
boards\variscite-mx6\lowlevel.c
-------------------------------
/*
 *
 * Copyright (C) 2013 Michael Burkey
 * Based on code by Sascha Hauer <s.hauer@pengutronix.de>
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; either version 2 of
 * the License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 */
#include <debug_ll.h>
#include <common.h>
#include <sizes.h>
#include <io.h>
#include <asm/barebox-arm-head.h>
#include <asm/barebox-arm.h>
#include <asm/sections.h>
#include <asm/cache.h>
#include <asm/mmu.h>
#include <mach/imx6-mmdc.h>
#include <mach/imx6.h>

static inline void setup_uart(void)
{
	void __iomem *ccmbase = (void *)MX6_CCM_BASE_ADDR;
	void __iomem *uartbase = (void *)MX6_UART1_BASE_ADDR;
	void __iomem *iomuxbase = (void *)MX6_IOMUXC_BASE_ADDR;

	writel(0x4, iomuxbase + 0x01f8);

	writel(0xffffffff, ccmbase + 0x68);
	writel(0xffffffff, ccmbase + 0x6c);
	writel(0xffffffff, ccmbase + 0x70);
	writel(0xffffffff, ccmbase + 0x74);
	writel(0xffffffff, ccmbase + 0x78);
	writel(0xffffffff, ccmbase + 0x7c);
	writel(0xffffffff, ccmbase + 0x80);

	writel(0x00000000, uartbase + 0x80);
	writel(0x00004027, uartbase + 0x84);
	writel(0x00000704, uartbase + 0x88);
	writel(0x00000a81, uartbase + 0x90);
	writel(0x0000002b, uartbase + 0x9c);
	writel(0x00013880, uartbase + 0xb0);
	writel(0x0000047f, uartbase + 0xa4);
	writel(0x0000c34f, uartbase + 0xa8);
	writel(0x00000001, uartbase + 0x80);

	putc_ll('>');
}
extern char __dtb_imx6q_var_custom_start[];

ENTRY_FUNCTION(start_variscite_custom)(void)
{
	uint32_t fdt;

	__barebox_arm_head();

	arm_cpu_lowlevel_init();

	arm_setup_stack(0x00920000 - 8);

		setup_uart();
	fdt = (uint32_t)__dtb_imx6q_var_custom_start - get_runtime_offset();

	barebox_arm_entry(0x10000000, SZ_1G, fdt);
}

--------------------------------------------------
boards\variscite-mx6\flash-header-variscite.imxcfg
--------------------------------------------------

loadaddr 0x10000000
soc imx6
dcdofs 0x400
wm 32 0x020e0798 0x000C0000
wm 32 0x020e0758 0x00000000
wm 32 0x020e0588 0x00000030
wm 32 0x020e0594 0x00000030
wm 32 0x020e056c 0x00000030
wm 32 0x020e0578 0x00000030
wm 32 0x020e074c 0x00000030
wm 32 0x020e057c 0x00000030
wm 32 0x020e058c 0x00000000
wm 32 0x020e059c 0x00000030
wm 32 0x020e05a0 0x00000030
wm 32 0x020e078c 0x00000030
wm 32 0x020e0750 0x00020000
wm 32 0x020e05a8 0x00000030
wm 32 0x020e05b0 0x00000030
wm 32 0x020e0524 0x00000030
wm 32 0x020e051c 0x00000030
wm 32 0x020e0518 0x00000030
wm 32 0x020e050c 0x00000030
wm 32 0x020e05b8 0x00000030
wm 32 0x020e05c0 0x00000030
wm 32 0x020e0774 0x00020000
wm 32 0x020e0784 0x00000030
wm 32 0x020e0788 0x00000030
wm 32 0x020e0794 0x00000030
wm 32 0x020e079c 0x00000030
wm 32 0x020e07a0 0x00000030
wm 32 0x020e07a4 0x00000030
wm 32 0x020e07a8 0x00000030
wm 32 0x020e0748 0x00000030
wm 32 0x020e05ac 0x00000030
wm 32 0x020e05b4 0x00000030
wm 32 0x020e0528 0x00000030
wm 32 0x020e0520 0x00000030
wm 32 0x020e0514 0x00000030
wm 32 0x020e0510 0x00000030
wm 32 0x020e05bc 0x00000030
wm 32 0x020e05c4 0x00000030
wm 32 0x021b0800 0xA1390003
wm 32 0x021b080c 0x001F001F
wm 32 0x021b0810 0x001F001F
wm 32 0x021b480c 0x001F001F
wm 32 0x021b4810 0x001F001F
wm 32 0x021b083c 0x4333033F
wm 32 0x021b0840 0x032C031D
wm 32 0x021b483c 0x43200332
wm 32 0x021b4840 0x031A026A
wm 32 0x021b0848 0x4D464746
wm 32 0x021b4848 0x47453F4D
wm 32 0x021b0850 0x3E434440
wm 32 0x021b4850 0x47384839
wm 32 0x021b081c 0x33333333
wm 32 0x021b0820 0x33333333
wm 32 0x021b0824 0x33333333
wm 32 0x021b0828 0x33333333
wm 32 0x021b481c 0x33333333
wm 32 0x021b4820 0x33333333
wm 32 0x021b4824 0x33333333
wm 32 0x021b4828 0x33333333
wm 32 0x021b08b8 0x00000800
wm 32 0x021b48b8 0x00000800
wm 32 0x021b0004 0x00020036
wm 32 0x021b0008 0x09444040
wm 32 0x021b000c 0x555A7975
wm 32 0x021b0010 0xFF538F64
wm 32 0x021b0014 0x01FF00DB
wm 32 0x021b0018 0x00001740
wm 32 0x021b001c 0x00008000
wm 32 0x021b002c 0x000026D2
wm 32 0x021b0030 0x005A1023
wm 32 0x021b0040 0x00000027
wm 32 0x021b0000 0x831A0000
wm 32 0x021b001c 0x04088032
wm 32 0x021b001c 0x00008033
wm 32 0x021b001c 0x00048031
wm 32 0x021b001c 0x09408030
wm 32 0x021b001c 0x04008040
wm 32 0x021b0020 0x00005800
wm 32 0x021b0818 0x00011117
wm 32 0x021b4818 0x00011117
wm 32 0x021b0004 0x00025576
wm 32 0x021b0404 0x00011006
wm 32 0x021b001c 0x00000000
								--------------------------------
images\Makefile.imx
--------------------------------

appended:
pblx-$(CONFIG_MACH_VARISCITE_MX6) += start_variscite_custom
CFG_start_variscite_custom.pblx.imximg =
$(board)/variscite-mx6/flash-header-variscite.imxcfg
FILE_barebox-variscite-custom.img = start_variscite_custom.pblx.imximg
image-$(CONFIG_MACH_VARISCITE_MX6) += barebox-variscite-custom.img
	

-------------------------------------------------------------

I also added the CONFIG_MACH_VARISCITE_MX6 flag to the config options,
etc (and added "obj-$(CONFIG_MACH_VARISCITE_MX6) += variscite-mx6/" to
the Makefile under boards (and I have gone back and verified that
everything that should be spitting out a .o appears to be -- i.e. the
right files are actually getting built).

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

Additionally, here are the dts and dtsi files I added for the Variscite part:

---------------------------------
arch/arm/dts/imx6q-var-custom.dts
---------------------------------
/*
 * Copyright 2013 Michael Burkey
 * Based on code written by Christian Hemp, Phytec Messtechnik GmbH
 *
 * The code contained herein is licensed under the GNU General Public
 * License. You may obtain a copy of the GNU General Public License
 * Version 2 or later at the following locations:
 *
 * http://www.opensource.org/licenses/gpl-license.html
 * http://www.gnu.org/copyleft/gpl.html
 */

/dts-v1/;
#include "imx6q-var-som.dtsi"

/ {
	model = "Variscite i.MX6 Quad Custom Carrier-Board";
	compatible = "variscite,imx6q-custom", "variscite,imx6q-som", "fsl,imx6q";

	chosen {
		linux,stdout-path = &uart1;

		environment@0 {
			compatible = "barebox,environment";
			device-path = &gpmi, "partname:barebox-environment";
		};
	};
};

&uart1 {
	status = "okay";
};

&usdhc2 {
	status = "okay";
};

&usbh1 {
	status = "okay";
	disable-over-current;
};

&i2c1 {
	status = "okay";
	clock-frequency = <100000>;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_i2c1_2>;
};

-------------------------------
arch/arm/dts/imx6q-var-som-dtsi
-------------------------------
/*
 * Copyright 2013 Michael Burkey
 * Based on code written by Christian Hemp, Phytec Messtechnik GmbH
 *
 * The code contained herein is licensed under the GNU General Public
 * License. You may obtain a copy of the GNU General Public License
 * Version 2 or later at the following locations:
 *
 * http://www.opensource.org/licenses/gpl-license.html
 * http://www.gnu.org/copyleft/gpl.html
 */

#include "imx6q.dtsi"

/ {
	model = "Variscite i.MX6 Quad SOM";
	compatible = "variscite,imx6q-som", "fsl,imx6q";

	memory {
		reg = <0x10000000 0x40000000>;
	};
};

&gpmi {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_gpmi_nand_1>;
	nand-on-flash-bbt;
	status = "okay";
	#address-cells = <1>;
	#size-cells = <1>;

	partition@0 {
		label = "barebox";
		reg = <0x0 0x200000>;
	};

	partition@1 {
		label = "barebox-environment";
		reg = <0x200000 0x10000>;
	};

	partition@2 {
		label = "kernel";
		reg = <0x210000 0x600000>;
	};

	partition@3 {
		label = "rootfs";
		reg = <0x860000 0x18000000>;
	};

	partition@4 {
		label = "profilefs";
		reg = <0x18860000 0x400000>;
	};
};

&usdhc2 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_usdhc2_2>;
	cd-gpios = <&gpio3 29 0>;
	status = "disabled";
};

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Alexander Aring]

Hi,

some little notice... this should not fix your problem.

On Thu, Dec 12, 2013 at 01:56:14PM -0500, Michael Burkey wrote:
> Additionally, here are the dts and dtsi files I added for the Variscite part:
> 
...
> 	partition@0 {
> 		label = "barebox";
> 		reg = <0x0 0x200000>;
> 	};
> 
> 	partition@1 {
> 		label = "barebox-environment";
> 		reg = <0x200000 0x10000>;
> 	};
> 
> 	partition@2 {
> 		label = "kernel";
> 		reg = <0x210000 0x600000>;
> 	};
> 
> 	partition@3 {
> 		label = "rootfs";
> 		reg = <0x860000 0x18000000>;

I think this should be "reg = <0x810000 ...>" or you have a little unused
space :-)

- Alex

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

You are correct!

Apparently, I have problems with pesky little things like simple addition! ;-)

Thanks for spotting that. I hadn't proofed that part of the code
thoroughly yet (we are still just using SD Card for the moment with an
intent to move to GPMI "eventually").

If only the other problem was this easy to fix!

On 12/12/13, Alexander Aring <alex.aring@gmail.com> wrote:
> Hi,
>
> some little notice... this should not fix your problem.
>
> On Thu, Dec 12, 2013 at 01:56:14PM -0500, Michael Burkey wrote:
>> Additionally, here are the dts and dtsi files I added for the Variscite
>> part:
>>
> ...
>> 	partition@0 {
>> 		label = "barebox";
>> 		reg = <0x0 0x200000>;
>> 	};
>>
>> 	partition@1 {
>> 		label = "barebox-environment";
>> 		reg = <0x200000 0x10000>;
>> 	};
>>
>> 	partition@2 {
>> 		label = "kernel";
>> 		reg = <0x210000 0x600000>;
>> 	};
>>
>> 	partition@3 {
>> 		label = "rootfs";
>> 		reg = <0x860000 0x18000000>;
>
> I think this should be "reg = <0x810000 ...>" or you have a little unused
> space :-)
>
> - Alex
>

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Sascha Hauer]

On Thu, Dec 12, 2013 at 01:49:19PM -0500, Michael Burkey wrote:
> Sascha, thanks for the pointers(especially on the UART and debugging)
> -- I had included the code from your PFLA02 board file but hadn't
> enabled the extra debugging config options.
> 
> The good news is, based on your email, I think I have everything
> right. The bad news is, it still doesn't work! (initial board
> bring-ups are always just SO much fun - NOT) Everything links, no
> error messages or warnings, I get an img file out, etc -- just no luck
> in it actually doing anything. (PS...I am currently booting from SD
> Card but intend on having some things in GPMI NAND eventually)
> 
> Based on this and from Alex's suggestion, I am just going to include
> my actual modified source files in this email/post just in case anyone
> sees anything blindingly obvious.
> 
> Thanks again!
> Michael Burkey
> 

[...]

> 
> ENTRY_FUNCTION(start_variscite_custom)(void)
> {
> 	uint32_t fdt;
> 
> 	__barebox_arm_head();

Remove this. It's already included in the ENTRY_FUNCTION macro.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

Thanks for all the help!

I have now at least got it to the point of getting a barebox prompt
via the serial port.

The final thing I had to change was that I realized that since we have
our UART1 using a different set of pins than is the default, I needed
to manually change the IOMUX settings for the early bring-up of the
serial port that Sascha pointed me to earlier.

Basically:

/arch/arm/boards/variscite-mx6/lowlevel.c

-writel(0x4, iomuxbase + 0x01f8);
+writel(0x03, iomuxbase + 0x0280);
+writel(0x03, iomuxbase + 0x0284);
+writel(0x00, iomuxbase + 0x0920);

MANY THANKS!!!!

I'm sure I will have more issues, but this at least gets things
booting up enough to where I can now make progress.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

Variscite SOM...the saga continues.

First off, I now have the serial console up (more or less -- more on
this in a second), but it's not accepting input and I have other
issues.

My questions:

1) When using devicetree inside barebox, does a built-in devicetree
get automatically enumerated and probed?
2) At what point in the boot process do devices specified in
devicetree become available? (specifically, the I2C bus support)
3) Is there any voltage regulator support in barebox? I notice on some
of the i.MX6 SOM's that the PF0100 is specified and configured, but
I'm not actually seeing any driver code in barebox itself that
accesses it (unless I'm overlooking it). I assume the voltage
regulator definitions are just for pushing upstream when booting a
kernel?


What I am running into is that the Variscite SOM uses the 3.3V output
of the PF0100 voltage regulator as a "power good" signal that brings
up the 3.3V rail on their development board -- which, among other
things, powers the RS232 transceiver that the debug port connects to
(which is the reason I get output, but no input). It also powers the
USB hub on the board, which is also fairly important.

So, basically, I'm trying to figure out the proper way to configure
I2C devices early in the barebox boot sequence when using devicetree.
I know how to do it the old-fashioned way in the board file (which I
have done before).

Thanks,
Michael Burkey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

I have answered some of my own questions and got more working on the
Variscite port.

So, for anyone else trying to do basically the same thing I am:

1) The built-in devicetree does get probed and enumerated.

2) By the time the _init function in board.c gets called, the probing
is complete and devices such as i2c are available.

I also got my uart problem fixed -- which was actually a devicetree
error on my part.

However, I am still back to working on part of my problem. When
configured correctly, the Variscite development board is SUPPOSED to
gate the 3.3V line to the onboard peripherals using the 3.3V output of
the PF0100 -- which, unfortunately, means that some of the devices
that may need to be probed in devicetree probably won't respond until
after I can use I2C to properly configure the PF0100.

So...after I have configured the PF0100, can "oftree -p" be used to
re-probe the current tree?? Or do I have to figure out a way to bring
I2C up early as well?

Thanks,
Michael Burkey

On 12/18/13, Michael Burkey <mdburkey@gmail.com> wrote:
> Variscite SOM...the saga continues.
>
> First off, I now have the serial console up (more or less -- more on
> this in a second), but it's not accepting input and I have other
> issues.
>
> My questions:
>
> 1) When using devicetree inside barebox, does a built-in devicetree
> get automatically enumerated and probed?
> 2) At what point in the boot process do devices specified in
> devicetree become available? (specifically, the I2C bus support)
> 3) Is there any voltage regulator support in barebox? I notice on some
> of the i.MX6 SOM's that the PF0100 is specified and configured, but
> I'm not actually seeing any driver code in barebox itself that
> accesses it (unless I'm overlooking it). I assume the voltage
> regulator definitions are just for pushing upstream when booting a
> kernel?
>
>
> What I am running into is that the Variscite SOM uses the 3.3V output
> of the PF0100 voltage regulator as a "power good" signal that brings
> up the 3.3V rail on their development board -- which, among other
> things, powers the RS232 transceiver that the debug port connects to
> (which is the reason I get output, but no input). It also powers the
> USB hub on the board, which is also fairly important.
>
> So, basically, I'm trying to figure out the proper way to configure
> I2C devices early in the barebox boot sequence when using devicetree.
> I know how to do it the old-fashioned way in the board file (which I
> have done before).
>
> Thanks,
> Michael Burkey
>

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Sascha Hauer]

On Wed, Dec 18, 2013 at 04:34:20PM -0500, Michael Burkey wrote:
> I have answered some of my own questions and got more working on the
> Variscite port.
> 
> So, for anyone else trying to do basically the same thing I am:
> 
> 1) The built-in devicetree does get probed and enumerated.
> 
> 2) By the time the _init function in board.c gets called, the probing
> is complete and devices such as i2c are available.
> 
> I also got my uart problem fixed -- which was actually a devicetree
> error on my part.
> 
> However, I am still back to working on part of my problem. When
> configured correctly, the Variscite development board is SUPPOSED to
> gate the 3.3V line to the onboard peripherals using the 3.3V output of
> the PF0100 -- which, unfortunately, means that some of the devices
> that may need to be probed in devicetree probably won't respond until
> after I can use I2C to properly configure the PF0100.
> 
> So...after I have configured the PF0100, can "oftree -p" be used to
> re-probe the current tree?? Or do I have to figure out a way to bring
> I2C up early as well?

For the kernel the correct solution is to add regulators to the device
nodes which need the 3.3V line, so that the drivers for these devices
request and enable the regulators before accessing the devices.
In barebox we are not (yet?) prepared for this. Right now your options
are:

a) make sure the PF0100 is available before the devices using it (that
   may mean to move the i2c-imx driver and the PF0100 driver to an earlier
   initcall level).
b) Use an 'early' i2c driver (For example arch/ppc/mach-mpc85xx/fsl_i2c.c
   has this, the code should even work on i.MX)
c) implement regulator support for barebox

I would first try to get away with a), although from my point of view I
of course recommend c) ;)

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

A few more comments & questions regarding getting the Variscite SOM up
and working (and it's pretty close to fully working at this point):

First off, what works:

1) Booting from NAND, SD, etc to barebox
2) Nand programming under barebox
3) GPIO
4) I2C
5) USB
6) RS232
etc.

Basically, things are working pretty well....up to the point of
starting the Linux Kernel.

Whenever I try to do a "bootm" of pretty much any image type, I run
into issues. I *think* I have everything setup properly on the Linux
command line in the way of bootargs (but I'm still checking a couple
of things). It doesn't matter whether I am launching the kernel from a
partition (NAND), USB, memory, etc. The result is the same regardless.
It *does* decode the kernel header properly, display the version, the
correct load address, etc -- so that's not the issue.

One thing is that I am using an older kernel that is not setup for
devicetree -- which is hopefully not a major problem. Basically,
everything is specified "the old way" in the kernel platform/board
files (and it works fine from u-boot). And, at least for now, moving
to a newer kernel isn't an option.

Under barebox, I either get a "launching kernel with devicetree" and
then it hangs, or, if I do an "oftree -f" and then do a bootm, I get
an "unable to dereference NULL pointer" and a restart.

Any quick guesses, suggestions as to what I may be doing wrong?
Is there a proper way to tell barebox (when started with devicetree)
to NOT try to send the devicetree on to the kernel?

Also, for the moment, I am using Kobs-NG under Linux to actually
program barebox itself into NAND. Once there, it works fine and I can
use barebox itself to program the other NAND partitions. Is adding
support for writing out the FCB/DBBT to the first NAND blocks anywhere
in the current (near-term) to do list for barebox? I noticed that it
looked like you had something similar to this already in barebox for a
couple of the other, earlier iMX cores.


Lastly, once I do get this semi-final issue fixed, what is the best
way to submit the code for the Variscite SOM to the main barebox tree
for everyone else to have access to?

Thanks again!
Michael Burkey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

Sascha,

Since I am still having issues with the kernel booting -- and needed a
bit of a break to clear my mind -- I decided to delve into the initial
barebox bootup from NAND a bit more.

Correct me if I am wrong, but how I understand things right now...

The iMX6 requires a BCB header prior to the actual barebox partition
(e.g. nand0.bootstream). This bootstream partition would contain the
BCB data specific to the iMX6 (i.e. an FCB and at least a partial
DBBT).

It also looks like this functionality is already present in barebox
for the MX23/28 series of parts (i.e. the "bcb" command).

I also have the source for kobs-ng v1.3, which does properly generate
the BCB for the MX6 series (and is what I am currently using to flash
barebox into NAND).

So, basically, it sounds like what I need to do is migrate the bcb.c
file from the arm/mach-mxs folder into the MX6 portion of the tree and
then update it based on the datasheet and the "known good" parameters
from kobs-ng v1.3 (which look fairly similar to the definitions you
already have in place for the MX23/28 FCB).

Does this sound like a reasonable plan of action?

It really looks like life with the iMX6 would be much easier if I had
a SPI-NOR on this SOM, instead of NAND only.

Thanks,
Michael Burkey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Sascha Hauer]

On Thu, Jan 09, 2014 at 02:59:33PM -0500, Michael Burkey wrote:
> Sascha,
> 
> Since I am still having issues with the kernel booting -- and needed a
> bit of a break to clear my mind -- I decided to delve into the initial
> barebox bootup from NAND a bit more.
> 
> Correct me if I am wrong, but how I understand things right now...
> 
> The iMX6 requires a BCB header prior to the actual barebox partition
> (e.g. nand0.bootstream). This bootstream partition would contain the
> BCB data specific to the iMX6 (i.e. an FCB and at least a partial
> DBBT).

Yes, right.

> 
> It also looks like this functionality is already present in barebox
> for the MX23/28 series of parts (i.e. the "bcb" command).

Yes.

> 
> I also have the source for kobs-ng v1.3, which does properly generate
> the BCB for the MX6 series (and is what I am currently using to flash
> barebox into NAND).

Yes, kobs works for me aswell on i.MX6

> 
> So, basically, it sounds like what I need to do is migrate the bcb.c
> file from the arm/mach-mxs folder into the MX6 portion of the tree and
> then update it based on the datasheet and the "known good" parameters
> from kobs-ng v1.3 (which look fairly similar to the definitions you
> already have in place for the MX23/28 FCB).
> 
> Does this sound like a reasonable plan of action?

Indeed. I tried Doing that myself, but it didn't work, probably some
little piece was missing. I also started to port the original kobs code
to barebox, but was distracted. I can give you the code I have so far if
you like.

> 
> It really looks like life with the iMX6 would be much easier if I had
> a SPI-NOR on this SOM, instead of NAND only.

Yeah, indeed. I usually recommend our customers to not rely on NAND for
booting.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Sascha Hauer]

On Thu, Jan 09, 2014 at 02:20:33AM -0500, Michael Burkey wrote:
> A few more comments & questions regarding getting the Variscite SOM up
> and working (and it's pretty close to fully working at this point):
> 
> First off, what works:
> 
> 1) Booting from NAND, SD, etc to barebox
> 2) Nand programming under barebox
> 3) GPIO
> 4) I2C
> 5) USB
> 6) RS232
> etc.
> 
> Basically, things are working pretty well....up to the point of
> starting the Linux Kernel.
> 
> Whenever I try to do a "bootm" of pretty much any image type, I run
> into issues. I *think* I have everything setup properly on the Linux
> command line in the way of bootargs (but I'm still checking a couple
> of things). It doesn't matter whether I am launching the kernel from a
> partition (NAND), USB, memory, etc. The result is the same regardless.
> It *does* decode the kernel header properly, display the version, the
> correct load address, etc -- so that's not the issue.
> 
> One thing is that I am using an older kernel that is not setup for
> devicetree -- which is hopefully not a major problem. Basically,
> everything is specified "the old way" in the kernel platform/board
> files (and it works fine from u-boot). And, at least for now, moving
> to a newer kernel isn't an option.
> 
> Under barebox, I either get a "launching kernel with devicetree" and
> then it hangs,

Ok, this is expected since your kernel does not have devicetree support

> or, if I do an "oftree -f" and then do a bootm,

That's the correct thing to do. With this it should work.

> I get
> an "unable to dereference NULL pointer" and a restart.

You could enable:

[*] enable arm exception handling support
[*]   enable stack unwinding support

and

[*] kallsyms

With this barebox prints a backtrace giving a clue where the NULL
pointer deref happens.

> 
> Any quick guesses, suggestions as to what I may be doing wrong?
> Is there a proper way to tell barebox (when started with devicetree)
> to NOT try to send the devicetree on to the kernel?
> 
> Also, for the moment, I am using Kobs-NG under Linux to actually
> program barebox itself into NAND. Once there, it works fine and I can
> use barebox itself to program the other NAND partitions. Is adding
> support for writing out the FCB/DBBT to the first NAND blocks anywhere
> in the current (near-term) to do list for barebox? I noticed that it
> looked like you had something similar to this already in barebox for a
> couple of the other, earlier iMX cores.
> 
> 
> Lastly, once I do get this semi-final issue fixed, what is the best
> way to submit the code for the Variscite SOM to the main barebox tree
> for everyone else to have access to?

Just post the patches to the list. I'll include them then.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

Sascha, thanks for the advice on the stack unwinding and other
debugging aids. It was a huge help.

I have made progress and isolated and gotten past my earlier null
pointer problem -- it turned out to be an issue that you had already
fixed on the tip (the recent changes to armlinux_get_bootparams fixed
the null pointer issue).

That said, I'm still having issues booting with an older kernel. Which
brings me to my next question....

In the case where I am booting an old, non-devicetree, kernel with a
newer, devicetree, version of barebox, and then using "oftree -f" to
flush the devicetree before starting the kernel, what is the proper
way to have things like the boot parameters, the boot architecture,
etc. specified for passing to the older kernel? Just go back and add
them into the board files like they used to be in older versions of
barebox? Do you know if having stuff specified in both the old way and
in the oftree will cause any potential problems?

Basically, my goal is to have a version of barebox than can launch
either our current (old) kernel or a newer mainline version
interchangeably without having to upgrade barebox (basically, we will
probably initially be shipping an older kernel and then upgrading to a
newer one later -- and, if at all possible, I'd really rather not have
to incur the risk of having our users need to update barebox in the
field as well).

Thanks,
Michael Burkey


On 1/10/14, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Thu, Jan 09, 2014 at 02:20:33AM -0500, Michael Burkey wrote:
>> A few more comments & questions regarding getting the Variscite SOM up
>> and working (and it's pretty close to fully working at this point):
>>
>> First off, what works:
>>
>> 1) Booting from NAND, SD, etc to barebox
>> 2) Nand programming under barebox
>> 3) GPIO
>> 4) I2C
>> 5) USB
>> 6) RS232
>> etc.
>>
>> Basically, things are working pretty well....up to the point of
>> starting the Linux Kernel.
>>
>> Whenever I try to do a "bootm" of pretty much any image type, I run
>> into issues. I *think* I have everything setup properly on the Linux
>> command line in the way of bootargs (but I'm still checking a couple
>> of things). It doesn't matter whether I am launching the kernel from a
>> partition (NAND), USB, memory, etc. The result is the same regardless.
>> It *does* decode the kernel header properly, display the version, the
>> correct load address, etc -- so that's not the issue.
>>
>> One thing is that I am using an older kernel that is not setup for
>> devicetree -- which is hopefully not a major problem. Basically,
>> everything is specified "the old way" in the kernel platform/board
>> files (and it works fine from u-boot). And, at least for now, moving
>> to a newer kernel isn't an option.
>>
>> Under barebox, I either get a "launching kernel with devicetree" and
>> then it hangs,
>
> Ok, this is expected since your kernel does not have devicetree support
>
>> or, if I do an "oftree -f" and then do a bootm,
>
> That's the correct thing to do. With this it should work.
>
>> I get
>> an "unable to dereference NULL pointer" and a restart.
>
> You could enable:
>
> [*] enable arm exception handling support
> [*]   enable stack unwinding support
>
> and
>
> [*] kallsyms
>
> With this barebox prints a backtrace giving a clue where the NULL
> pointer deref happens.
>
>>
>> Any quick guesses, suggestions as to what I may be doing wrong?
>> Is there a proper way to tell barebox (when started with devicetree)
>> to NOT try to send the devicetree on to the kernel?
>>
>> Also, for the moment, I am using Kobs-NG under Linux to actually
>> program barebox itself into NAND. Once there, it works fine and I can
>> use barebox itself to program the other NAND partitions. Is adding
>> support for writing out the FCB/DBBT to the first NAND blocks anywhere
>> in the current (near-term) to do list for barebox? I noticed that it
>> looked like you had something similar to this already in barebox for a
>> couple of the other, earlier iMX cores.
>>
>>
>> Lastly, once I do get this semi-final issue fixed, what is the best
>> way to submit the code for the Variscite SOM to the main barebox tree
>> for everyone else to have access to?
>
> Just post the patches to the list. I'll include them then.
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Sascha Hauer]

On Wed, Jan 15, 2014 at 01:35:15PM -0500, Michael Burkey wrote:
> Sascha, thanks for the advice on the stack unwinding and other
> debugging aids. It was a huge help.
> 
> I have made progress and isolated and gotten past my earlier null
> pointer problem -- it turned out to be an issue that you had already
> fixed on the tip (the recent changes to armlinux_get_bootparams fixed
> the null pointer issue).
> 
> That said, I'm still having issues booting with an older kernel. Which
> brings me to my next question....
> 
> In the case where I am booting an old, non-devicetree, kernel with a
> newer, devicetree, version of barebox, and then using "oftree -f" to
> flush the devicetree before starting the kernel, what is the proper
> way to have things like the boot parameters, the boot architecture,
> etc. specified for passing to the older kernel? Just go back and add
> them into the board files like they used to be in older versions of
> barebox?

yes.

> Do you know if having stuff specified in both the old way and
> in the oftree will cause any potential problems?

Not sure if I understand you. The kernel either takes old style ATAGs or
a devicetree (in the same pointer), barebox sets up either one or the
other, but never both. The machine number becomes meaningless with
devicetree support, it doesn't matter if it is specified or not.

> 
> Basically, my goal is to have a version of barebox than can launch
> either our current (old) kernel or a newer mainline version
> interchangeably without having to upgrade barebox (basically, we will
> probably initially be shipping an older kernel and then upgrading to a
> newer one later -- and, if at all possible, I'd really rather not have
> to incur the risk of having our users need to update barebox in the
> field as well).

Basically barebox has to know whether a kernel is to be started with
devicetree or not, which means you have to have two boot entries, one
with devicetree and one without. There are two ways around it:

- Use bootloader spec based booting. This way you have text files on
  your boot medium describing what to boot. This text file would
  include information whether or not a kernel should be booted with
  devicetree
- Use appended devicetrees: cat zImage dtb > myImage. Such a kernel
  can be started the traditional way and still uses devicetree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

Sascha,

Eureka! Based on your comments, things are starting to make sense now.
My brain wasn't fully comprehending how things were now supposed to
work.

I now have my kernel booting and things are working much better now (I
still have to get all my partition info specified properly, but that's
a fairly well understood task).

I also went back and watched your ELCE 2013 "Barebox and the
Bootloader Specification" presentation on Youtube. This REALLY helped
clarify things a bit -- although the direction things seem to be
heading (away from raw NOR/NAND, etc) don't fit with the world in
which I typically work (dedicated hardware, totally custom designed
and manufactured carrier boards, etc).

As everything I am currently working with is specifically from a raw
NAND device and using UBI, the Bootloader Specification doesn't really
do anything to help us (also, we will probably have no need for ever
using any standard distribution of Linux, since we do our own custom
rootfs that is trimmed to eliminate everything we don't need).

The way I have things setup now (and apparently working):

1) I have a dtb file built into barebox which is what it is using to
initially configure it's devices.

2) I have all of the legacy type information (MACH_TYPE) specified in
the board.c file and in the /env/config file. This is required to use
the existing (older) kernel we have for the Variscite SOM.

3) I am (currently) using kobs-ng under Linux to initially program
barebox into our NAND part and I am then using barebox to program any
of the additional partitions based on an upgrade script we have
written.

So, to boot the kernel we are using currently, I have modified the
barebox startup script to do an "oftree -f" after startup and then use
bootm to launch the kernel from it's appropriate NAND partition.

Based on my understanding, I could also just as easily (once we get a
newer kernel), *not* do the "oftree -f" and allow barebox to pass the
stored devicetree along to the kernel for initial configuration. I
could also just as easily load, other, different devicetree's using
"oftree -l" from either the barebox environment or from any other
device I mounted (USB, MMC, etc).

Personally, I doubt we will ever use any devicetree other than the one
that is built into barebox initially, but having the ability to load
another one manually is nice (especially for hardware testing).
Honestly though, I personally find just making changes directly to the
board-*.c file and rebuilding the kernel to be easier than reading
through and changing dts files.

I'll try to get some of this cleaned up enough to turn into nice patch
files to post to the mailing list within the next couple of weeks.

Thanks again!
Michael Burkey



On 1/16/14, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Wed, Jan 15, 2014 at 01:35:15PM -0500, Michael Burkey wrote:
>> Sascha, thanks for the advice on the stack unwinding and other
>> debugging aids. It was a huge help.
>>
>> I have made progress and isolated and gotten past my earlier null
>> pointer problem -- it turned out to be an issue that you had already
>> fixed on the tip (the recent changes to armlinux_get_bootparams fixed
>> the null pointer issue).
>>
>> That said, I'm still having issues booting with an older kernel. Which
>> brings me to my next question....
>>
>> In the case where I am booting an old, non-devicetree, kernel with a
>> newer, devicetree, version of barebox, and then using "oftree -f" to
>> flush the devicetree before starting the kernel, what is the proper
>> way to have things like the boot parameters, the boot architecture,
>> etc. specified for passing to the older kernel? Just go back and add
>> them into the board files like they used to be in older versions of
>> barebox?
>
> yes.
>
>> Do you know if having stuff specified in both the old way and
>> in the oftree will cause any potential problems?
>
> Not sure if I understand you. The kernel either takes old style ATAGs or
> a devicetree (in the same pointer), barebox sets up either one or the
> other, but never both. The machine number becomes meaningless with
> devicetree support, it doesn't matter if it is specified or not.
>
>>
>> Basically, my goal is to have a version of barebox than can launch
>> either our current (old) kernel or a newer mainline version
>> interchangeably without having to upgrade barebox (basically, we will
>> probably initially be shipping an older kernel and then upgrading to a
>> newer one later -- and, if at all possible, I'd really rather not have
>> to incur the risk of having our users need to update barebox in the
>> field as well).
>
> Basically barebox has to know whether a kernel is to be started with
> devicetree or not, which means you have to have two boot entries, one
> with devicetree and one without. There are two ways around it:
>
> - Use bootloader spec based booting. This way you have text files on
>   your boot medium describing what to boot. This text file would
>   include information whether or not a kernel should be booted with
>   devicetree
> - Use appended devicetrees: cat zImage dtb > myImage. Such a kernel
>   can be started the traditional way and still uses devicetree.
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Sascha Hauer]

On Thu, Jan 16, 2014 at 04:18:10PM -0500, Michael Burkey wrote:
> Sascha,
> 
> Eureka! Based on your comments, things are starting to make sense now.
> My brain wasn't fully comprehending how things were now supposed to
> work.
> 
> I now have my kernel booting and things are working much better now (I
> still have to get all my partition info specified properly, but that's
> a fairly well understood task).
> 
> I also went back and watched your ELCE 2013 "Barebox and the
> Bootloader Specification" presentation on Youtube. This REALLY helped
> clarify things a bit -- although the direction things seem to be
> heading (away from raw NOR/NAND, etc) don't fit with the world in
> which I typically work (dedicated hardware, totally custom designed
> and manufactured carrier boards, etc).

Indeed bootloader Spec is more targeted to desktop/server PCs. The
thinking is that if we use an established standard (ok, we may argue how
established Bootloader Spec is), things get easier for the embedded case
aswell as we shift away from specialized solutions.

> 
> As everything I am currently working with is specifically from a raw
> NAND device and using UBI, the Bootloader Specification doesn't really
> do anything to help us (also, we will probably have no need for ever
> using any standard distribution of Linux, since we do our own custom
> rootfs that is trimmed to eliminate everything we don't need).

We use Bbootloader Spec on UBI aswell here. It currently requires some
out of tree patches, but I'll mainline them soon. Unfortunately
Bootloader Spec on UBI is not as straightforward as it is on SD/MMC, but
then again using UBI is not straightforward anyway ;)

> 
> The way I have things setup now (and apparently working):
> 
> 1) I have a dtb file built into barebox which is what it is using to
> initially configure it's devices.

Yes.

> 
> 2) I have all of the legacy type information (MACH_TYPE) specified in
> the board.c file and in the /env/config file. This is required to use
> the existing (older) kernel we have for the Variscite SOM.

Yes.

> 
> 3) I am (currently) using kobs-ng under Linux to initially program
> barebox into our NAND part and I am then using barebox to program any
> of the additional partitions based on an upgrade script we have
> written.

Yes. Ideally we would have a barebox_update handler so that barebox
could write itself into flash, but we currently don't have the kobs-ng
like code.

> 
> So, to boot the kernel we are using currently, I have modified the
> barebox startup script to do an "oftree -f" after startup and then use
> bootm to launch the kernel from it's appropriate NAND partition.

Yes. I must admit I'm not that happy with the "oftree -f" part since it
is not very obvious, but I don't have a better idea and this case should
become very rare soon.

> 
> Based on my understanding, I could also just as easily (once we get a
> newer kernel), *not* do the "oftree -f" and allow barebox to pass the
> stored devicetree along to the kernel for initial configuration. I
> could also just as easily load, other, different devicetree's using
> "oftree -l" from either the barebox environment or from any other
> device I mounted (USB, MMC, etc).

Yes. But that would require barebox to 'know' if the kernel is
devicetree or not.

> 
> Personally, I doubt we will ever use any devicetree other than the one
> that is built into barebox initially, but having the ability to load
> another one manually is nice (especially for hardware testing).

Devicetrees change over time. Kernel folk agrees that they should not
change in incompatible ways, but it happens from time to time that
newer kernels need additional properties/nodes. Experience shows that
you can start a newer kernel with an older devicetree, but you might
loose some features. It's always advisable to make the devicetree
changeable.

> Honestly though, I personally find just making changes directly to the
> board-*.c file and rebuilding the kernel to be easier than reading
> through and changing dts files.

That perspective changes over time. When I started with devicetree it
felt just like an additional layer that I had to understand and an
addional source of errors. Now I don't want to miss devicetrees anymore.
For the first time devicetrees offer a way to describe the crosslinks
between devices (SSI unit and Codec, v4l2 device and i2c encoder) which
is not subsystem specific. We can conveniently reference gpios without
relying on hardcoded numbers. Different board dts files look nearly
identical. The same dts files that works for the kernel can be used to
bring up barebox. It takes some time but it's really worth it.

> 
> I'll try to get some of this cleaned up enough to turn into nice patch
> files to post to the mailing list within the next couple of weeks.

Nice ;)

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

Sascha,

Things are working fairly well at this point.

I can boot barebox on the Variscite SOM.
I can boot Linux from barebox out of either NAND or off the SD card.
I can update the kernel and/or rootfs to NAND or SD from barebox.
I can mount and access both the SD card and USB mass storage devices.

So, basically, it's usable at this point.

Which brings me to my next couple of issues...

The first involves mounting USB mass storage devices. When I do a
probe of the USB bus, it works fine as long as I have at least one low
speed USB device connected (mouse, keyboard, etc). If I do not have a
low speed USB device connected, it never probes anything beyond the
initial hub and my flash drive never gets detected.

The Variscite dev board has three USB ports, but all of which are
connected to a USB hub IC on the board, so none of them are tied
directly to the iMX6 itself (all go through the hub).

The output is as follows (with a flash drive connected, but nothing else):

USB: scanning bus for devices...
Bus 001 Device 002: ID 0424:2514
Bus 001 Device 001: ID 0000:0000 EHCI Host Controller
2 USB Device(s) found

and with a mouse and a flash drive connected:

USB: scanning bus for devices...
Using index 0 for the new disk
Bus 001 Device 004: ID 125f:c08a ADATA USB Flash Drive
Bus 001 Device 002: ID 0424:2514
Bus 001 Device 001: ID 0000:0000 EHCI Host Controller
4 USB Device(s) found

Any ideas on where to look in the code for this?
Have you seen this behavior before?
I don't think it is a DTS file problem (unless I'm missing something).


The second item, which is MUCH lower priority, would be getting the
onboard PHY working to make transferring files to/from the board a bit
easier in barebox.

The issues I'm running into:
1) the board uses a Micrel KSZ9031 Phy, which doesn't appear to be
supported. However, it is very close to the KSZ9021 and I *think* I
have changed the micrel_phy.c file to where it probably would work.

2) The other issue is that the reset procedure used in Variscite's BSP
version of u-Boot for this phy is a bit, well, odd. I'm not sure if it
is specifically necessary or not. Basically, they initially assign all
of the ports over to GPIO6 so that they can force all the phy lines to
high during the reset. Then, once the reset is finished, they change
the iomux settings back to the correct ones for ethernet operation. I
suspect this would probably require adding code directly to board.c
and removing the fec entries from the DTS file.

3) Similarly with item #2, the power supply for the phy appears to be
routed through the PF0100, but is NOT enabled with the chips default
values. Immediately after startup, they hand configure the voltage
rail to the phy via I2C commands directly to the PF0100. I have
already added this code to the board.c file for barebox and it appears
to work properly. Unfortunately, the devicetree probe of the fec
controller happens BEFORE this is done, which means that the phy isn't
powered during the probe operation. Additionally, trying to move it
over to lowlevel.c for early startup (like the UART) isn't a simple
option since the I2C drivers need to be started so I can access the
PF0100.

So, if you were doing this, which option would you probably choose
(assuming my logic is correct):
1) just leave the fec out of the devicetree and bring it up later in
the board file (i.e. old style).
2) leave the fec out of the devicetree, configure the PF0100, then
apply devicetree overlays to add in the fec and then reprobe the tree?

Once again, the ethernet is not a big deal for me since we aren't
actually using it ourselves. It is just a bit of a convenience item to
have (though I can always use a USB NIC).

Thanks again for all your help!
Michael Burkey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

Sascha,

Part of my last post can be ignored -- specifically part of the stuff
on the ethernet controller.

I just discovered that using either "detect -a" or "detect miibus0"
works to properly detect and configure /dev/phy0.

Basically, the initial probe using devicetree fails, but once the
PF0100 is set correctly and a simple manual reset is done (same code
as you used on the pfla02), then the phy detects properly and I can
access the network.

So, is there an easy way to have it skip the initial probe that fails?

Was this possibly the idea behind why you have the fec disabled in the
pfla02.dtsi and then enable it in the pbab01.dts?

Basically, disable it for the first probe, then enable it in an
overlay and reprobe?

What I have now "works", but I prefer to do things the "right way" if possible.

Thanks!
Michael Burkey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Porting barebox (devicetree) to Variscite iMX6 SOM

[Sascha Hauer]

On Wed, Jan 29, 2014 at 04:10:14PM -0500, Michael Burkey wrote:
> Sascha,
> 
> Things are working fairly well at this point.
> 
> I can boot barebox on the Variscite SOM.
> I can boot Linux from barebox out of either NAND or off the SD card.
> I can update the kernel and/or rootfs to NAND or SD from barebox.
> I can mount and access both the SD card and USB mass storage devices.
> 
> So, basically, it's usable at this point.
> 
> Which brings me to my next couple of issues...
> 
> The first involves mounting USB mass storage devices. When I do a
> probe of the USB bus, it works fine as long as I have at least one low
> speed USB device connected (mouse, keyboard, etc). If I do not have a
> low speed USB device connected, it never probes anything beyond the
> initial hub and my flash drive never gets detected.
> 
> The Variscite dev board has three USB ports, but all of which are
> connected to a USB hub IC on the board, so none of them are tied
> directly to the iMX6 itself (all go through the hub).
> 
> The output is as follows (with a flash drive connected, but nothing else):
> 
> USB: scanning bus for devices...
> Bus 001 Device 002: ID 0424:2514
> Bus 001 Device 001: ID 0000:0000 EHCI Host Controller
> 2 USB Device(s) found
> 
> and with a mouse and a flash drive connected:
> 
> USB: scanning bus for devices...
> Using index 0 for the new disk
> Bus 001 Device 004: ID 125f:c08a ADATA USB Flash Drive
> Bus 001 Device 002: ID 0424:2514
> Bus 001 Device 001: ID 0000:0000 EHCI Host Controller
> 4 USB Device(s) found
> 
> Any ideas on where to look in the code for this?
> Have you seen this behavior before?

So your flash drive only gets detected when another device is also
connected? I've never seen that before. Normally once you can detect
the first hub behind your root hub everything should be fine. I have no
idea what such a behaviour could cause. I would enable debug messages in
the ehci/usb code, but ok, you probably did that already.

> I don't think it is a DTS file problem (unless I'm missing something).
> 
> 
> The second item, which is MUCH lower priority, would be getting the
> onboard PHY working to make transferring files to/from the board a bit
> easier in barebox.
> 
> The issues I'm running into:
> 1) the board uses a Micrel KSZ9031 Phy, which doesn't appear to be
> supported. However, it is very close to the KSZ9021 and I *think* I
> have changed the micrel_phy.c file to where it probably would work.
> 
> 2) The other issue is that the reset procedure used in Variscite's BSP
> version of u-Boot for this phy is a bit, well, odd. I'm not sure if it
> is specifically necessary or not. Basically, they initially assign all
> of the ports over to GPIO6 so that they can force all the phy lines to
> high during the reset. Then, once the reset is finished, they change
> the iomux settings back to the correct ones for ethernet operation. I
> suspect this would probably require adding code directly to board.c
> and removing the fec entries from the DTS file.

Some boards do this to configure the phy address which is specified by
bootstrap pins during phy reset. There's currently no code to describe
this behaviour in the devicetree, neither in barebox now in the kernel.
One way to accomplish this would be to add code to board.c which
configures the pins as gpios and sets the output values correctly. This
should be done in an earlier initcall than the fec driver has. Then
afterwards the fec driver could probe as usual from the devicetree. Make
sure to remove the phy-reset-gpio from devicetree as this would cause
another phy reset in the fec driver in which case your settings would be
lost again.

> 
> 3) Similarly with item #2, the power supply for the phy appears to be
> routed through the PF0100, but is NOT enabled with the chips default
> values. Immediately after startup, they hand configure the voltage
> rail to the phy via I2C commands directly to the PF0100. I have
> already added this code to the board.c file for barebox and it appears
> to work properly. Unfortunately, the devicetree probe of the fec
> controller happens BEFORE this is done, which means that the phy isn't
> powered during the probe operation. Additionally, trying to move it
> over to lowlevel.c for early startup (like the UART) isn't a simple
> option since the I2C drivers need to be started so I can access the
> PF0100.

I have nothing against moving the i2c driver to coredevice_initcall
which gives you fs_initcall to setup the power before the fec finally
gets probed in device_initcall.

All these initcall dependencies are not nice and the time will come when
we have to do something about it. That we have to add regulator support
gets more and more obvious...

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael D. Burkey]

Sascha,

I have enabled the USB debugging (and added some additional code as
well). I'm still trying to figure out exactly why it's not detecting
my flash drive without another device being present. One thing that is
weird is that it has to be a non-mass storage device of some kind for
things to work -- if I have 3 USB flash drives plugged in, it finds
nothing. If I plug in a mouse too, it see's all three of them. I'll
post more info and maybe a few questions as I progress.

I've got the PHY working on the Variscite part, but the code is ugly.
After digging into the KSZ9031 spec a bit deeper, it turns out that
the pins they are configuring as GPIO's during reset are NOT the
address pins -- they are the MODE pins on the PHY. Apparently, they
must not have included pull-ups on the board for the default state of
the pins during the PHY reset and are instead setting them in the
bootloader and then doing a manual reset of the PHY. That said, the
PHY appears to startup in the correct mode even if I don't modify the
pins, so it is possible they may actually have pull-ups on the pins
(either that, or the default state floats high enough to be latched as
1's and I'm just getting lucky). It would be really nice if I had the
schematics for the SOM -- I may just stick the board under a
magnifying glass and see if I can trace out those pins.

Thanks,
Michael Burkey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox