Hi Simon,
On Sat, 30 Mar 2019 at 15:40, Simon Goldschmidt
<simon.k.r.goldschm...@gmail.com> wrote:
>
>
>
> Simon Glass <s...@chromium.org> schrieb am Sa., 30. März 2019, 22:18:
>>
>> Hi Simon,
>>
>> On Sat, 30 Mar 2019 at 14:50, Simon Goldschmidt
>> <simon.k.r.goldschm...@gmail.com> wrote:
>> >
>> >
>> >
>> > Simon Goldschmidt <simon.k.r.goldschm...@gmail.com> schrieb am Sa., 30.
>> > März 2019, 21:18:
>> >>
>> >>
>> >>
>> >> Simon Glass <s...@chromium.org> schrieb am Sa., 30. März 2019, 21:06:
>> >>>
>> >>> Hi Simon,
>> >>>
>> >>> On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt
>> >>> <simon.k.r.goldschm...@gmail.com> wrote:
>> >>> >
>> >>> > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it
>> >>> > clears
>> >>> > the bss before calling board_init_f() instead of clearing it before
>> >>> > calling
>> >>> > board_init_r().
>> >>> >
>> >>> > This also ensures that variables placed in BSS can be shared between
>> >>> > board_init_f() and board_init_r() in SPL.
>> >>> >
>> >>> > Such global variables are used, for example, when loading things from
>> >>> > FAT
>> >>> > before SDRAM is available: the full heap required for FAT uses global
>> >>> > variables and clearing BSS after board_init_f() would reset the heap
>> >>> > state.
>> >>> > An example for such a usage is socfpa_arria10 where an FPGA
>> >>> > configuration
>> >>> > is required before SDRAM can be used.
>> >>> >
>> >>> > Make the new option depend on ARM for now until more implementations
>> >>> > follow.
>> >>> >
>> >>>
>> >>> I still have objections to this series and I think we should discuss
>> >>> other ways of solving this problem.
>> >>>
>> >>> Does socfgpa have SRAM that could be used before SDRAM is available?
>> >>> If so, can we not use that for the configuration? What various are
>> >>> actually in BSS that are needed before board_init_r() is called? Can
>> >>> they not be in a struct created from malloc()?
>> >>
>> >>
>> >> The problem is the board needs to load an FPGA configuration from FAT
>> >> before SDRAM is available. Yes, this is loaded into SRAM of course, but
>> >> the whole code until that is done uses so many malloc/free iterations
>> >> that The simple mall of implementation would require too much memory.
>> >>
>> >> And it's the full malloc state variables only that use BSS, not the FAT
>> >> code.
>> >>
>> >> One way out could be to move the full mall of state variables into 'gd'...
>> >
>> >
>> > Maybe I should point out again that the whole purpose of this series is to
>> > have an SPL that uses full malloc right from the start. This is currently
>> > not possible as full malloc needs BSS.
>>
>> Right, and our assumption/design is that full malloc() requires SRAM.
>>
>> Here we have an architecture that requires FAT just to init its SDRAM.
>> FAT requires malloc() and free() and there is not enough SRAM to skip
>> the free() calls. So we have to use full malloc() and that uses BSS.
>> But BSS is not available before board_init_r(). But we need to init
>> SDRAM before board_init_r().
>>
>> Firstly I'd point out that someone should speak to the chip designers.
>> Did anyone try to boot U-Boot on the SoC model?
>
>
> Well, it's a U-Boot thing to load it from FAT. It could probably be loaded
> from RAW mmc without problems, so I don't know if it's a chip designers
> issue. I think it's an issue that we need to fix in U-Boot: we have a good
> full malloc implementation but it's not usable in all cases were it should be.
OK then why use FAT? I assumed it was a boot-ROM requirement. How does
the boot ROM load SPL?
>
>>
>> I think it is possible to change dlmalloc to put its variables in a
>> struct. Then I suppose the struct pointer could be kept in gd. That
>> would be one solution. Then full malloc() could be inited in
>> spl_common_init() perhaps.
>
>
> That might be worth a try.
Yes shouldn't be too painful. I suspect it would be neutral on code size, too.
>
>>
>> Another option might be to update the FAT code to use
>> ALLOC_CACHE_ALIGN_BUFFER() instead of malloc(), as it already does in
>> places, and perhaps to disable all caching for this case. Then it
>> might work with simple malloc().
>
>
> Hmm, then the next platform will have problems because allocating via malloc
> would be preferable. If really rather fix using dlmalloc instead.
Hmm but there is no obvious analysis behind your preference. If we
have code like this:
do_something_with_fat()
{
void *buf = malloc(...);
...
free(buf);
}
it seems to me we should convert it to use the stack instead, unless
there is some recursion problem, etc. Otherwise we are just causing
pointless churn on malloc().
>
>>
>> Another option would be to put the FPGA image in a known position on
>> the media, outside the FAT partition. The position could perhaps be
>> written into a FAT file, and reading just that file in SPL might not
>> involve many free() operations.
>
>
> Sounds like a workaround, too. I think the U-Boot infrastructure should work
> for the boards, not placing restrictions on them.
I'll await your answer to my first question in this email before
passing judgement.
>
>>
>> I hesitate to suggest enhancing simple malloc() to support a free
>> list. That would increase the code size and I'm not sure it would be
>> better than using full malloc().
>
>
> Yes, I think that might result in making a second dlmalloc.... :-)
>
> Thanks for your thoughts and input!
Overall I feel that the current trade-offs and phases of boot are
reasonable. We should be suspicious of attempts to make them more
complex.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
