* [ptxdist] boot problem w/ barebox
@ 2017-09-09 9:01 Enrico Weigelt, metux IT consult
2017-09-11 7:16 ` Uwe Kleine-König
0 siblings, 1 reply; 5+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2017-09-09 9:01 UTC (permalink / raw)
To: ptxdist, barebox, d.schultz, c.hemp
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
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ptxdist] boot problem w/ barebox
2017-09-09 9:01 [ptxdist] boot problem w/ barebox Enrico Weigelt, metux IT consult
@ 2017-09-11 7:16 ` Uwe Kleine-König
2017-09-11 18:47 ` Enrico Weigelt, metux IT consult
0 siblings, 1 reply; 5+ messages in thread
From: Uwe Kleine-König @ 2017-09-11 7:16 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult; +Cc: d.schultz, barebox, ptxdist, c.hemp
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/ |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ptxdist] boot problem w/ barebox
2017-09-11 7:16 ` Uwe Kleine-König
@ 2017-09-11 18:47 ` Enrico Weigelt, metux IT consult
2017-09-12 8:32 ` Uwe Kleine-König
0 siblings, 1 reply; 5+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2017-09-11 18:47 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: d.schultz, barebox, ptxdist, c.hemp
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
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ptxdist] boot problem w/ barebox
2017-09-11 18:47 ` Enrico Weigelt, metux IT consult
@ 2017-09-12 8:32 ` Uwe Kleine-König
2017-09-13 10:56 ` Enrico Weigelt, metux IT consult
0 siblings, 1 reply; 5+ messages in thread
From: Uwe Kleine-König @ 2017-09-12 8:32 UTC (permalink / raw)
To: ptxdist; +Cc: barebox, d.schultz, c.hemp
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/ |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ptxdist] boot problem w/ barebox
2017-09-12 8:32 ` Uwe Kleine-König
@ 2017-09-13 10:56 ` Enrico Weigelt, metux IT consult
0 siblings, 0 replies; 5+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2017-09-13 10:56 UTC (permalink / raw)
To: ptxdist
On 12.09.2017 10:32, Uwe Kleine-König wrote:
Hi,
> 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.
Perhaps we could add some notes in the description, so people
won't get confused anymore.
> 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.
The clock wasn't the only problem. I've hacked out that, so console
(printk) continued to work, but later on /dev/console couldn't be
opened (ENODEV). And this was due to missing tty device. See printk.c:
console_device().
>> * 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.
Wasn't aware of that yet. Thx.
--mtx
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-09-13 10:56 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-09 9:01 [ptxdist] boot problem w/ barebox Enrico Weigelt, metux IT consult
2017-09-11 7:16 ` Uwe Kleine-König
2017-09-11 18:47 ` Enrico Weigelt, metux IT consult
2017-09-12 8:32 ` Uwe Kleine-König
2017-09-13 10:56 ` Enrico Weigelt, metux IT consult
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox