* [U-Boot] U-Boot memory allocation problems with ast2500
@ 2016-09-09 21:53 Maxim Sloyko
2016-09-09 23:18 ` Simon Glass
0 siblings, 1 reply; 5+ messages in thread
From: Maxim Sloyko @ 2016-09-09 21:53 UTC (permalink / raw)
To: u-boot
Hi all,
First, disclaimer: this is the first time I'm doing something with U-Boot
or the part (ast2500), so any claim I make below can be false or just plain
nonsense.
I'm working on expanding support of Aspeed ast2500 part in U-Boot.
I ran into some problems, when I tried to use Linux Kernel device tree for
this part in U-Boot. Looking at diagnostic messages (
http://pastebin.ca/3713876) I figured out that the problem is that U-Boot
continues to use malloc_simple, even after it has been relocated to RAM. As
a result, it fails to allocate 130k needed for environment, because it is
larger than the configured size of a memory chunk for simple malloc.
I suspect that this has something to do with memory configuration, do you
know what I may be missing? Also, it looks like lowlevel_init has been
called twice, i.e. again after relocation -- is this expected? This might
be what is causing the problem, because lowlevel_init does a lot of RAM
related configuration, but I don't know what to do about it.
There is some very basic support for this part in U-Boot, provided by
manufacturer, but it is basically a single platform.S assembly file that
does everything, like RAM configuration and some other peripherals support
in lowlevel_init procedure.
So, if I want to add proper support for this part, i.e. with device tree
and all, is there a way to make this a gradual process? I mean, is it
possible to leave existing RAM initialization procedure in lowlevel_init
and just add new drivers for something I'm interested in or is this all or
nothing kind of thing?
Thank you.
--
*M*axim *S*loyko
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] U-Boot memory allocation problems with ast2500
2016-09-09 21:53 [U-Boot] U-Boot memory allocation problems with ast2500 Maxim Sloyko
@ 2016-09-09 23:18 ` Simon Glass
2016-09-12 16:29 ` Maxim Sloyko
2016-09-14 15:50 ` Maxim Sloyko
0 siblings, 2 replies; 5+ messages in thread
From: Simon Glass @ 2016-09-09 23:18 UTC (permalink / raw)
To: u-boot
Hi Maxim,
On 9 September 2016 at 15:53, Maxim Sloyko <maxims@google.com> wrote:
>
> Hi all,
>
> First, disclaimer: this is the first time I'm doing something with U-Boot or the part (ast2500), so any claim I make below can be false or just plain nonsense.
Welcome!
>
> I'm working on expanding support of Aspeed ast2500 part in U-Boot.
>
> I ran into some problems, when I tried to use Linux Kernel device tree for this part in U-Boot. Looking at diagnostic messages (http://pastebin.ca/3713876) I figured out that the problem is that U-Boot continues to use malloc_simple, even after it has been relocated to RAM. As a result, it fails to allocate 130k needed for environment, because it is larger than the configured size of a memory chunk for simple malloc.
The test for this is in dlmalloc.c - the GD_FLG_FULL_MALLOC_INIT flag.
The flag is set in initr_reloc() after relocation.
I wonder if your global_data (the 'gd' pointer) is not set up
correctly, so it cannot write to the flag.
What version of U-Boot is it? Is the tree available somewhere?
>
> I suspect that this has something to do with memory configuration, do you know what I may be missing? Also, it looks like lowlevel_init has been called twice, i.e. again after relocation -- is this expected? This might be what is causing the problem, because lowlevel_init does a lot of RAM related configuration, but I don't know what to do about it.
I would expect lowlevel_init() to be called only once (or perhaps once
in SPL and once in U-Boot proper).
>
> There is some very basic support for this part in U-Boot, provided by manufacturer, but it is basically a single platform.S assembly file that does everything, like RAM configuration and some other peripherals support in lowlevel_init procedure.
>
> So, if I want to add proper support for this part, i.e. with device tree and all, is there a way to make this a gradual process? I mean, is it possible to leave existing RAM initialization procedure in lowlevel_init and just add new drivers for something I'm interested in or is this all or nothing kind of thing?
Yes you can do things gradually. If you have a sane early memory
environment then you shouldn't have much trouble.
>
> Thank you.
>
> --
> Maxim Sloyko
Regards,
Simon
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] U-Boot memory allocation problems with ast2500
2016-09-09 23:18 ` Simon Glass
@ 2016-09-12 16:29 ` Maxim Sloyko
2016-09-14 15:50 ` Maxim Sloyko
1 sibling, 0 replies; 5+ messages in thread
From: Maxim Sloyko @ 2016-09-12 16:29 UTC (permalink / raw)
To: u-boot
Thanks, Simon, I'll look into GD issue and will update you on my findings :)
On Fri, Sep 9, 2016 at 4:18 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Maxim,
>
> On 9 September 2016 at 15:53, Maxim Sloyko <maxims@google.com> wrote:
> >
> > Hi all,
> >
> > First, disclaimer: this is the first time I'm doing something with
> U-Boot or the part (ast2500), so any claim I make below can be false or
> just plain nonsense.
>
> Welcome!
>
> >
> > I'm working on expanding support of Aspeed ast2500 part in U-Boot.
> >
> > I ran into some problems, when I tried to use Linux Kernel device tree
> for this part in U-Boot. Looking at diagnostic messages (
> http://pastebin.ca/3713876) I figured out that the problem is that U-Boot
> continues to use malloc_simple, even after it has been relocated to RAM. As
> a result, it fails to allocate 130k needed for environment, because it is
> larger than the configured size of a memory chunk for simple malloc.
>
> The test for this is in dlmalloc.c - the GD_FLG_FULL_MALLOC_INIT flag.
> The flag is set in initr_reloc() after relocation.
>
> I wonder if your global_data (the 'gd' pointer) is not set up
> correctly, so it cannot write to the flag.
>
> What version of U-Boot is it? Is the tree available somewhere?
>
This is OpenBMC U-Boot, you can find it here
https://github.com/openbmc/u-boot. IIUC, main U-Boot branch 2016.05 is the
last one that has been merged into it.
>
> >
> > I suspect that this has something to do with memory configuration, do
> you know what I may be missing? Also, it looks like lowlevel_init has been
> called twice, i.e. again after relocation -- is this expected? This might
> be what is causing the problem, because lowlevel_init does a lot of RAM
> related configuration, but I don't know what to do about it.
>
> I would expect lowlevel_init() to be called only once (or perhaps once
> in SPL and once in U-Boot proper).
>
> >
> > There is some very basic support for this part in U-Boot, provided by
> manufacturer, but it is basically a single platform.S assembly file that
> does everything, like RAM configuration and some other peripherals support
> in lowlevel_init procedure.
> >
> > So, if I want to add proper support for this part, i.e. with device tree
> and all, is there a way to make this a gradual process? I mean, is it
> possible to leave existing RAM initialization procedure in lowlevel_init
> and just add new drivers for something I'm interested in or is this all or
> nothing kind of thing?
>
> Yes you can do things gradually. If you have a sane early memory
> environment then you shouldn't have much trouble.
>
> >
> > Thank you.
> >
> > --
> > Maxim Sloyko
>
> Regards,
> Simon
>
--
*M*axim *S*loyko
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] U-Boot memory allocation problems with ast2500
2016-09-09 23:18 ` Simon Glass
2016-09-12 16:29 ` Maxim Sloyko
@ 2016-09-14 15:50 ` Maxim Sloyko
2016-09-15 14:29 ` Simon Glass
1 sibling, 1 reply; 5+ messages in thread
From: Maxim Sloyko @ 2016-09-14 15:50 UTC (permalink / raw)
To: u-boot
On Fri, Sep 9, 2016 at 4:18 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Maxim,
>
> On 9 September 2016 at 15:53, Maxim Sloyko <maxims@google.com> wrote:
> >
> > Hi all,
> >
> > First, disclaimer: this is the first time I'm doing something with
> U-Boot or the part (ast2500), so any claim I make below can be false or
> just plain nonsense.
>
> Welcome!
>
> >
> > I'm working on expanding support of Aspeed ast2500 part in U-Boot.
> >
> > I ran into some problems, when I tried to use Linux Kernel device tree
> for this part in U-Boot. Looking at diagnostic messages (
> http://pastebin.ca/3713876) I figured out that the problem is that U-Boot
> continues to use malloc_simple, even after it has been relocated to RAM. As
> a result, it fails to allocate 130k needed for environment, because it is
> larger than the configured size of a memory chunk for simple malloc.
>
> The test for this is in dlmalloc.c - the GD_FLG_FULL_MALLOC_INIT flag.
> The flag is set in initr_reloc() after relocation.
>
> I wonder if your global_data (the 'gd' pointer) is not set up
> correctly, so it cannot write to the flag.
>
OK, so you are right, this flag turned out to be a problem. Global data was
setup normally, but then for some reason in board_init there was a line
gd->flags = 0;
I removed it and everything works now.
Thanks for your help!
>
> What version of U-Boot is it? Is the tree available somewhere?
>
> >
> > I suspect that this has something to do with memory configuration, do
> you know what I may be missing? Also, it looks like lowlevel_init has been
> called twice, i.e. again after relocation -- is this expected? This might
> be what is causing the problem, because lowlevel_init does a lot of RAM
> related configuration, but I don't know what to do about it.
>
> I would expect lowlevel_init() to be called only once (or perhaps once
> in SPL and once in U-Boot proper).
>
> >
> > There is some very basic support for this part in U-Boot, provided by
> manufacturer, but it is basically a single platform.S assembly file that
> does everything, like RAM configuration and some other peripherals support
> in lowlevel_init procedure.
> >
> > So, if I want to add proper support for this part, i.e. with device tree
> and all, is there a way to make this a gradual process? I mean, is it
> possible to leave existing RAM initialization procedure in lowlevel_init
> and just add new drivers for something I'm interested in or is this all or
> nothing kind of thing?
>
> Yes you can do things gradually. If you have a sane early memory
> environment then you shouldn't have much trouble.
>
> >
> > Thank you.
> >
> > --
> > Maxim Sloyko
>
> Regards,
> Simon
>
--
*M*axim *S*loyko
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] U-Boot memory allocation problems with ast2500
2016-09-14 15:50 ` Maxim Sloyko
@ 2016-09-15 14:29 ` Simon Glass
0 siblings, 0 replies; 5+ messages in thread
From: Simon Glass @ 2016-09-15 14:29 UTC (permalink / raw)
To: u-boot
Hi Maxim,
On 14 September 2016 at 09:50, Maxim Sloyko <maxims@google.com> wrote:
>
>
>
> On Fri, Sep 9, 2016 at 4:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi Maxim,
>>
>> On 9 September 2016 at 15:53, Maxim Sloyko <maxims@google.com> wrote:
>> >
>> > Hi all,
>> >
>> > First, disclaimer: this is the first time I'm doing something with U-Boot or the part (ast2500), so any claim I make below can be false or just plain nonsense.
>>
>> Welcome!
>>
>> >
>> > I'm working on expanding support of Aspeed ast2500 part in U-Boot.
>> >
>> > I ran into some problems, when I tried to use Linux Kernel device tree for this part in U-Boot. Looking at diagnostic messages (http://pastebin.ca/3713876) I figured out that the problem is that U-Boot continues to use malloc_simple, even after it has been relocated to RAM. As a result, it fails to allocate 130k needed for environment, because it is larger than the configured size of a memory chunk for simple malloc.
>>
>> The test for this is in dlmalloc.c - the GD_FLG_FULL_MALLOC_INIT flag.
>> The flag is set in initr_reloc() after relocation.
>>
>> I wonder if your global_data (the 'gd' pointer) is not set up
>> correctly, so it cannot write to the flag.
>
>
> OK, so you are right, this flag turned out to be a problem. Global data was setup normally, but then for some reason in board_init there was a line
>
> gd->flags = 0;
>
> I removed it and everything works now.
>
> Thanks for your help!
OK, that's good!
[...]
Regards,
Simon
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-09-15 14:29 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-09 21:53 [U-Boot] U-Boot memory allocation problems with ast2500 Maxim Sloyko
2016-09-09 23:18 ` Simon Glass
2016-09-12 16:29 ` Maxim Sloyko
2016-09-14 15:50 ` Maxim Sloyko
2016-09-15 14:29 ` Simon Glass
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.