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?? BR, -R _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
