On Sun, Dec 8, 2019 at 6:50 AM Adam Ford <aford...@gmail.com> wrote: > > On Sat, Dec 7, 2019 at 12:25 PM Tom Rini <tr...@konsulko.com> wrote: > > > > On Sat, Dec 07, 2019 at 08:42:32AM -0600, Adam Ford wrote: > > > > > I am trying to run the latest master > > > > > > 4b19b89ca4a866b7baa642533e6dbd67cd832d27 > > > with the clock patches applied for 8mm, but I am getting a boot > > > failure when I follow the instructions in the README, which are also a > > > bit wrong. (the firmware versions don't match, and the ./firmware > > > command is missing the trailing '.bin', but it's trivial.) > > > > > > What comes out of the kit with DEBUG enabled is: > > > > > > (bunch of stuff deleted) > > > > > > [PMU Major message = 0x000000fe] > > > [PMU Major message = 0x00000007] > > > Training PASS > > > DDRINFO: ddrphy config done > > > DDRINFO:ddrphy calibration done > > > DDRINFO: ddrmix config done > > > >>SPL: board_init_r() > > > using memory lx-lx for malloc() > > > spl_init > > > Normal Boot > > > Trying to boot from MMC1 > > > common/dlmalloc.c:792: do_check_inuse_chunk: Assertion `inuse(p)' failed. > > > resetting ... > > > > > > The above sequence repeats again and again. I didn't put all the junk > > > into the log because it looked like everything seemed OK until the > > > dlmalloc failure at the end. If someone has any suggestions, I'd like > > > to try the 8mm-evk with a modern U-Boot. > > > > I think (per the thread about fixing one of the colibri platforms) this > > also needs a CONFIG_FSL_ESDHC -> CONFIG_FSL_ESDHC_IMX fix in the board > > file. > > I am not seeing a reference to either CONFIG_FSL_ESDHC or > CONFIG_FSL_ESDHC_IMX in the imx8mm_evk board files, and it appears as > if the device tree and DM_SPL stuff is managing the drivers. The > defconfig file is enabling CONFIG_FSL_ESDHC_IMX. > > It seems like a memory issue based on: > common/dlmalloc.c:792: do_check_inuse_chunk: Assertion `inuse(p)' failed. >
I switched the imx8mm-evk to use CONFIG_SPL_SYS_MALLOC_SIMPLE=y, and it appears to fix one error, but I get a different one in its place. For booting from microSD, the proper USDHC controller is located at 30b50000, but it's unclear to me which one it's trying to use: spl: mmc boot mode: raw blk_find_device: if_type=6, devnum=1: m...@30b50000.blk, 6, 0 blk_find_device: if_type=6, devnum=1: m...@30b60000.blk, 6, 1 hdr read sector 300, count=1 mkimage signature not found - ih_magic = 0 blk_find_device: if_type=6, devnum=1: m...@30b50000.blk, 6, 0 blk_find_device: if_type=6, devnum=1: m...@30b60000.blk, 6, 1 read 400 sectors to 40200000 Jumping to U-Boot loaded - jumping to U-Boot... image entry point: 0x40200000 It looks like it might be trying both or falling back to a different MMC device. The fact that it gets "mkimage signature not found - ih_magic = 0" indicates to me that maybe it's either reading from the wrong sdhc controller or the wrong address. I am still learning how the 'make flash.bin' stuff works, and/or where the u-boot raw file gets placed since it appears to be all one bundled image burned to SDHC. I think I'm making progress, but I think the original statement about memory an memory issue is interesting to me. I am not sure why simple malloc would work, but the standard malloc would fail. adam > adam > > > > > > > -- > > Tom
