On Sun, Sep 17, 2017 at 8:28 AM, Rob Clark <robdcl...@gmail.com> wrote: > On Sun, Sep 17, 2017 at 7:08 AM, Adam Ford <aford...@gmail.com> wrote: >> On Sat, Sep 16, 2017 at 3:42 PM, Rob Clark <robdcl...@gmail.com> wrote: >>> On Sat, Sep 16, 2017 at 4:32 PM, Adam Ford <aford...@gmail.com> wrote: >>>> On Fri, Sep 15, 2017 at 9:32 PM, Tom Rini <tr...@konsulko.com> wrote: >>>>> >>>>> On Sat, Sep 09, 2017 at 01:15:54PM -0400, Rob Clark wrote: >>>>> >>>>> > And drop a whole lot of ugly code! >>>>> > >>>>> > Signed-off-by: Rob Clark <robdcl...@gmail.com> >>>>> > Reviewed-by: Łukasz Majewski <lu...@denx.de> >>>>> > Reviewed-by: Simon Glass <s...@chromium.org> >>>>> >>>>> Applied to u-boot/master, thanks! >>>>> >>>> >>>> According to git bisect, this patch seems to break the booting of >>>> am3517_evm >>>> >>>> It just displays: >>>> >>>> U-Boot SPL 2017.09-00135-g8eafae2 (Sep 16 2017 - 15:23:16) >>>> Trying to boot from MMC1 >>>> >>>> Then hangs. >>>> >>>> It does, however the same patch boots just fine on >>>> omap3_logic_defconfig which is an OMAP3630/DM3730 board. >>>> >>>> da850evm_defconfig (OMAP-L138) is also booting just fine. >>>> >>>> I'm going to investigate it further to see why just 1/3 boards seems >>>> impacted. >>>> >>> >>> Tom reported a similar fail.. although I am failing to reproduce it in >>> sandbox w/ a copy of his partition, so maybe it is somehow hw >>> specific? If you could, debug logs w/ >>> https://hastebin.com/raw/fijazebiso applied in before/after case would >>> be useful.. maybe I could spot something from that? >>> >> >> Adding the debug to master made no difference. No debug messages appeared. >> Interestingly enough, some junk appeard, and the name of U-Boot name >> wasn't correctly displayed: >> >> **Sș017.09-00178-g08cebee-dirty (Sep 17 2017 - 06:01:07) >> Trying to boot from MMC1 >> >> (hang) >> >> Could there a be some memory overflow somewhere? >> >> Adding the debug to the last working commit, yielded the following: >> >> U-Boot SPL 2017.09-00134-ge71f88d-dirty (Sep 17 2017 - 06:03:28) >> Trying to boot from MMC1 >> reading u-boot.img >> VFAT Support enabled >> FAT16, fat_sect: 1, fatlength: 200 >> Rootdir begins at cluster: 536870910, sector: 401, offset: 32200 >> Data begins at: 417 >> Sector size: 512, cluster size: 8 >> FAT read(sect=401, cnt:2), clust_size=8, DIRENTSPERBLOCK=d >> RootMismatch: |mlo|| >> Rootvfatname: |u-boot.img| >> RootName: u-boot.img, start: 0x98, size: 0x83708 >> Filesize: u bytes >> u bytes >> gc - clustnum: 152, startsect: 1633 >> Size: 538376, got: u >> reading u-boot.img >> VFAT Support enabled >> FAT16, fat_sect: 1, fatlength: 200 >> Rootdir begins at cluster: 536870910, sector: 401, offset: 32200 >> Data begins at: 417 >> Sector size: 512, cluster size: 8 >> FAT read(sect=401, cnt:2), clust_size=8, DIRENTSPERBLOCK=d >> RootMismatch: |mlo|| >> Rootvfatname: |u-boot.img| >> RootName: u-boot.img, start: 0x98, size: 0x83708 >> Filesize: u bytes >> u bytes >> >> I truncated it, because after that, it seems to just be showing >> entries and offsets over and over again. >> > > Thanks, this first part is what I was looking for. > > Not sure why DEBUG would make it hang on master. I don't know much > about spl, but is there a way you can get it to just do 'ls mmc 1:1' > instead of loading u-boot.img? ls should give me the same information > about the partition, without so many repeating entries/offsets. > Alternately, is it possible to boot w/ old spl image but new > u-boot.img to debug this once we get into main u-boot image??
I suppose another benefit if it is possible to use old spl and new u-boot.img is the presumably u-boot.img isn't using TINY_PRINTF so the debug prints about the partition parameters would be more complete.. BR, -R _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
