Re: kirkwood stack size

Re: kirkwood stack size

[Tony Dinh]

Hi Marek,

In reference to:
https://lists.denx.de/pipermail/u-boot/2021-October/465221.html

I have several Kirkwood boards, and currently support these boards in
mainline: Sheevaplug, Zyxel NSA310S, GoFlex Home, Dockstar. I also
have a few out-of-tree Kirkwood u-boots that have not been submitted
for mainline yet.

I did not see the stack size problem, or any other problem. And I'm
running the 2021.07 version.

Regards,
Tony

Re: kirkwood stack size

[Marek Behún]

On Wed, 27 Oct 2021 16:06:58 -0700
Tony Dinh <mibodhi@gmail.com> wrote:

> Hi Marek,
> 
> In reference to:
> https://lists.denx.de/pipermail/u-boot/2021-October/465221.html
> 
> I have several Kirkwood boards, and currently support these boards in
> mainline: Sheevaplug, Zyxel NSA310S, GoFlex Home, Dockstar. I also
> have a few out-of-tree Kirkwood u-boots that have not been submitted
> for mainline yet.
> 
> I did not see the stack size problem, or any other problem. And I'm
> running the 2021.07 version.
> 
> Regards,
> Tony

Hi Tony,

thank you for your reply.

I should have mentioned that this concerns only the following
defconfigs:
  km_kirkwood_128m16_defconfig
  km_kirkwood_defconfig
  km_kirkwood_pci_defconfig
since only these store environment in EEPROM.

Marek

Re: kirkwood stack size

[Tony Dinh]

Hi Marek,

Ah. That makes sense! I don't have the km_kirkwood_xxx boards.

Thanks,
Tony

On Wed, Oct 27, 2021 at 6:28 PM Marek Behún <marek.behun@nic.cz> wrote:
>
> On Wed, 27 Oct 2021 16:06:58 -0700
> Tony Dinh <mibodhi@gmail.com> wrote:
>
> > Hi Marek,
> >
> > In reference to:
> > https://lists.denx.de/pipermail/u-boot/2021-October/465221.html
> >
> > I have several Kirkwood boards, and currently support these boards in
> > mainline: Sheevaplug, Zyxel NSA310S, GoFlex Home, Dockstar. I also
> > have a few out-of-tree Kirkwood u-boots that have not been submitted
> > for mainline yet.
> >
> > I did not see the stack size problem, or any other problem. And I'm
> > running the 2021.07 version.
> >
> > Regards,
> > Tony
>
> Hi Tony,
>
> thank you for your reply.
>
> I should have mentioned that this concerns only the following
> defconfigs:
>   km_kirkwood_128m16_defconfig
>   km_kirkwood_defconfig
>   km_kirkwood_pci_defconfig
> since only these store environment in EEPROM.
>
> Marek

Re: kirkwood stack size

[Stefan Roese]

Added Holger, the maintainer of the km_kirkwood boards to Cc...

On 28.10.21 03:28, Marek Behún wrote:
> On Wed, 27 Oct 2021 16:06:58 -0700
> Tony Dinh <mibodhi@gmail.com> wrote:
> 
>> Hi Marek,
>>
>> In reference to:
>> https://lists.denx.de/pipermail/u-boot/2021-October/465221.html
>>
>> I have several Kirkwood boards, and currently support these boards in
>> mainline: Sheevaplug, Zyxel NSA310S, GoFlex Home, Dockstar. I also
>> have a few out-of-tree Kirkwood u-boots that have not been submitted
>> for mainline yet.
>>
>> I did not see the stack size problem, or any other problem. And I'm
>> running the 2021.07 version.
>>
>> Regards,
>> Tony
> 
> Hi Tony,
> 
> thank you for your reply.
> 
> I should have mentioned that this concerns only the following
> defconfigs:
>    km_kirkwood_128m16_defconfig
>    km_kirkwood_defconfig
>    km_kirkwood_pci_defconfig
> since only these store environment in EEPROM.

Holger, could you perhaps take a look here? Marek is working on some
env related stuff that might interfere with your Kirkwood boards, e.g.
the initial stack location.

Thanks,
Stefan

RE: kirkwood stack size

[Holger Brunck]

Hi Stefan, Hi Marek,

> Added Holger, the maintainer of the km_kirkwood boards to Cc...
> 
> On 28.10.21 03:28, Marek Behún wrote:
> > On Wed, 27 Oct 2021 16:06:58 -0700
> > Tony Dinh <mibodhi@gmail.com> wrote:
> >
> >> Hi Marek,
> >>
> >> In reference to:
> >> https://lists.denx.de/pipermail/u-boot/2021-October/465221.html
> >>
> >> I have several Kirkwood boards, and currently support these boards in
> >> mainline: Sheevaplug, Zyxel NSA310S, GoFlex Home, Dockstar. I also
> >> have a few out-of-tree Kirkwood u-boots that have not been submitted
> >> for mainline yet.
> >>
> >> I did not see the stack size problem, or any other problem. And I'm
> >> running the 2021.07 version.
> >>
> >> Regards,
> >> Tony
> >
> > Hi Tony,
> >
> > thank you for your reply.
> >
> > I should have mentioned that this concerns only the following
> > defconfigs:
> >    km_kirkwood_128m16_defconfig
> >    km_kirkwood_defconfig
> >    km_kirkwood_pci_defconfig
> > since only these store environment in EEPROM.
> 
> Holger, could you perhaps take a look here? Marek is working on some env
> related stuff that might interfere with your Kirkwood boards, e.g.
> the initial stack location.
> 

