On Tue, Mar 05, 2019 at 03:01:35PM +0500, Embedded Engineer wrote: > On Mon, Mar 4, 2019 at 7:25 PM Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > Perhaps also try to run a recent linux-next just to exclude any issues > > that may have been part of the 4.8.0-rc7 that you tested. > > Thierry I have disabled cache as per Andrew's suggestion by calling > dcache_disable() and icache_disable() just before kernel_entry() in > u-boot source. I have also build the linux-next kernel and tested by > booting from microSD card but it is not going upto login console and > hangs midway. Please have a look at kernel logs in below link: > > https://pastebin.com/ByuaLxTt Okay, looks fairly normal so far, except for the corrupted data. That's definitely not normal and I think we need to fix that first, otherwise we can't really be certain what's going on later. One thing besides memory timings in BCT that comes to mind that could be causing memory corruption are power supplies. Are you sure they're all correctly configured and enabled as required? It might be worth looking at all of them and marking them "regulator-always-on" just to make sure an essential one isn't disabled inadvertently during boot. The corruption happens long before unused regulators are disabled, so that doesn't sound like it would be very relevant here. But perhaps best to check it anyway, just in case. > P.S: If I replace zImage and DTB of downstream same microSD card, it > successfully takes me to login console (although it has hanging issues > as I mentioned in previous posts) Does the upstream kernel and DTB boot reliably, even if it doesn't get you to a login prompt? Or does it also behave erratically like the downstream kernel and DTB that you have? Thierry
Attachment:
signature.asc
Description: PGP signature
