Message ID | 1354460119-23877-15-git-send-email-sjg@chromium.org |
---|---|
State | Accepted, archived |
Delegated to: | Simon Glass |
Headers | show |
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
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
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
-----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-----
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 --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")));