[U-Boot] [U-Boot, v3, 3/9] fat/fs: convert to directory iterators

[Rob Clark]

On Sun, Sep 17, 2017 at 7:08 AM, Adam Ford <aford173 at gmail.com> wrote:
> On Sat, Sep 16, 2017 at 3:42 PM, Rob Clark <robdclark at gmail.com> wrote:
>> On Sat, Sep 16, 2017 at 4:32 PM, Adam Ford <aford173 at gmail.com> wrote:
>>> On Fri, Sep 15, 2017 at 9:32 PM, Tom Rini <trini at 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 <robdclark at gmail.com>
>>>> > Reviewed-by: Łukasz Majewski <lukma at denx.de>
>>>> > Reviewed-by: Simon Glass <sjg at 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