[U-Boot] [PATCH v4 2/3] spl: Remove overwrite of relocated malloc limit
Tom Rini
trini at konsulko.com
Thu Feb 2 00:08:53 UTC 2017
On Wed, Feb 01, 2017 at 11:48:11PM +0000, André Przywara wrote:
> On 27/01/17 16:39, Andrew F. Davis wrote:
>
> Hi,
>
> > spl_init on some boards is called after stack and heap relocation, on
> > some platforms spl_relocate_stack_gd is called to handle setting the
> > limit to its value CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN when simple
> > SPL malloc is enabled during relocation. spl_init should then not
> > re-assign the old pre-relocation limit when this is defined.
>
> I am sorry to say this, but this very patch breaks SPL boot on sunxi
> boards (tested on the Pine64, the Orangepi PC2 (with a similar ARMv8
> SoC) and the OrangePi Zero (ARMv7 Allwinner H3 SoC).
>
> U-Boot SPL 2017.03-rc1-00022-gf77309d (Feb 01 2017 - 23:27:19)
> DRAM: 1024 MiB
> Trying to boot from MMC1
> MMC Device 0 not found
> spl: could not find mmc device. error: -19
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> sunxi boards both use the default CONFIG_SYS_MALLOC_F_LEN=0x400 and
> CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x100000.
>
> At the moment the code there is beyond me, so I can't really say how
> this breaks, but it clearly does: reverting this patch makes U-Boot
> happy again.
>
> Any ideas?
Arg. I'll try and poke at this but my A20-OLinuXino-Lime2 is (FEL at
least) booting so I hadn't seen this. Can you confirm that pine64, or
these other boards, also fail when FEL booting? I ask since if they
pass that way I need to pencil in some time to figure out another way to
test that HW, or at least make additional testing of that hardware
easier. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170201/3b566edd/attachment.sig>
More information about the U-Boot
mailing list