boot problem w/ barebox

boot problem w/ barebox

[Enrico Weigelt, metux IT consult]

Hi folks,


I've got a really strange booting problem on an phycore-imx6
based board (pretty much the same as mira):

* barebox v2017.06.1-phy2 comes up properly, but cant boot
   the kernel (v4.13) - just hangs w/o any output (not even
   uncompression message)
* putting the kernel manually into the factory-image (sdcard)
   w/ old 2015 barebox boots the kernel
* w/ DEBUG_LL + earlyprintk it doesn't even does that, just
   hangs like w/ new barebox


Here's the last output I've got: (added few more debug outputs)

 > Loading ARM Linux zImage '/mnt/mmc/boot/zImage'
 > Loading devicetree from '/mnt/mmc/boot/imx6q-phytec-mira-rdk-emmc.dtb'
 > Updating DT commandline:  console=ttymxc1,115200n8 
root=/dev/mmcblk0p2 rootwait rw earlyprintk=1
 > DT commandline:  console=ttymxc1,115200n8  root=/dev/mmcblk0p2 
rootwait rw earlyprintk=1
 > booting kernel with devicetree
 > start_linux: kernel entry point: 12000000
 >                            dtb: 18000000
 >                           swap: 0
 >                           arch: 0
 > shutting down barebox

My first suspicion was zero'ed DT memory node (which OTOH doesn't
explain why earlyprintk doesn't work), but fixing that didn't help.

Could there be any vital low-level init missing in the new bbx ?
Maybe the entry point correct ?

Any ideas where I could have a deeper look at ?


thx.

--mtx

-- 

mit freundlichen Grüßen
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287

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

Re: boot problem w/ barebox

[Uwe Kleine-König]

On Sat, Sep 09, 2017 at 11:01:34AM +0200, Enrico Weigelt, metux IT consult wrote:
> Hi folks,
> 
> 
> I've got a really strange booting problem on an phycore-imx6
> based board (pretty much the same as mira):
> 
> * barebox v2017.06.1-phy2 comes up properly, but cant boot
>   the kernel (v4.13) - just hangs w/o any output (not even
>   uncompression message)
> * putting the kernel manually into the factory-image (sdcard)
>   w/ old 2015 barebox boots the kernel
> * w/ DEBUG_LL + earlyprintk it doesn't even does that, just
>   hangs like w/ new barebox
> 
> 
> Here's the last output I've got: (added few more debug outputs)
> 
> > Loading ARM Linux zImage '/mnt/mmc/boot/zImage'
> > Loading devicetree from '/mnt/mmc/boot/imx6q-phytec-mira-rdk-emmc.dtb'
> > Updating DT commandline:  console=ttymxc1,115200n8 root=/dev/mmcblk0p2
> rootwait rw earlyprintk=1
> > DT commandline:  console=ttymxc1,115200n8  root=/dev/mmcblk0p2 rootwait rw
> earlyprintk=1
> > booting kernel with devicetree
> > start_linux: kernel entry point: 12000000
> >                            dtb: 18000000
> >                           swap: 0
> >                           arch: 0
> > shutting down barebox
> 
> My first suspicion was zero'ed DT memory node (which OTOH doesn't
> explain why earlyprintk doesn't work), but fixing that didn't help.
> 
> Could there be any vital low-level init missing in the new bbx ?
> Maybe the entry point correct ?
> 
> Any ideas where I could have a deeper look at ?

Try adding a #define DEBUG in linux-4.13/arch/arm/boot/compressed/head.S
and make sure enabled DEBUG_LL and selected the right UART in your
.config.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

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

Re: boot problem w/ barebox

[Enrico Weigelt, metux IT consult]

On 11.09.2017 09:16, Uwe Kleine-König wrote:

> Try adding a #define DEBUG in linux-4.13/arch/arm/boot/compressed/head.S > and make sure enabled DEBUG_LL and selected the right UART in your> 
.config.
After deep digging in the init code, I've meanwhile fixed it (at least
with self-compiled 2015 bbx - didn't try newer versions yet). In the end
was just dt misconfiguration (that wasn't obvious in this dts wood,
which I ported from the old 4.1-phy tree): the debug uart was disabled.

This lead to some funny situations:

* DEBUG_ll worked after fixing the port number (the counting is a bit
   confusing: ttymxc1 is #2)
* console works up to the point where the uarts tty drivers are
   configured. as the uart was disabled in dt, no tty driver was
   associated (while ll driver was still active), so the clock was
   disabled on some point, leading to supposedly hangup (actually,
   just the console was gone)
* hacking out the clock disable lead further to the point where rootfs
   is mounted and init started
* init couldn't do much, as it didn't get a console. first I suspected
   rootfs would be mounted too late, but then turned out that
   /dev/console indeed was there (in the internal initramfs), but open()
   returned ENODEV (hmm, we should have verbose errno printouts - already
   got some patches for that in some other trees ...)
* the reason for ENODEV was the lack of an tty driver for the uart
   (printk() still went through ll driver) -- may we should add a proper
   warning for that ...


--mtx

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

Re: [ptxdist] boot problem w/ barebox

[Uwe Kleine-König]

Hello,

On Mon, Sep 11, 2017 at 08:47:03PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 11.09.2017 09:16, Uwe Kleine-König wrote:
> 
> > Try adding a #define DEBUG in linux-4.13/arch/arm/boot/compressed/head.S
> > > and make sure enabled DEBUG_LL and selected the right UART in your>
> .config.
> After deep digging in the init code, I've meanwhile fixed it (at least
> with self-compiled 2015 bbx - didn't try newer versions yet). In the end
> was just dt misconfiguration (that wasn't obvious in this dts wood,
> which I ported from the old 4.1-phy tree): the debug uart was disabled.
> 
> This lead to some funny situations:
> 
> * DEBUG_ll worked after fixing the port number (the counting is a bit
>   confusing: ttymxc1 is #2)

CONFIG_DEBUG_IMX_UART_PORT=2 means it should use UART-2 as documented in
the reference manual. But yeah, this is confusing, the problem is that
the hardware guy numbering the UARTS named the first UART UART-1 which
isn't what a kernel hacker would have picked.

> * console works up to the point where the uarts tty drivers are
>   configured. as the uart was disabled in dt, no tty driver was
>   associated (while ll driver was still active), so the clock was
>   disabled on some point, leading to supposedly hangup (actually,
>   just the console was gone)

When the UART tty driver are configured doesn't play a role here. At
some point during boot all unused clocks are disabled and up to then no
driver ensured your uart clock to be used. And maybe you had a real
hangup because writing to an UART with its clock off might have "funny"
effects.

> * hacking out the clock disable lead further to the point where rootfs
>   is mounted and init started

There is no need for a hack, just pass "clk_ignore_unused" on the kernel
command line.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

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