Re: Fwd: Barebox 2017.02 works great but no Linux Framebuffer... :-/

2017-06-26 Thread gianluca

On 06/26/2017 10:46 AM, Lucas Stach wrote:

Am Montag, den 26.06.2017, 10:40 +0200 schrieb gianluca:

During boot I can see no output on the framebuffer on the QuadPlus
and
the kernel log have those messages:


[4.914737] [ cut here ]
[4.914769] WARNING: CPU: 1 PID: 17 at
drivers/gpu/drm/drm_atomic_helper.c:1140
drm_atomic_helper_wait_for_vblanks+0x258/0x25c
[4.914772] [CRTC:24] vblank wait timed out
[4.914846] Modules linked in: evdev joydev rfkill at24
nvmem_imx_ocotp ci_hdrc_imx nvmem_core sx8656_ek(O) ci_hdrc
udc_core ehci_hcd usbcore usbmisc_imx coda phy_mxs_usb v4l2_mem2mem
panel_simple videobuf2_v4l2 imx_thermal videobuf2_dma_contig
imx2_wdt videobuf2_core snd_soc_fsl_asrc flexcan can_dev
videobuf2_vmalloc snd_soc_fsl_asoc_card videobuf2_memops pwm_bl
pwm_imx snd_ac97_codec backlight leds_gpio
[4.914856] CPU: 1 PID: 17 Comm: kworker/1:0 Tainted:
G   O4.9.7-EK20170623 #1
[4.914859] Hardware name: Freescale i.MX6 Quad/DualLite (Device
Tree)
[4.914875] Workqueue: events deferred_probe_work_func
[4.914900] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[4.914915] [] (show_stack) from []
(dump_stack+0x94/0xb0)
[4.914927] [] (dump_stack) from []
(__warn+0xf8/0x110)
[4.914937] [] (__warn) from []
(warn_slowpath_fmt+0x48/0x50)
[4.914951] [] (warn_slowpath_fmt) from []
(drm_atomic_helper_wait_for_vblanks+0x258/0x25c)
[4.914970] [] (drm_atomic_helper_wait_for_vblanks)
from [] (imx_drm_atomic_commit_tail+0x58/0x68)
[4.914982] [] (imx_drm_atomic_commit_tail) from
[] (commit_tail+0x50/0x6c)
[4.914992] [] (commit_tail) from []
(drm_atomic_helper_commit+0xa4/0xe4)
[4.915003] [] (drm_atomic_helper_commit) from
[] (imx_drm_atomic_commit+0x104/0x130)
[4.915021] [] (imx_drm_atomic_commit) from
[] (drm_atomic_commit+0x5c/0x68)
[4.915038] [] (drm_atomic_commit) from []
(restore_fbdev_mode+0x158/0x298)
[4.915051] [] (restore_fbdev_mode) from []
(drm_fb_helper_restore_fbdev_mode_unlocked+0x40/0x84)
[4.915063] []
(drm_fb_helper_restore_fbdev_mode_unlocked) from []
(drm_fb_helper_set_par+0x40/0x6c)
[4.915076] [] (drm_fb_helper_set_par) from
[] (fbcon_init+0x4b4/0x4f8)
[4.915088] [] (fbcon_init) from []
(visual_init+0xd4/0x11c)
[4.915102] [] (visual_init) from []
(do_bind_con_driver+0x14c/0x334)
[4.915112] [] (do_bind_con_driver) from []
(do_take_over_console+0x150/0x1b4)
[4.915121] [] (do_take_over_console) from
[] (do_fbcon_takeover+0x88/0xe8)
[4.915130] [] (do_fbcon_takeover) from []
(fbcon_event_notify+0x7c0/0x7f8)
[4.915142] [] (fbcon_event_notify) from []
(notifier_call_chain+0x54/0x94)
[4.915153] [] (notifier_call_chain) from []
(__blocking_notifier_call_chain+0x58/0x70)
[4.915164] [] (__blocking_notifier_call_chain) from
[] (blocking_notifier_call_chain+0x28/0x30)
[4.915175] [] (blocking_notifier_call_chain) from
[] (fb_notifier_call_chain+0x2c/0x30)
[4.915187] [] (fb_notifier_call_chain) from
[] (register_framebuffer+0x1f8/0x2b0)
[4.915200] [] (register_framebuffer) from
[] (drm_fb_helper_initial_config+0x260/0x408)
[4.915212] [] (drm_fb_helper_initial_config) from
[] (drm_fbdev_cma_init_with_funcs+0x90/0x110)
[4.915223] [] (drm_fbdev_cma_init_with_funcs) from
[] (drm_fbdev_cma_init+0x28/0x30)
[4.915236] [] (drm_fbdev_cma_init) from []
(imx_drm_bind+0x104/0x194)
[4.915254] [] (imx_drm_bind) from []
(try_to_bring_up_master+0x234/0x294)
[4.915266] [] (try_to_bring_up_master) from
[] (component_add+0xc0/0x158)
[4.915277] [] (component_add) from []
(ipu_drm_probe+0x68/0x74)
[4.915291] [] (ipu_drm_probe) from []
(platform_drv_probe+0x60/0xc0)
[4.915304] [] (platform_drv_probe) from []
(driver_probe_device+0x238/0x428)
[4.915314] [] (driver_probe_device) from []
(__device_attach_driver+0xac/0x10c)
[4.915324] [] (__device_attach_driver) from
[] (bus_for_each_drv+0x54/0x9c)
[4.915335] [] (bus_for_each_drv) from []
(__device_attach+0xb0/0x134)
[4.915344] [] (__device_attach) from []
(device_initial_probe+0x1c/0x20)
[4.915354] [] (device_initial_probe) from
[] (bus_probe_device+0x94/0x9c)
[4.915364] [] (bus_probe_device) from []
(deferred_probe_work_func+0x7c/0xc8)
[4.915377] [] (deferred_probe_work_func) from
[] (process_one_work+0x14c/0x440)
[4.915386] [] (process_one_work) from []
(worker_thread+0x54/0x504)
[4.915398] [] (worker_thread) from []
(kthread+0xf0/0x108)
[4.915415] [] (kthread) from []
(ret_from_fork+0x14/0x3c)
[4.915419] ---[ end trace 64ae59d2b69cc4d3 ]---



