On Mon, Feb 08, 2016 at 02:00:00AM +0000, Paul Walmsley wrote: > On Sat, 6 Feb 2016, Troy Benjegerdes wrote: > > > I'm trying to track down and fix some breakage on the 3517/3505 SOCs. > > > > It seems like not a lot of testing has gone into this port since say 3.18 > > or so, and what I'm finding now is that if I try to use either the new > > u-boot FIT image format, or load a separate uImage and dtb with bootm, > > I get crashes in loading and/or processing the device tree. > > ... > > > And if I move up to the latest version, it seems to die in > > unflatten_device_tree because it looks like the memory that u-boot put > > the device tree in is unmapped. > > > > Any ideas on where to start with this? > > At least as far as the Compulab CM-T3517 board goes, it boots on the > latest kernels with a combined uImage+DTB (grep for "cmt3517"): > > http://www.pwsan.com/omap/testlogs/test_v4.5-rc2/20160131225233/README.txt > > Console log can be found here: > > http://www.pwsan.com/omap/testlogs/test_v4.5-rc2/20160131225233/boot/cmt3517/ > > Please be advised that, if you are thinking about using these chips for a > product, I don't think there's anyone at TI spending time on mainline > Linux support for these AM3505/3517 chips. I kinda figured it was rather unsupported. (this is for a 'legacy' product that needs updates) I actually found that 'nohlt' was rather important and that the default meta-ti yocto builds don't include it, and this ends up hanging while waiting for the MMC to show up. Any chance you've tested video/hdmi/lcd output on the CMT3517 board? Also, do you happen to have the code/script that produced the output at http://www.pwsan.com/omap/testlogs/test_v4.5-rc2/20160131225233/dtcat/omap2plus_defconfig/dtcat_20160131225233_am3517-evm_log.txt I would like to confirm I can produce the same thing, and I'm not quite sure what to look for in the output that it has successfully found a device tree vs just defaulting to something. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
