* Porting barebox (devicetree) to Variscite iMX6 SOM @ 2013-12-11 17:07 Michael Burkey 2013-12-11 23:17 ` Alexander Aring 2013-12-12 8:04 ` Sascha Hauer 0 siblings, 2 replies; 24+ messages in thread From: Michael Burkey @ 2013-12-11 17:07 UTC (permalink / raw) To: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-11 17:07 Porting barebox (devicetree) to Variscite iMX6 SOM Michael Burkey @ 2013-12-11 23:17 ` Alexander Aring 2013-12-12 8:04 ` Sascha Hauer 1 sibling, 0 replies; 24+ messages in thread From: Alexander Aring @ 2013-12-11 23:17 UTC (permalink / raw) To: Michael Burkey; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-11 17:07 Porting barebox (devicetree) to Variscite iMX6 SOM Michael Burkey 2013-12-11 23:17 ` Alexander Aring @ 2013-12-12 8:04 ` Sascha Hauer 2013-12-12 18:49 ` Michael Burkey 1 sibling, 1 reply; 24+ messages in thread From: Sascha Hauer @ 2013-12-12 8:04 UTC (permalink / raw) To: Michael Burkey; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-12 8:04 ` Sascha Hauer @ 2013-12-12 18:49 ` Michael Burkey 2013-12-12 18:56 ` Michael Burkey 2013-12-12 19:58 ` Sascha Hauer 0 siblings, 2 replies; 24+ messages in thread From: Michael Burkey @ 2013-12-12 18:49 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-12 18:49 ` Michael Burkey @ 2013-12-12 18:56 ` Michael Burkey 2013-12-12 19:12 ` Alexander Aring 2013-12-12 19:58 ` Sascha Hauer 1 sibling, 1 reply; 24+ messages in thread From: Michael Burkey @ 2013-12-12 18:56 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-12 18:56 ` Michael Burkey @ 2013-12-12 19:12 ` Alexander Aring 2013-12-12 19:24 ` Michael Burkey 0 siblings, 1 reply; 24+ messages in thread From: Alexander Aring @ 2013-12-12 19:12 UTC (permalink / raw) To: Michael Burkey; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-12 19:12 ` Alexander Aring @ 2013-12-12 19:24 ` Michael Burkey 0 siblings, 0 replies; 24+ messages in thread From: Michael Burkey @ 2013-12-12 19:24 UTC (permalink / raw) To: Alexander Aring; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-12 18:49 ` Michael Burkey 2013-12-12 18:56 ` Michael Burkey @ 2013-12-12 19:58 ` Sascha Hauer 2013-12-12 22:44 ` Michael Burkey 1 sibling, 1 reply; 24+ messages in thread From: Sascha Hauer @ 2013-12-12 19:58 UTC (permalink / raw) To: Michael Burkey; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-12 19:58 ` Sascha Hauer @ 2013-12-12 22:44 ` Michael Burkey 2013-12-18 16:39 ` Michael Burkey 0 siblings, 1 reply; 24+ messages in thread From: Michael Burkey @ 2013-12-12 22:44 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-12 22:44 ` Michael Burkey @ 2013-12-18 16:39 ` Michael Burkey 2013-12-18 21:34 ` Michael Burkey 0 siblings, 1 reply; 24+ messages in thread From: Michael Burkey @ 2013-12-18 16:39 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-18 16:39 ` Michael Burkey @ 2013-12-18 21:34 ` Michael Burkey 2013-12-19 8:09 ` Sascha Hauer 0 siblings, 1 reply; 24+ messages in thread From: Michael Burkey @ 2013-12-18 21:34 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-18 21:34 ` Michael Burkey @ 2013-12-19 8:09 ` Sascha Hauer 2014-01-09 7:20 ` Michael Burkey 0 siblings, 1 reply; 24+ messages in thread From: Sascha Hauer @ 2013-12-19 8:09 UTC (permalink / raw) To: Michael Burkey; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2013-12-19 8:09 ` Sascha Hauer @ 2014-01-09 7:20 ` Michael Burkey 2014-01-09 19:59 ` Michael Burkey 2014-01-10 8:13 ` Sascha Hauer 0 siblings, 2 replies; 24+ messages in thread From: Michael Burkey @ 2014-01-09 7:20 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Porting barebox (devicetree) to Variscite iMX6 SOM 2014-01-09 7:20 ` Michael Burkey @ 2014-01-09 19:59 ` Michael Burkey 2014-01-10 8:00 ` Sascha Hauer 2014-01-10 8:13 ` Sascha Hauer 1 sibling, 1 reply; 24+ messages in thread From: Michael Burkey @ 2014-01-09 19:59 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2014-01-09 19:59 ` Michael Burkey @ 2014-01-10 8:00 ` Sascha Hauer 0 siblings, 0 replies; 24+ messages in thread From: Sascha Hauer @ 2014-01-10 8:00 UTC (permalink / raw) To: Michael Burkey; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2014-01-09 7:20 ` Michael Burkey 2014-01-09 19:59 ` Michael Burkey @ 2014-01-10 8:13 ` Sascha Hauer 2014-01-15 18:35 ` Michael Burkey 1 sibling, 1 reply; 24+ messages in thread From: Sascha Hauer @ 2014-01-10 8:13 UTC (permalink / raw) To: Michael Burkey; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Porting barebox (devicetree) to Variscite iMX6 SOM 2014-01-10 8:13 ` Sascha Hauer @ 2014-01-15 18:35 ` Michael Burkey 2014-01-16 14:13 ` Sascha Hauer 0 siblings, 1 reply; 24+ messages in thread From: Michael Burkey @ 2014-01-15 18:35 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2014-01-15 18:35 ` Michael Burkey @ 2014-01-16 14:13 ` Sascha Hauer 2014-01-16 21:18 ` Michael Burkey 0 siblings, 1 reply; 24+ messages in thread From: Sascha Hauer @ 2014-01-16 14:13 UTC (permalink / raw) To: Michael Burkey; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Porting barebox (devicetree) to Variscite iMX6 SOM 2014-01-16 14:13 ` Sascha Hauer @ 2014-01-16 21:18 ` Michael Burkey 2014-01-20 8:00 ` Sascha Hauer 0 siblings, 1 reply; 24+ messages in thread From: Michael Burkey @ 2014-01-16 21:18 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2014-01-16 21:18 ` Michael Burkey @ 2014-01-20 8:00 ` Sascha Hauer 2014-01-29 21:10 ` Michael Burkey 0 siblings, 1 reply; 24+ messages in thread From: Sascha Hauer @ 2014-01-20 8:00 UTC (permalink / raw) To: Michael Burkey; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Porting barebox (devicetree) to Variscite iMX6 SOM 2014-01-20 8:00 ` Sascha Hauer @ 2014-01-29 21:10 ` Michael Burkey 2014-01-29 21:53 ` Michael Burkey 2014-02-01 18:35 ` Sascha Hauer 0 siblings, 2 replies; 24+ messages in thread From: Michael Burkey @ 2014-01-29 21:10 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2014-01-29 21:10 ` Michael Burkey @ 2014-01-29 21:53 ` Michael Burkey 2014-02-01 18:35 ` Sascha Hauer 1 sibling, 0 replies; 24+ messages in thread From: Michael Burkey @ 2014-01-29 21:53 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM 2014-01-29 21:10 ` Michael Burkey 2014-01-29 21:53 ` Michael Burkey @ 2014-02-01 18:35 ` Sascha Hauer 2014-02-04 21:44 ` Michael D. Burkey 1 sibling, 1 reply; 24+ messages in thread From: Sascha Hauer @ 2014-02-01 18:35 UTC (permalink / raw) To: Michael Burkey; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Porting barebox (devicetree) to Variscite iMX6 SOM 2014-02-01 18:35 ` Sascha Hauer @ 2014-02-04 21:44 ` Michael D. Burkey 0 siblings, 0 replies; 24+ messages in thread From: Michael D. Burkey @ 2014-02-04 21:44 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-02-04 21:52 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-12-11 17:07 Porting barebox (devicetree) to Variscite iMX6 SOM Michael Burkey 2013-12-11 23:17 ` Alexander Aring 2013-12-12 8:04 ` Sascha Hauer 2013-12-12 18:49 ` Michael Burkey 2013-12-12 18:56 ` Michael Burkey 2013-12-12 19:12 ` Alexander Aring 2013-12-12 19:24 ` Michael Burkey 2013-12-12 19:58 ` Sascha Hauer 2013-12-12 22:44 ` Michael Burkey 2013-12-18 16:39 ` Michael Burkey 2013-12-18 21:34 ` Michael Burkey 2013-12-19 8:09 ` Sascha Hauer 2014-01-09 7:20 ` Michael Burkey 2014-01-09 19:59 ` Michael Burkey 2014-01-10 8:00 ` Sascha Hauer 2014-01-10 8:13 ` Sascha Hauer 2014-01-15 18:35 ` Michael Burkey 2014-01-16 14:13 ` Sascha Hauer 2014-01-16 21:18 ` Michael Burkey 2014-01-20 8:00 ` Sascha Hauer 2014-01-29 21:10 ` Michael Burkey 2014-01-29 21:53 ` Michael Burkey 2014-02-01 18:35 ` Sascha Hauer 2014-02-04 21:44 ` Michael D. Burkey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox