[meta-freescale] minimal DT changes to start booting kernel on D/L board on ttymxc3?

[Robert P. J. Day]

On Wed, 11 Oct 2017, Otavio Salvador wrote:

> Hello Robert,
>
> On Wed, Oct 11, 2017 at 7:57 AM, Robert P. J. Day <rpjday at crashcourse.ca> wrote:
> >
> >   this *should* be a simple question but i just want to make sure i'm
> > not overlooking anything, costing myself hours of aggravation.
> >
> >   for a freescale MCIMX6Q-SDB reference board in front of me, i've
> > trivially built a "core-image-minimal" using MACHINE=imx6qdlsabresd,
> > dd'ed the wic image to SD card, and booted perfectly successfully. so
> > i now have a kernel that should cover a wide range of i.MX6 targets,
> > differing only in the .dtb file passed to the kernel at boot time.
> >
> >   the only detail of interest is that this board clearly has its
> > console on UART1, as /proc/cmdline contains:
> >
> >   # cat /proc/cmdline
> >   console=ttymxc0,115200 root=PARTUUID=0b867308-02 rootwait rw
> >   #
> >
> > where, as i read it, for i.MX6, the association is:
> >
> >   UART1 -> ttymxc0
> >   UART2 -> ttymxc1
> >   UART3 -> ttymxc2
> >   UART4 -> ttymxc3
> >
> > correct? and herein lies the issue.
> >
> >   i have recently been handed a proprietary i.MX6-based board, built
> > around dual-lite but, as i've been told, trying to hang onto as much
> > of the MCIMX6Q-SDB design as possible to minimize the churn in the
> > device tree files. still, there's a ton of stuff that's been added to
> > the proprietary board, so certainly the DT files are going to be
> > different and will need major tweaking.
> >
> >   what i want to do is start with a generic YP build as above, and
> > just boot using (i'm assuming) "imx6dl-sabresd.dtb" that was built as
> > above; in other words, i already have everything i need from the
> > current build, i just need to stop in u-boot and switch the .dtb file
> > being passed to the kernel.
> >
> >   i'm prepared for all sorts of warnings and errors given that the DTB
> > file won't match the actual board, but the fundamental issue is that
> > the console port on this proprietary board was (apparently) moved from
> > UART1 to UART4, since (for this proprietary board and a working but
> > fairly old bootable image) u-boot sets "console=ttymxc3,115200". so my
> > plan is to simply define a new layer (meta-rday or whatever), which
> > defines a new MACHINE, and tweaks the meta-freescale kernel with a
> > single patch that defines UART4 as the console rather than UART1.
> >
> >   does that make sense? as i said, the rest of the DT files will
> > certainly be out of whack and i'll start adjusting them as errors come
> > up and i add support for new subsystems, but just to start getting
> > kernel output, is it sufficient to just move the DT console definition
> > from UART1 to UART4? is there anything else that would need to change?
> >
> >   oh, and while i'm about to dig into the device trees to see how to
> > do that, if anyone wants to just supply the kernel patch i would need
> > to apply, that would be just ducky. :-)
> >
> >   does all this make sense?
>
> Not much ;-)
>
> Generally we do this kind of development using:
>
> - a toolchain and building the U-Boot and Linux kernel outside the OE
> build system as it is way faster, easier and more productive
> - when those are good, we integrate them in a customer layer
> - make a custom machine for the customer on this layer
> - enjoy ;-)
>
> This way you have more control and is not affected by changes on the
> other layers. It is safer and also keeps clear what are the specific
> components of your board.

  i understand that, and in a perfect world, that is how i would work,
too but, as they say, that is not the hand i have been dealt. so as
what is basically a proof-of-concept that i can build a YP image that
runs on this board, the only thing i want to change is to move the
console port from UART1 (/dev/ttymxc0) to UART4 (/dev/ttymxc3).

  i totally appreciate that lots of stuff won't work until i
methodically start fixing the device tree files but, at the moment, i
want to do nothing more than start booting a kernel and be able to see
the output, even if it crashes and burns partway through the boot, at
which point i'll start fixing stuff one thing at a time.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================