first answer yes the boards are still maintained and alive. In production for
km_kirkwood our latest branch in use is 2016.10, but we keep it up to date
in case we need to upgrade.

I was not able to compile the latest master due to some problems most
likely related to my outdated host compiler, but I was compiling a version
for this target from the 2021.04 release and gave it a try on my board.
It seems to run without any issues. Also saving and reloading the
environment from eeprom works fine.

Best regards 
Holger

Re: kirkwood stack size

[Stefan Roese]

Hi Holger,

On 28.10.21 11:37, Holger Brunck wrote:
> Hi Stefan, Hi Marek,
> 
>> Added Holger, the maintainer of the km_kirkwood boards to Cc...
>>
>> On 28.10.21 03:28, Marek Behún wrote:
>>> On Wed, 27 Oct 2021 16:06:58 -0700
>>> Tony Dinh <mibodhi@gmail.com> wrote:
>>>
>>>> Hi Marek,
>>>>
>>>> In reference to:
>>>> https://lists.denx.de/pipermail/u-boot/2021-October/465221.html
>>>>
>>>> I have several Kirkwood boards, and currently support these boards in
>>>> mainline: Sheevaplug, Zyxel NSA310S, GoFlex Home, Dockstar. I also
>>>> have a few out-of-tree Kirkwood u-boots that have not been submitted
>>>> for mainline yet.
>>>>
>>>> I did not see the stack size problem, or any other problem. And I'm
>>>> running the 2021.07 version.
>>>>
>>>> Regards,
>>>> Tony
>>>
>>> Hi Tony,
>>>
>>> thank you for your reply.
>>>
>>> I should have mentioned that this concerns only the following
>>> defconfigs:
>>>     km_kirkwood_128m16_defconfig
>>>     km_kirkwood_defconfig
>>>     km_kirkwood_pci_defconfig
>>> since only these store environment in EEPROM.
>>
>> Holger, could you perhaps take a look here? Marek is working on some env
>> related stuff that might interfere with your Kirkwood boards, e.g.
>> the initial stack location.
>>
> 
> first answer yes the boards are still maintained and alive. In production for
> km_kirkwood our latest branch in use is 2016.10, but we keep it up to date
> in case we need to upgrade.

Thanks for confirming.

> I was not able to compile the latest master due to some problems most
> likely related to my outdated host compiler, but I was compiling a version
> for this target from the 2021.04 release and gave it a try on my board.
> It seems to run without any issues. Also saving and reloading the
> environment from eeprom works fine.

Thanks for testing. You might want to download and use a recent
toolchain from kernel.org for latest master, e.g. gcc 11 [1].

Thanks,
Stefan

[1] 
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-arm-linux-gnueabi.tar.xz

Re: kirkwood stack size

[Marek Behún]

OK I discovered how it works :)

Pre-relocation only env_init() is called, which does not call
the .load() env driver method, only .init().

So the 2K stack usage in env_eeprom_load() is only used after
relocation, and at that time stack is big enough to contain it.

This means that I can greatly simplify the env_eeprom_load() function.

Marek

Re: kirkwood stack size

[Stefan Roese]

Hi Marek,

On 28.10.21 00:07, Marek Behún wrote:
> Hello Stefan,
> 
> do you have some ARM Kirkwood board?

No, I don't have of them here. Sorry.

> I am working on some env patches,
> because the code in the env/ directory is a pain in the ass of old
> relics, and Kirkwood is the only platform using the eeprom environment
> driver.
> 
> I would like to ask about Kirkwood stack size.
> 
> In arch/arm/mach-kirkwood/include/mach/config.h it says
> 
> /* Kirkwood has 2k of Security SRAM, use it for SP */
> #define CONFIG_SYS_INIT_SP_ADDR		0xC8012000
> 
> So if I understand correctly, Kirkwood has only 2k of init stack.
> 
> But the env_eeprom_load() method in env/eeprom.c allocates a
> CONFIG_ENV_SIZE bytes long array for environment, and CONFIG_ENV_SIZE
> is 2k.
> 
> Is the init stack changed to another stack before environment is loaded?
> I couldn't find code which would do that. As far as I am able to
> determine, this 2k long init stack is used, and this means that the
> code in env/eeprom.c is wrong, since it allocates below stack space.
> 
> Maybe no one used newer U-Boot on Kirkwood for a long time and this was
> not noticed? Should we remove support for Kirkwood?

As you have noticed, Tony is actively working on Kirkwood support
lately.

Thanks,
Stefan

kirkwood stack size

[Marek Behún]

Hello Stefan,

do you have some ARM Kirkwood board? I am working on some env patches,
because the code in the env/ directory is a pain in the ass of old
relics, and Kirkwood is the only platform using the eeprom environment
driver.

I would like to ask about Kirkwood stack size.

In arch/arm/mach-kirkwood/include/mach/config.h it says

/* Kirkwood has 2k of Security SRAM, use it for SP */
#define CONFIG_SYS_INIT_SP_ADDR		0xC8012000

So if I understand correctly, Kirkwood has only 2k of init stack.

But the env_eeprom_load() method in env/eeprom.c allocates a
CONFIG_ENV_SIZE bytes long array for environment, and CONFIG_ENV_SIZE
is 2k.

Is the init stack changed to another stack before environment is loaded?
I couldn't find code which would do that. As far as I am able to
determine, this 2k long init stack is used, and this means that the
code in env/eeprom.c is wrong, since it allocates below stack space.

Maybe no one used newer U-Boot on Kirkwood for a long time and this was
not noticed? Should we remove support for Kirkwood?

Marek