[U-Boot] Simple Malloc Breaks omap3_logic

[Tom Rini <trini@konsulko.com>]

On Tue, Mar 07, 2017 at 09:31:02PM -0600, Adam Ford wrote:
> On Tue, Mar 7, 2017 at 7:04 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Tue, Mar 07, 2017 at 04:23:08PM -0600, Adam Ford wrote:
> >> On Tue, Mar 7, 2017 at 4:05 PM, Tom Rini <trini@konsulko.com> wrote:
> >> > On Tue, Mar 07, 2017 at 04:02:22PM -0600, Adam Ford wrote:
> >> >> On Wed, Feb 15, 2017 at 7:23 AM, Adam Ford <aford173@gmail.com> wrote:
> >> >> > On Tue, Feb 14, 2017 at 4:07 PM, Tom Rini <trini@konsulko.com> wrote:
> >> >> >> On Tue, Feb 14, 2017 at 03:56:43PM -0600, Adam Ford wrote:
> >> >> >>> On Feb 14, 2017 3:10 PM, "Tom Rini" <trini@konsulko.com> wrote:
> >> >> >>>
> >> >> >>> On Tue, Feb 14, 2017 at 03:03:44PM -0600, Adam Ford wrote:
> >> >> >>>
> >> >> >>> > Tom,
> >> >> >>> >
> >> >> >>> > I noticed there was an update to the omap3_logic_defconfig to use Simple
> >> >> >>> Malloc
> >> >> >>> >
> >> >> >>> > http://git.denx.de/?p=u-boot.git;a=commit;h=0959649dc6d9e6a371617abd3b0363
> >> >> >>> 0c5d4d5a72
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > I didn't see anything in my inbox indicating the patch, I only noticed
> >> >> >>> > it because I pulled the latest from the trunk.  Unfortunately, this
> >> >> >>> > patch breaks the board.
> >> >> >>> >
> >> >> >>> > (ie. MLO doesn't load U-Boot)
> >> >> >>> >
> >> >> >>> > See Log:
> >> >> >>> >
> >> >> >>> > U-Boot SPL 2017.03-rc2-00008-g2ebb842-dirty (Feb 14 2017 - 14:54:59)
> >> >> >>> > Trying to boot from MMC1
> >> >> >>> > reading args
> >> >> >>> > spl_load_image_fat_os: error reading image args, err - -1
> >> >> >>> > reading u-boot.img
> >> >> >>> > reading u-boot.img
> >> >> >>> >
> >> >> >>> > (then it just hangs)
> >> >> >>> >
> >> >> >>> > Removing this line from the defconfig returns the board to a functional
> >> >> >>> state.
> >> >> >>> >
> >> >> >>> > Is there an alternative that we can explore to give you what you need?
> >> >> >>> >
> >> >> >>> > I am able to build with gcc version 5.4.0 , but I can help you do some
> >> >> >>> > testing if you need.
> >> >> >>>
> >> >> >>> Oh, sorry, I thought I had made sure to copy all of the required logic
> >> >> >>> to have simple malloc work.  I think it's highly likely I forgot to make
> >> >> >>> sure that CONFIG_SYS_MALLOC_F_LEN is also set and that's why it all went
> >> >> >>> south.  Sorry again!
> >> >> >>>
> >> >> >>>
> >> >> >>> That's OK, I just hope I can be included in changes so I can test them. I
> >> >> >>> do appreciate the help in making the code and user experience better.
> >> >> >>>
> >> >> >>> Can you send me an updated patch so I can test your change?
> >> >> >>
> >> >> >> Try this please:
> >> >> >> diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
> >> >> >> index fe762c0a6b04..9d1304f08e49 100644
> >> >> >> --- a/configs/omap3_logic_defconfig
> >> >> >> +++ b/configs/omap3_logic_defconfig
> >> >> >> @@ -1,5 +1,6 @@
> >> >> >>  CONFIG_ARM=y
> >> >> >>  CONFIG_OMAP34XX=y
> >> >> >> +CONFIG_SYS_MALLOC_F_LEN=0x2000
> >> >> >>  CONFIG_TARGET_OMAP3_LOGIC=y
> >> >> >>  CONFIG_SYS_EXTRA_OPTIONS="NAND"
> >> >> >>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
> >> >> >>
> >> >> >
> >> >>
> >> >> Tom,
> >> >>
> >> >> I am not sure what you're trying to fix here, but I looked at other
> >> >> OMAP3 and AM3X boards, but they don't have either the config options
> >> >> you are proposing.  Even with both sets of config options, the board
> >> >> fails to boot.
> >> >>
> >> >> I did look at the some of the other TI boards, and they have some SPL
> >> >> related memory allocation settings.
> >> >>
> >> >> If I perform the following, I can get my board to boot, but since I am
> >> >> not sure what you're trying to fix, I am not sure if it helps your
> >> >> issue.
> >> >>
> >> >>
> >> >> --- a/configs/omap3_logic_defconfig
> >> >> +++ b/configs/omap3_logic_defconfig
> >> >> @@ -5,9 +5,10 @@ CONFIG_SYS_EXTRA_OPTIONS="NAND"
> >> >>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
> >> >>  CONFIG_VERSION_VARIABLE=y
> >> >>  CONFIG_SPL=y
> >> >> -CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> >> >>  CONFIG_SPL_MTD_SUPPORT=y
> >> >>  CONFIG_SPL_OS_BOOT=y
> >> >> +CONFIG_SPL_STACK_R_ADDR=0x82000000
> >> >> +CONFIG_SPL_STACK_R=y
> >> >>  CONFIG_HUSH_PARSER=y
> >> >>  CONFIG_SYS_PROMPT="OMAP Logic # "
> >> >>  CONFIG_CMD_BOOTZ=y
> >> >>
> >> >> Do those options make any sense?  I'd like to get this resolved before
> >> >> the 2017.03 release comes as of right now, the stuff in the trunk does
> >> >> not boot my board.
> >> >
> >> > Please submit this as a proper patch and I'll make sure it still fits in
> >> > size wise everywhere, thanks!
> >> >
> >>
> >> No problem - done.  :-)
> >>
> >> Can you tell me what you're seeing so I can try to replicate it on my
> >> end?  I assume you're seeing stuff overflow memory with a certain
> >> compiler and/or library version.
> >
> > Here's one:
> > https://travis-ci.org/trini/u-boot/jobs/208767272
> 
> Thanks for sending me the build failures.  I was able to get the
> failure to occur with GCC 4.8, and confirm that the fix booted when
> using both 4.8 and 6.2 versions of GCC.  I had to implement both your
> fix as well as the CONFIG_SPL_STACK_R_ADDR in order to get everything
> to work.  I forgot to mark it as V2 when I submitted the patch.  If
> you want me to resend it with V2 added to the prefix, I can do that.

Sorry, to be clear, the above failure is with your current patch.

-- 
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/20170308/577e5d5b/attachment.sig>