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

[Rob Clark]

On Sun, Sep 17, 2017 at 8:28 AM, Rob Clark <robdclark at gmail.com> wrote:
> 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??

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