On Wed, Oct 11, 2017 at 4:47 PM, Robert P. J. Day <[email protected]> wrote: > On Wed, 11 Oct 2017, Otavio Salvador wrote: > >> Hello Robert, >> >> On Wed, Oct 11, 2017 at 7:57 AM, Robert P. J. Day <[email protected]> >> 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 -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
