On Tue, Oct 3, 2017 at 12:32 PM, Rob Clark <robdcl...@gmail.com> wrote:
> On Tue, Oct 3, 2017 at 12:04 PM, Fabio Estevam <feste...@gmail.com> wrote:
>> On Tue, Oct 3, 2017 at 12:30 PM, Rob Clark <robdcl...@gmail.com> wrote:
>>> On some devices, this does not appear to be a valid assumption.  So
>>> figure out the number of blocks we actually need to read.
>>>
>>> Signed-off-by: Rob Clark <robdcl...@gmail.com>
>>
>> This version does not solve the mx6 spl boot issue.
>
> Hmm, the change you had tested earlier is not correct, since it would
> allocate potentially less than blksz (and then read blksz bytes into
> it)..
>
> *maybe* the memory allocation is failing?  I'm not sure, I'm kind of
> just guessing here.  It would be nice to know what blksz is on your
> device.  (That said, before the original patch, the allocation was for
> blksz bytes too, so if this were the issue I think it would have been
> failing before.)
>

btw, I'm still hoping someone can get me some logs so I can see what
blksz is, etc, on these boards..

in the worst case I guess we can change part_test_dos() to:

#ifdef SPL
  .. old code ..
#else
  .. new code ..
#endif

a bit ugly, but at least that wouldn't break efi_bootmgr plus boards
with multiple "disks".. having the proper partition signatures I guess
doesn't matter in the SPL stage..

BR,
-R
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to