Re: iMX6Q First boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/25/2016 08:27 PM, Andrey Smirnov wrote:
On Thu, Feb 25, 2016 at 5:50 AM, gianluca <gianlucarenzi@xxxxxxxx> wrote:
Hello list,
I am trying to bootup my custom designed board (actually a rev.0, but I know
it will need a rev.1 ASAP ;-).

I started with the latest (2016.02) barebox version, adding my board to the
Kconfig & Makefile stuff, copying the udoo stuff to the
arch/arm/boards/eurek-ek360 (as the board name is EK360) and cut-off any
unneeded initialization.

I am using imx_v7_defconfig as a starting point for configuration.

I kept the device tree file as short as possible, keeping only the model,
memory, gpio-pinmux for uart (debug) and the uart3 configurator.

In attachment there are the board.c, the lowlevel.c and the device-tree
file.

gianluca, the information you included is somewhat incomplete.
Attached file is a .dsti file (include file, not a standalone .dts)
which references phandles not defined in the file itself, so it seems
like there should be more to it.


The .dts file is almost empty. In attachment there is such a file. ;-)


However there are a couple of things to note about the code you included:

  - The device tree code that you provided doesn't have
     chosen {
           linux,stdout-path = <something>;
      };
      which means that BB's console subsystem doesn't have a assigned
"stdout" device, which might explain why you don't see the output


Even if it says: linux,stdout-path = .... ??? I suppose it was good only for Linux Kernel. My goal is to have ONLY one device-tree for Linux & Barebox. It is simpler to maintain, and if I add something to linux, it is automagically added to barebox too (if barebox drivers exists...)


  - Udoo board, that you used as a reference for your implementation
actually doesn't "support" for CONFIG_DEBUG_LL, and what I mean by
this is that there's no code in lowlevel.c that would set-up pinmux or
UART blocks correctly (see phytech-som-imx6/lowlevel.c for example),
so the  fact that you were able to see any output would mean that
either default in all involved registers are good for your board or
that settings were set during some other initialization process (most
likely when UART driver was probed and pinmux configured as a part of
it)


I didn't kown it. I will try ASAP.


Hope this helps,

I hope too... ;-)


--
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212
/*
 * Copyright 2014 Raphaël Poggi
 * Copyright 2012 Freescale Semiconductor, Inc.
 * Copyright 2011 Linaro Ltd.
 *
 * 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 <arm/imx6q.dtsi>
#include "imx6q.dtsi"
#include "imx6q-eurek-ek360.dtsi"

/ {
       model = "EK360 Eurek i.MX6 Quad";
       compatible = "eurek,ek360", "fsl,imx6q";
};
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox

[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux