diff mbox

[U-Boot,v2,14/15] Introduce arch_phys_memset which works like memset but on physical memory

Message ID 1354460119-23877-15-git-send-email-sjg@chromium.org
State Accepted, archived
Delegated to: Simon Glass
Headers show

Commit Message

Simon Glass Dec. 2, 2012, 2:55 p.m. UTC 
From: Gabe Black <gabeblack@chromium.org>

The default implementation of this function is just memset, but other
implementations will be needed when physical memory isn't accessible by
U-Boot using normal addressing mechanisms.

Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Update README and add to Makefile

 README            |    8 ++++++++
 include/physmem.h |   21 +++++++++++++++++++++
 lib/Makefile      |    1 +
 lib/physmem.c     |   24 ++++++++++++++++++++++++
 4 files changed, 54 insertions(+), 0 deletions(-)
 create mode 100644 include/physmem.h
 create mode 100644 lib/physmem.c

Comments

Wolfgang Denk Dec. 2, 2012, 7:33 p.m. UTC | #1 
Dear Simon Glass,

In message <1354460119-23877-15-git-send-email-sjg@chromium.org> you wrote:
> From: Gabe Black <gabeblack@chromium.org>
> 
> The default implementation of this function is just memset, but other
> implementations will be needed when physical memory isn't accessible by
> U-Boot using normal addressing mechanisms.
> 
> Signed-off-by: Gabe Black <gabeblack@chromium.org>
> Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> Changes in v2:
> - Update README and add to Makefile

This patch comes without any threading.  That's really bad!!

Please make sure to supply proper trheading information with ALL patch
submissions!  Thanks.

Best regards,

Wolfgang Denk
Simon Glass Dec. 2, 2012, 9:16 p.m. UTC | #2 
Hi Wolfgang,

On Sun, Dec 2, 2012 at 11:33 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <1354460119-23877-15-git-send-email-sjg@chromium.org> you wrote:
>> From: Gabe Black <gabeblack@chromium.org>
>>
>> The default implementation of this function is just memset, but other
>> implementations will be needed when physical memory isn't accessible by
>> U-Boot using normal addressing mechanisms.
>>
>> Signed-off-by: Gabe Black <gabeblack@chromium.org>
>> Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>> Changes in v2:
>> - Update README and add to Makefile
>
> This patch comes without any threading.  That's really bad!!
>
> Please make sure to supply proper trheading information with ALL patch
> submissions!  Thanks.

I'm not quite sure how do to this. Did we discuss this before? Do I
need to enter the correct ID of the previous patch into the 'in
replace to message id' when git send-email asks me? If so I guess that
means sending one patch at a time.

I am about to send a few more patches out so I will try to do this and
see if it works. Maybe patman should do it automatically.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> ...the increased productivity fostered by a friendly environment  and
> quality  tools  is  essential  to  meet  ever  increasing demands for
> software.               - M. D. McIlroy, E. N. Pinson and B. A. Tague
Wolfgang Denk Dec. 2, 2012, 10:26 p.m. UTC | #3 
Dear Simon Glass,

In message <CAPnjgZ2ABaneWvwmN-56KcgC0juO1MMNhGGQEQ3pfRQSphQt0g@mail.gmail.com> you wrote:
> 
> > Please make sure to supply proper trheading information with ALL patch
> > submissions!  Thanks.
> 
> I'm not quite sure how do to this. Did we discuss this before? Do I

Do we have to?  With all your experience?

If in doubt, please RTFM git-send-email(1); see especially section
starting at "--in-reply-to=<identifier>"

> need to enter the correct ID of the previous patch into the 'in
> replace to message id' when git send-email asks me? If so I guess that
> means sending one patch at a time.

Yes. It Depends.

> I am about to send a few more patches out so I will try to do this and
> see if it works. Maybe patman should do it automatically.

Definitely.

Best regards,

Wolfgang Denk
Tom Rini Dec. 3, 2012, 1:59 p.m. UTC | #4 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/02/12 09:55, Simon Glass wrote:
> From: Gabe Black <gabeblack@chromium.org>
> 
> The default implementation of this function is just memset, but
> other implementations will be needed when physical memory isn't
> accessible by U-Boot using normal addressing mechanisms.
> 
> Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by:
> Che-Liang Chiou <clchiou@chromium.org> Signed-off-by: Simon Glass
> <sjg@chromium.org>

We've supported PowerPC platforms with 36bit memory ranges for ages.
Part of that however I believe is just not touching that high memory
range.  So why do we need to touch the range here, rather than just
configuring the memory controller and booting Linux?  Is this for some
hardware tester for example?

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQvLBWAAoJENk4IS6UOR1WS3oP/3OslD0jJzixbYNn35N+4KjY
dgnkNuLYwiXPhsw9sRttNihf7C2XLfPtbJfQo97hAVSgULLgBjjRN4HtoB9Yx3M1
hMtPcWzt/JxOOzgKwUBF1RdFwQ8ENmD0AYQ3F6D3uNq/3Tez9/VkrrXpbMnNvNyh
cw1fKT0aFDJgTdoK6KWRvXd1Z/cQk0+aWDFXhi1Y1yBag80PKXoiEATrd3hg1Tig
MVFu3QFxjGcYWkZiFtEpn4fpFLzhZVbmxzOzq/JTT33fH60ZJewCkUTVw3zfqBHE
bGyGiNhzZa4Se7cgtL4mkWEGyAmapfMwowM7SPqw3gew5G8lFZdpIKTe+4ECGEdH
dcHaXb28KghE8XUdcA02cWd0COhyFpdsJxuzqzKg3J8S/b4DMLMFcJRalBfTMcm3
T9fSDxa5DwiEoJd0/HTF5ZBR4QQoAp9EOrNU+y2zjF9U7y5USA1smoXSBKQGtZTL
sCB3FFfrGoDHiVks4lhEDqGT+eFPK2cYZzi8RCG3sP8MhfNzaw7ZjUfwi2zjdu/D
scIAh8RexrAvuIG5svqTun7YppRFbTINSIB2Z3WVievJGCUa72ke5eC9cSAaW5Uv
MNoURhgp4lqXLNPiYyKMtJEgyQQrSQVT4Ty0MfxSEWwZVKrU6AQ2OGe/xCHiejSw
0QqmDjrlA/4ntaimuw14
=ahxh
-----END PGP SIGNATURE-----
Simon Glass Dec. 3, 2012, 5:58 p.m. UTC | #5 
Hi Tom,

On Mon, Dec 3, 2012 at 5:59 AM, Tom Rini <trini@ti.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/02/12 09:55, Simon Glass wrote:
>> From: Gabe Black <gabeblack@chromium.org>
>>
>> The default implementation of this function is just memset, but
>> other implementations will be needed when physical memory isn't
>> accessible by U-Boot using normal addressing mechanisms.
>>
>> Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by:
>> Che-Liang Chiou <clchiou@chromium.org> Signed-off-by: Simon Glass
>> <sjg@chromium.org>
>
> We've supported PowerPC platforms with 36bit memory ranges for ages.
> Part of that however I believe is just not touching that high memory
> range.  So why do we need to touch the range here, rather than just
> configuring the memory controller and booting Linux?  Is this for some
> hardware tester for example?

We need to clear all memory as part of the secure boot, to avoid
attacks which involve leaving code around over a reboot, etc. For x86
also we avoid touching memory above 4GB during normal operation, but
it isn't enough to just ignore it, since there might be something
lurking there that someone can invoke. The support is minimal (just
clearing it) and we don't want to start using it in any other way.

Regards,
Simon

>
> - --
> Tom
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJQvLBWAAoJENk4IS6UOR1WS3oP/3OslD0jJzixbYNn35N+4KjY
> dgnkNuLYwiXPhsw9sRttNihf7C2XLfPtbJfQo97hAVSgULLgBjjRN4HtoB9Yx3M1
> hMtPcWzt/JxOOzgKwUBF1RdFwQ8ENmD0AYQ3F6D3uNq/3Tez9/VkrrXpbMnNvNyh
> cw1fKT0aFDJgTdoK6KWRvXd1Z/cQk0+aWDFXhi1Y1yBag80PKXoiEATrd3hg1Tig
> MVFu3QFxjGcYWkZiFtEpn4fpFLzhZVbmxzOzq/JTT33fH60ZJewCkUTVw3zfqBHE
> bGyGiNhzZa4Se7cgtL4mkWEGyAmapfMwowM7SPqw3gew5G8lFZdpIKTe+4ECGEdH
> dcHaXb28KghE8XUdcA02cWd0COhyFpdsJxuzqzKg3J8S/b4DMLMFcJRalBfTMcm3
> T9fSDxa5DwiEoJd0/HTF5ZBR4QQoAp9EOrNU+y2zjF9U7y5USA1smoXSBKQGtZTL
> sCB3FFfrGoDHiVks4lhEDqGT+eFPK2cYZzi8RCG3sP8MhfNzaw7ZjUfwi2zjdu/D
> scIAh8RexrAvuIG5svqTun7YppRFbTINSIB2Z3WVievJGCUa72ke5eC9cSAaW5Uv
> MNoURhgp4lqXLNPiYyKMtJEgyQQrSQVT4Ty0MfxSEWwZVKrU6AQ2OGe/xCHiejSw
> 0QqmDjrlA/4ntaimuw14
> =ahxh
> -----END PGP SIGNATURE-----
diff mbox

Patch

diff --git a/README b/README
index ed7d270..c7aab18 100644
--- a/README
+++ b/README
@@ -2200,6 +2200,14 @@  CBFS (Coreboot Filesystem) support
 			HERMES, IP860, RPXlite, LWMON,
 			FLAGADM, TQM8260
 
+- Access to physical memory region (> 4GB)
+		Some basic support is provided for operations on memory not
+		normally accessible to U-Boot - e.g. some architectures
+		support access to more than 4GB of memory on 32-bit
+		machines using physical address extension or similar.
+		Define CONFIG_PHYSMEM to access this basic support, which
+		currently only supports clearing the memory.
+
 - Error Recovery:
 		CONFIG_PANIC_HANG
 
diff --git a/include/physmem.h b/include/physmem.h
new file mode 100644
index 0000000..03d3a78
--- /dev/null
+++ b/include/physmem.h
@@ -0,0 +1,21 @@ 
+/*
+ * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ */
+
+/*
+ * These functions work like memset but operate on physical memory which may
+ * not be accessible directly.
+ *
+ * @param s	The physical address to start setting memory at.
+ * @param c	The character to set each byte of the region to.
+ * @param n	The number of bytes to set.
+ *
+ * @return	The physical address of the memory which was set.
+ */
+phys_addr_t arch_phys_memset(phys_addr_t s, int c, phys_size_t n);
diff --git a/lib/Makefile b/lib/Makefile
index e44e045..f83f6e8 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -48,6 +48,7 @@  COBJS-$(CONFIG_LMB) += lmb.o
 COBJS-y += ldiv.o
 COBJS-$(CONFIG_MD5) += md5.o
 COBJS-y += net_utils.o
+COBJS-$(CONFIG_PHYSMEM) += physmem.o
 COBJS-y += qsort.o
 COBJS-$(CONFIG_SHA1) += sha1.o
 COBJS-$(CONFIG_SHA256) += sha256.o
diff --git a/lib/physmem.c b/lib/physmem.c
new file mode 100644
index 0000000..0f035ed
--- /dev/null
+++ b/lib/physmem.c
@@ -0,0 +1,24 @@ 
+/*
+ * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ */
+
+#include <common.h>
+#include <physmem.h>
+
+static phys_addr_t __arch_phys_memset(phys_addr_t s, int c, phys_size_t n)
+{
+	void *s_ptr = (void *)(uintptr_t)s;
+
+	assert(((phys_addr_t)(uintptr_t)s) == s);
+	assert(((phys_addr_t)(uintptr_t)(s + n)) == s + n);
+	return (phys_addr_t)(uintptr_t)memset(s_ptr, c, n);
+}
+
+phys_addr_t arch_phys_memset(phys_addr_t s, int c, phys_size_t n)
+	__attribute__((weak, alias("__arch_phys_memset")));