and after a while:


[   15.102758] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
[CRTC:24:crtc-0] flip_done timed out
[   25.342746] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
[CRTC:24:crtc-0] flip_done timed out
[   25.358582] Console: switching to colour frame buffer device
160x50
[   35.582744] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
[CRTC:24:crtc-0] flip_done timed out
[   

Re: Fwd: Barebox 2017.02 works great but no Linux Framebuffer... :-/

2017-06-26 Thread Lucas Stach
Am Montag, den 26.06.2017, 10:40 +0200 schrieb gianluca:
> On 06/23/2017 11:45 AM, gianluca wrote:
> > On 06/21/2017 05:30 PM, Lucas Stach wrote:
> > > > As you can see imx-drm.legacy_depth=32 is passed to the kernel
> > > > from
> > > > bootloader.
> > > 
> > > The module is called "imxdrm" without a dash, so the correct way
> > > to
> > > specify the parameter on the command line is
> > > "imxdrm.legacyfb_depth=32".
> > 
> > It works now, the culprit was the name of the driver: imxdrm is the
> > right one.
> > 
> 
> In Barebox everything looks like good. Both boards are running quite 
> well and all stuff are working as expected.
> In Linux I have some strange beahviours.
> 
> If I replace the bootloader and the device-tree on the microSD card
> (the 
> Linux kernel and the rootfilesystem remains the same) the
> iMX6QuadPlus 
> refuses to use the framebuffer.
> 
> Frankly, I do not understand how those drivers react differently if
> they 
> are running on the DualLite or the QuadPlus.
> 
> The main differences in the device-tree are (for Barebox point of
> view):
> > 
> > diff -Nru imx6dl-eurek-ek360.dts imx6qp-eurek-ek360.dts
> > --- imx6dl-eurek-ek360.dts  2017-06-21 12:22:32.0
> > +0200
> > +++ imx6qp-eurek-ek360.dts  2017-06-21 13:46:35.0
> > +0200
> > @@ -1,5 +1,5 @@
> >  /*
> > - * $Id: imx6dl-eurek-ek360.dts,v 1.4 2017/06/21 10:22:32 gianluca
> > Exp $
> > + * $Id: imx6qp-eurek-ek360.dts,v 1.5 2017/06/21 11:46:35 gianluca
> > Exp $
> >   *
> >   * Copyright 2016/2017 Gianluca Renzi, Eurek Elettronica S.R.L.
> >   * Copyright 2014 Raphaël Poggi
> > @@ -18,13 +18,13 @@
> > 
> >  #include 
> >  #include 
> > -#include 
> > -#include 
> > -#include "imx6dl.dtsi"
> > +#include 
> > +#include "imx6qdl.dtsi"
> > +#include "imx6q.dtsi"
> > 
> >  / {
> > -   model = "Eurek EK360 i.MX6DL";
> > -   compatible = "eurek,ek360", "fsl,imx6dl";
> > +   model = "Eurek EK360 i.MX6QP";
> > +   compatible = "eurek,ek360", "fsl,imx6qp";
> > 
> >     chosen {
> >     linux,stdout-path = 
> 
> Just a matter of include and a compatible property line...
> 
> Of course the flash header and memory initializers are still
> different 
> for both processors (NoC and other stuff).
> 
> In Linux the only thing wich differs is the device-tree file (more
> or 
> less like in Barebox):
> 
> > --- linux-4.9.7-EK360-EK360DL-dts.patch 2017-06-21
> > 12:42:00.944833220 +0200
> > +++ linux-4.9.7-EK360-EK360QP-dts.patch 2017-06-22
> > 17:29:24.634534659 +0200
> > @@ -1,8 +1,8 @@
> >  a/arch/arm/boot/dts/imx6dl-eurek-ek360.dts 1970-01-01
> > 01:00:00.0 +0100
> > -+++ b/arch/arm/boot/dts/imx6dl-eurek-ek360.dts 2017-06-21
> > 12:42:00.412833238 +0200
> > +--- a/arch/arm/boot/dts/imx6qp-eurek-ek360.dts 1970-01-01
> > 01:00:00.0 +0100
> >  b/arch/arm/boot/dts/imx6qp-eurek-ek360.dts 2017-06-22
> > 17:29:24.634534659 +0200
> >  @@ -0,0 +1,626 @@
> >  +/*
> > -+ * $Id: imx6dl-eurek-ek360.dts,v 1.4 2017/06/21 10:22:32 gianluca
> > Exp $
> > ++ * $Id: imx6qp-eurek-ek360.dts,v 1.5 2017/06/21 11:46:35 gianluca
> > Exp $
> >  + *
> >  + * Copyright 2016/2017 Gianluca Renzi, Eurek Elettronica S.R.L.
> >  + * Copyright 2014 Raphaël Poggi
> > @@ -21,13 +21,13 @@
> >  +
> >  +#include 
> >  +#include 
> > -+/* #include  */
> > -+#include "imx6qdl.dtsi"
> > -+#include "imx6dl.dtsi"
> > ++/* #include  */
> > ++/* #include "imx6qdl.dtsi" */
> > ++#include "imx6qp.dtsi"
> >  +
> >  +/ {
> > -+  model = "Eurek EK360 i.MX6DL";
> > -+  compatible = "eurek,ek360", "fsl,imx6dl";
> > ++  model = "Eurek EK360 i.MX6QP";
> > ++  compatible = "eurek,ek360", "fsl,imx6qp";
> >  +
> >  +  chosen {
> >  +  linux,stdout-path = 
> 
> The DuaLite has those includes:
> 
> #include 
> #include 
> /* #include  */
> #include "imx6qdl.dtsi"
> #include "imx6dl.dtsi"
> 
> and the compatible string is: compatible = "eurek,ek360",
> "fsl,imx6dl"
> 
> The QuadPlus has those includes:
> 
> #include 
> #include 
> /* #include  */
> /* #include "imx6qdl.dtsi" */
> #include "imx6qp.dtsi"
> 
> and the compatible string is: compatible = "eurek,ek360",
> "fsl,imx6qp"
> 
> During boot I can see no output on the framebuffer on the QuadPlus
> and 
> the kernel log have those messages:
> 
> > [4.914737] [ cut here ]
> > [4.914769] WARNING: CPU: 1 PID: 17 at
> > drivers/gpu/drm/drm_atomic_helper.c:1140
> > drm_atomic_helper_wait_for_vblanks+0x258/0x25c
> > [4.914772] [CRTC:24] vblank wait timed out
> > [4.914846] Modules linked in: evdev joydev rfkill at24
> > nvmem_imx_ocotp ci_hdrc_imx nvmem_core sx8656_ek(O) ci_hdrc
> > udc_core ehci_hcd usbcore usbmisc_imx coda phy_mxs_usb v4l2_mem2mem
> > panel_simple videobuf2_v4l2 imx_thermal videobuf2_dma_contig
> > imx2_wdt videobuf2_core snd_soc_fsl_asrc flexcan can_dev
> > videobuf2_vmalloc snd_soc_fsl_asoc_card videobuf2_memops pwm_bl
> > pwm_imx snd_ac97_codec backlight leds_gpio
> > [4.914856] CPU: 1 PID: 17 Comm: kworker/1:0 

Re: Fwd: Barebox 2017.02 works great but no Linux Framebuffer... :-/

2017-06-26 Thread gianluca

On 06/23/2017 11:45 AM, gianluca wrote:

On 06/21/2017 05:30 PM, Lucas Stach wrote:

As you can see imx-drm.legacy_depth=32 is passed to the kernel from
bootloader.


The module is called "imxdrm" without a dash, so the correct way to
specify the parameter on the command line is "imxdrm.legacyfb_depth=32".




It works now, the culprit was the name of the driver: imxdrm is the
right one.



In Barebox everything looks like good. Both boards are running quite 
well and all stuff are working as expected.

In Linux I have some strange beahviours.

If I replace the bootloader and the device-tree on the microSD card (the 
Linux kernel and the rootfilesystem remains the same) the iMX6QuadPlus 
refuses to use the framebuffer.


Frankly, I do not understand how those drivers react differently if they 
are running on the DualLite or the QuadPlus.


The main differences in the device-tree are (for Barebox point of view):


diff -Nru imx6dl-eurek-ek360.dts imx6qp-eurek-ek360.dts
--- imx6dl-eurek-ek360.dts  2017-06-21 12:22:32.0 +0200
+++ imx6qp-eurek-ek360.dts  2017-06-21 13:46:35.0 +0200
@@ -1,5 +1,5 @@
 /*
- * $Id: imx6dl-eurek-ek360.dts,v 1.4 2017/06/21 10:22:32 gianluca Exp $
+ * $Id: imx6qp-eurek-ek360.dts,v 1.5 2017/06/21 11:46:35 gianluca Exp $
  *
  * Copyright 2016/2017 Gianluca Renzi, Eurek Elettronica S.R.L.
  * Copyright 2014 Raphaël Poggi
@@ -18,13 +18,13 @@

 #include 
 #include 
-#include 
-#include 
-#include "imx6dl.dtsi"
+#include 
+#include "imx6qdl.dtsi"
+#include "imx6q.dtsi"

 / {
-   model = "Eurek EK360 i.MX6DL";
-   compatible = "eurek,ek360", "fsl,imx6dl";
+   model = "Eurek EK360 i.MX6QP";
+   compatible = "eurek,ek360", "fsl,imx6qp";

chosen {
linux,stdout-path = 


Just a matter of include and a compatible property line...

Of course the flash header and memory initializers are still different 
for both processors (NoC and other stuff).


In Linux the only thing wich differs is the device-tree file (more or 
less like in Barebox):



--- linux-4.9.7-EK360-EK360DL-dts.patch 2017-06-21 12:42:00.944833220 +0200
+++ linux-4.9.7-EK360-EK360QP-dts.patch 2017-06-22 17:29:24.634534659 +0200
@@ -1,8 +1,8 @@
 a/arch/arm/boot/dts/imx6dl-eurek-ek360.dts 1970-01-01 01:00:00.0 
+0100
-+++ b/arch/arm/boot/dts/imx6dl-eurek-ek360.dts 2017-06-21 12:42:00.412833238 
+0200
+--- a/arch/arm/boot/dts/imx6qp-eurek-ek360.dts 1970-01-01 01:00:00.0 
+0100
 b/arch/arm/boot/dts/imx6qp-eurek-ek360.dts 2017-06-22 17:29:24.634534659 
+0200
 @@ -0,0 +1,626 @@
 +/*
-+ * $Id: imx6dl-eurek-ek360.dts,v 1.4 2017/06/21 10:22:32 gianluca Exp $
++ * $Id: imx6qp-eurek-ek360.dts,v 1.5 2017/06/21 11:46:35 gianluca Exp $
 + *
 + * Copyright 2016/2017 Gianluca Renzi, Eurek Elettronica S.R.L.
 + * Copyright 2014 Raphaël Poggi
@@ -21,13 +21,13 @@
 +
 +#include 
 +#include 
-+/* #include  */
-+#include "imx6qdl.dtsi"
-+#include "imx6dl.dtsi"
++/* #include  */
++/* #include "imx6qdl.dtsi" */
++#include "imx6qp.dtsi"
 +
 +/ {
-+  model = "Eurek EK360 i.MX6DL";
-+  compatible = "eurek,ek360", "fsl,imx6dl";
++  model = "Eurek EK360 i.MX6QP";
++  compatible = "eurek,ek360", "fsl,imx6qp";
 +
 +  chosen {
 +  linux,stdout-path = 


The DuaLite has those includes:

#include 
#include 
/* #include  */
#include "imx6qdl.dtsi"
#include "imx6dl.dtsi"

and the compatible string is: compatible = "eurek,ek360", "fsl,imx6dl"

The QuadPlus has those includes:

#include 
#include 
/* #include  */
/* #include "imx6qdl.dtsi" */
#include "imx6qp.dtsi"

and the compatible string is: compatible = "eurek,ek360", "fsl,imx6qp"

During boot I can see no output on the framebuffer on the QuadPlus and 
the kernel log have those messages:



[4.914737] [ cut here ]
[4.914769] WARNING: CPU: 1 PID: 17 at 
drivers/gpu/drm/drm_atomic_helper.c:1140 
drm_atomic_helper_wait_for_vblanks+0x258/0x25c
[4.914772] [CRTC:24] vblank wait timed out
[4.914846] Modules linked in: evdev joydev rfkill at24 nvmem_imx_ocotp 
ci_hdrc_imx nvmem_core sx8656_ek(O) ci_hdrc udc_core ehci_hcd usbcore 
usbmisc_imx coda phy_mxs_usb v4l2_mem2mem panel_simple videobuf2_v4l2 
imx_thermal videobuf2_dma_contig imx2_wdt videobuf2_core snd_soc_fsl_asrc 
flexcan can_dev videobuf2_vmalloc snd_soc_fsl_asoc_card videobuf2_memops pwm_bl 
pwm_imx snd_ac97_codec backlight leds_gpio
[4.914856] CPU: 1 PID: 17 Comm: kworker/1:0 Tainted: G   O
4.9.7-EK20170623 #1
[4.914859] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[4.914875] Workqueue: events deferred_probe_work_func
[4.914900] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[4.914915] [] (show_stack) from [] 
(dump_stack+0x94/0xb0)
[4.914927] [] (dump_stack) from [] (__warn+0xf8/0x110)
[4.914937] [] (__warn) from [] 
(warn_slowpath_fmt+0x48/0x50)
[4.914951] [] (warn_slowpath_fmt) from [] 
(drm_atomic_helper_wait_for_vblanks+0x258/0x25c)
[ 

Re: [PATCH v5] arm: boards: phytec-som-am335x: Update boot scripts

2017-06-26 Thread Sascha Hauer
On Tue, Jun 20, 2017 at 05:42:22PM +0200, Daniel Schultz wrote:
> Expand the boot scripts with EMMC and add a default file source for
> expansions.
> 
> Removed "rw" and "rootwait" bootargs from existing boot scripts.

Why is "rootwait" removed? From my experience adding "rootwait" is
pretty essential when booting from mmc. Has that changed?

>  
> -if [ $bootsource = mmc ]; then
> - global.boot.default="mmc nand spi net"
> +if [ -e /dev/mmc1.0 ]; then
> + nvmem="emmc"
> +else
> + nvmem="nand"
> +fi
> +
> +if [ $bootsource = mmc -a $bootsource_instance = 1 ]; then
> + global.boot.default="emmc mmc spi net"
> +elif [ $bootsource = mmc -a $bootsource_instance = 0 ]; then
> + global.boot.default="mmc $nvmem spi net"
>  elif [ $bootsource = nand ]; then
>   global.boot.default="nand spi mmc net"
>  elif [ $bootsource = spi ]; then
> - global.boot.default="spi nand mmc net"
> + global.boot.default="spi $nvmem mmc net"
>  elif [ $bootsource = net ]; then
> - global.boot.default="net nand spi mmc"
> + global.boot.default="net $nvmem spi mmc"
>  fi

Normally the desired behaviour is that the bootsource can be changed
persistently by setting nv.boot.default to the desired source. This
does not work when global.boot.default gets overwritten after the nvvars
have been read from the environment.

This behaviour is not changed with this patch, but I would welcome a
patch that changes this script to the desired behaviour. This could
be done by changing global.boot.default only when nv.boot.default is
empty.

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- |

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


Re: [PATCH] defaultenv: bin: init: Add sourcing of config-expansions

2017-06-26 Thread Sascha Hauer
On Tue, Jun 20, 2017 at 05:50:56PM +0200, Daniel Schultz wrote:
> Hi,
> 
> Am 19.06.2017 um 09:34 schrieb Sascha Hauer:
> > On Tue, Jun 13, 2017 at 03:37:00PM +0200, Daniel Schultz wrote:
> > > This patch adds a further layer to the config hierarchy. It allows a
> > > dynamic configuration of expansions.
> > > 
> > > Signed-off-by: Daniel Schultz 
> > > ---
> > >   defaultenv/defaultenv-2-base/bin/init | 1 +
> > >   1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/defaultenv/defaultenv-2-base/bin/init 
> > > b/defaultenv/defaultenv-2-base/bin/init
> > > index 7af3c7d..a93ea58 100644
> > > --- a/defaultenv/defaultenv-2-base/bin/init
> > > +++ b/defaultenv/defaultenv-2-base/bin/init
> > > @@ -25,6 +25,7 @@ magicvar -a global.allow_color "Allow color on the 
> > > console (boolean)"
> > >   [ -z "${global.editcmd}" ] && global.editcmd=sedit
> > >   [ -e /env/config-board ] && /env/config-board
> > > +[ -e /env/config-expansions ] && /env/config-expansions
> > 
> > I read the last thread again and I think my question remains
> > unanswered. Why can't you put the config-expansions to /env/init/ and
> > let it be executed automatically without changing /bin/init?
> > 
> I can change the path of the config-expanions file without problems, but I
> thought there could be more who need a config for expansions. So, they have
> config files with a same behavior in different dirs.

I think we are talking at cross-purposes. All files in /env/init/ are
executed by the init script, so adding stuff that shall be executed
during init to that directory would be the natural way to "expand the
config".

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- |

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