public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm: socfpga: Fix bootcounter located at the end of internal SRAM
Date: Tue, 30 Oct 2018 10:36:36 +0100	[thread overview]
Message-ID: <394b57bb-cacb-e2b7-e897-c777e34589ec@denx.de> (raw)
In-Reply-To: <CAAh8qsxc3-8Nctt2pU5h=agM+QkrQqX2t0W9WpVCzUavKhXSkA@mail.gmail.com>

Hi Simon,

On 30.10.18 10:07, Simon Goldschmidt wrote:
> 
> 
> Stefan Roese <sr at denx.de <mailto:sr@denx.de>> schrieb am Di., 30. Okt. 2018, 10:00:
> 
>     Commit 768f23dc8ae3 ("ARM: socfpga: Put stack at the end of SRAM") broke
>     those socfpga boards that keep the bootcounter at the end of the
>     internal SRAM as the bootcounter needs 8 bytes by default and thus the
>     very first SPL call to board_init_f_alloc_reserve overwrites the
>     bootcounter.
> 
>     This patch allows to move the initial stack pointer down a bit by
>     checking if CONFIG_SYS_BOOTCOUNT_ADDR is located in the internal SRAM
>     area and then using this address as location for the start of the
>     stack pointer.
> 
>     No new macros / defines are added by this approach.
> 
> 
> Ok, so no new macros are defined, but this is limited to the boot
> counter. However, I need to store additional data that survives a
> reboot somewhere, so I think an explicit range reservation would
> be nicer.

Ah, I was not aware that you have a different reasoning to allocate
some memory in the internal SRAM.
  
> I could still do what I want with your patch by allocating my data
> above the bootcounter, but this works in a more or less implicit/
> hidden way, not explicitly configured...

Some implicit (hidden) means is definitely not good. You can go ahead
with your approach. But please don't introduce new defines for things
that are already configured - meaning 0x8 bytes reserved and 0xfffffff8
as bootcounter location are redundant. This is a bit messy and might
get out of hand, once those defines are not in sync any more.

And you probably need to add new defines to Kconfig as well
(e.g. SOCFPGA_INIT_RAM_END_RESERVE).

Thanks,
Stefan
  
> Simon
> 
> 
>     Signed-off-by: Stefan Roese <sr at denx.de <mailto:sr@denx.de>>
>     Cc: Marek Vasut <marex at denx.de <mailto:marex@denx.de>>
>     Cc: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com <mailto:simon.k.r.goldschmidt@gmail.com>>
>     ---
>       include/configs/socfpga_common.h | 13 +++++++++++++
>       1 file changed, 13 insertions(+)
> 
>     diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
>     index 2330143cf1..bd8f5c8c41 100644
>     --- a/include/configs/socfpga_common.h
>     +++ b/include/configs/socfpga_common.h
>     @@ -31,8 +31,21 @@
>       #define CONFIG_SYS_INIT_RAM_ADDR       0xFFE00000
>       #define CONFIG_SYS_INIT_RAM_SIZE       0x40000 /* 256KB */
>       #endif
>     +
>     +/*
>     + * Some boards (e.g. socfpga_sr1500) use 8 bytes at the end of the internal
>     + * SRAM as bootcounter storage. Make sure to not put the stack directly
>     + * at this address to not overwrite the bootcounter by checking, if the
>     + * bootcounter address is located in the internal SRAM.
>     + */
>     +#if ((CONFIG_SYS_BOOTCOUNT_ADDR > CONFIG_SYS_INIT_RAM_ADDR) && \
>     +     (CONFIG_SYS_BOOTCOUNT_ADDR < (CONFIG_SYS_INIT_RAM_ADDR +  \
>     +                                  CONFIG_SYS_INIT_RAM_SIZE)))
>     +#define CONFIG_SYS_INIT_SP_ADDR                CONFIG_SYS_BOOTCOUNT_ADDR
>     +#else
>       #define CONFIG_SYS_INIT_SP_ADDR                        \
>              (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)
>     +#endif
> 
>       #define CONFIG_SYS_SDRAM_BASE          PHYS_SDRAM_1
> 
>     -- 
>     2.19.1
> 

Viele Grüße,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

  reply	other threads:[~2018-10-30  9:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-30  9:00 [U-Boot] [PATCH] arm: socfpga: Fix bootcounter located at the end of internal SRAM Stefan Roese
2018-10-30  9:07 ` Simon Goldschmidt
2018-10-30  9:36   ` Stefan Roese [this message]
2018-10-30 10:24     ` Marek Vasut
2018-10-30 10:34     ` Simon Goldschmidt
2018-10-30 11:17       ` Simon Goldschmidt
2018-10-30 11:28         ` Stefan Roese
2018-10-30 12:37           ` Simon Goldschmidt
2018-10-30 12:50             ` Stefan Roese
2018-10-30 13:02               ` Simon Goldschmidt
2018-10-30 13:13                 ` Stefan Roese
2018-10-30 13:24                   ` Marek Vasut
2018-10-30 15:00                     ` Simon Goldschmidt
2018-10-30 15:18                       ` Marek Vasut
2018-10-30 15:33                         ` Stefan Roese
2018-10-30 16:59                           ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=394b57bb-cacb-e2b7-e897-c777e34589ec@denx.de \
    --to=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox