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

[Otavio Salvador]

On Wed, Oct 11, 2017 at 4:47 PM, Robert P. J. Day <rpjday at crashcourse.ca> wrote:
> 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.

So you can try to patch the u-boot and machine files.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750