On 19.01.2015 21:39, Stefan Tauner wrote:
Does (cross-)compile but is not run-tested.
Signed-off-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at Acked-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at
Makefile | 2 +- hwaccess.h | 8 ++++++++ platform.h | 5 ++++- 3 files changed, 13 insertions(+), 2 deletions(-)
hwaccess.c needs to be patched as well. Specifically, static inline void sync_primitive(void) needs either a comment why sync_primitive is unneeded or a a code snippet with correct code.
Not sure if I read http://lxr.free-electrons.com/source/arch/sparc/include/asm/barrier_64.h#L47 correctly, but we may need
__asm__ __volatile__("membar #StoreLoad":::"memory")
Mh. That might not be needed if /dev/mem uses a special access mode which enforces memory access ordering in Sparc. Someone else with Sparc knowledge needs to check this.
That said, the patch looks correct apart from the missing hwaccess.c stuff mentioned above.
Regards, Carl-Daniel
On Sun, 25 Jan 2015 03:04:09 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 19.01.2015 21:39, Stefan Tauner wrote:
Does (cross-)compile but is not run-tested.
Signed-off-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at Acked-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at
Makefile | 2 +- hwaccess.h | 8 ++++++++ platform.h | 5 ++++- 3 files changed, 13 insertions(+), 2 deletions(-)
hwaccess.c needs to be patched as well. Specifically, static inline void sync_primitive(void) needs either a comment why sync_primitive is unneeded or a a code snippet with correct code.
Not sure if I read http://lxr.free-electrons.com/source/arch/sparc/include/asm/barrier_64.h#L47 correctly, but we may need
__asm__ __volatile__("membar #StoreLoad":::"memory")
Mh. That might not be needed if /dev/mem uses a special access mode which enforces memory access ordering in Sparc. Someone else with Sparc knowledge needs to check this.
That said, the patch looks correct apart from the missing hwaccess.c stuff mentioned above.
I doubt that we will find something competent enough to answer that quickly. What about adding the information above to hwaccess.c so that it is available in-tree to everybody in case something does not work without a memory barrier?
On 26.01.2015 09:38, Stefan Tauner wrote:
On Sun, 25 Jan 2015 03:04:09 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 19.01.2015 21:39, Stefan Tauner wrote:
Does (cross-)compile but is not run-tested.
Signed-off-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at Acked-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at
Makefile | 2 +- hwaccess.h | 8 ++++++++ platform.h | 5 ++++- 3 files changed, 13 insertions(+), 2 deletions(-)
hwaccess.c needs to be patched as well. Specifically, static inline void sync_primitive(void) needs either a comment why sync_primitive is unneeded or a a code snippet with correct code.
Not sure if I read http://lxr.free-electrons.com/source/arch/sparc/include/asm/barrier_64.h#L47 correctly, but we may need
__asm__ __volatile__("membar #StoreLoad":::"memory")
Mh. That might not be needed if /dev/mem uses a special access mode which enforces memory access ordering in Sparc. Someone else with Sparc knowledge needs to check this.
That said, the patch looks correct apart from the missing hwaccess.c stuff mentioned above.
I doubt that we will find something competent enough to answer that quickly. What about adding the information above to hwaccess.c so that it is available in-tree to everybody in case something does not work without a memory barrier?
"Get it to compile first, work about correctness later"... not exactly a flashrom principle, but in this case it helps with code coverage and eliminates blacklists in package building, so be it. Are there any architectures left for building on modern debian? AArch64, Alpha? Adding the barrier info as comment is probably the best way to do it, and maybe disabling all non-USB/non-serial programmers. That would also completely eliminate the effect of memory barriers.
That said, the least we can do is make sure the internal programmer is never built for SPARC (no code to do anything useful).
Regards, Carl-Daniel
On Mon, 26 Jan 2015 10:26:34 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 26.01.2015 09:38, Stefan Tauner wrote:
On Sun, 25 Jan 2015 03:04:09 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 19.01.2015 21:39, Stefan Tauner wrote:
Does (cross-)compile but is not run-tested.
Signed-off-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at Acked-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at
Makefile | 2 +- hwaccess.h | 8 ++++++++ platform.h | 5 ++++- 3 files changed, 13 insertions(+), 2 deletions(-)
hwaccess.c needs to be patched as well. Specifically, static inline void sync_primitive(void) needs either a comment why sync_primitive is unneeded or a a code snippet with correct code.
Not sure if I read http://lxr.free-electrons.com/source/arch/sparc/include/asm/barrier_64.h#L47 correctly, but we may need
__asm__ __volatile__("membar #StoreLoad":::"memory")
Mh. That might not be needed if /dev/mem uses a special access mode which enforces memory access ordering in Sparc. Someone else with Sparc knowledge needs to check this.
That said, the patch looks correct apart from the missing hwaccess.c stuff mentioned above.
I doubt that we will find something competent enough to answer that quickly. What about adding the information above to hwaccess.c so that it is available in-tree to everybody in case something does not work without a memory barrier?
"Get it to compile first, work about correctness later"... not exactly a flashrom principle, but in this case it helps with code coverage and eliminates blacklists in package building, so be it. Are there any architectures left for building on modern debian? AArch64, Alpha? Adding the barrier info as comment is probably the best way to do it, and maybe disabling all non-USB/non-serial programmers. That would also completely eliminate the effect of memory barriers.
That said, the least we can do is make sure the internal programmer is never built for SPARC (no code to do anything useful).
PCI "port" programmers are disabled for anything != x86 AFAICS. "Normal/other" PCI programmers are enabled everywhere in general AFAICT. Is that really true?
The internal programmer is a bit complicated and I am not sure how to proceed. It would be great to document the status quo somewhere in the code: which architectures support which features and require which libraries and what needs to be done to get the others working. Partially this is done already with the error messages within internal_init() but the code is much too complicated to get a consistent view easily.
One interesting bit for example is this: /* FIXME: Remove this unconditional abort once all PCI drivers are * converted to use little-endian accesses for memory BARs. */ That explains why the internal programmer is completely disabled for little-endian devices... I am just not sure if it is still valid. AFAICS the drivers all use the hwaccess.c function to access PCI space and those have implicit endian conversions built in. Can you give me an example of a failing driver routine please?
Can you please try to document the internal programmer and PCI-related stuff somewhere in one or two spots (e.g. above internal_init() and/or hwaccess.c)? Maybe a abbreviated version of that should end up in an autogenerated wiki table eventually. I just don't have an idea how yet... but that might get better when I know what I am talking about :)
For the release I think we should completely disable all PCI-based modules (including the internal programmer) on SPARC. Is there an easy way to do that or do I need something similar to the "PCI port" disabling that checks and sets all related CONFIG_ programmer variables to no and adds it to UNSUPPORTED_FEATURES instead. Also, I wonder if that should be done for other architectures as well. I really can't tell :/
Was implemented by SPARC newbies, does (cross-)compile but is not run-tested.
Signed-off-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at ---
Well, it is NOT compile-tested yet... because 64b gcc for SPARC seems to be kind of broken... but I am working on it and it will be before I commit it.
Makefile | 2 +- hwaccess.c | 24 ++++++++++++++++++++---- hwaccess.h | 8 ++++++++ platform.h | 5 ++++- 4 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile index bf79866..edd85cc 100644 --- a/Makefile +++ b/Makefile @@ -318,7 +318,7 @@ endif # below uses CC itself. override ARCH := $(strip $(shell LC_ALL=C $(CC) $(CPPFLAGS) -E archtest.c 2>/dev/null | grep -v '^#' | grep '"' | cut -f 2 -d'"'))
-# PCI port I/O support is unimplemented on PPC/MIPS and unavailable on ARM. +# PCI port I/O support is unimplemented on PPC/MIPS/SPARC and unavailable on ARM. # Right now this means the drivers below only work on x86. ifneq ($(ARCH), x86) ifeq ($(CONFIG_NIC3COM), yes) diff --git a/hwaccess.c b/hwaccess.c index c90490b..0b7d7c3 100644 --- a/hwaccess.c +++ b/hwaccess.c @@ -49,13 +49,29 @@ int io_fd; */ static inline void sync_primitive(void) { -/* This is needed only on PowerPC because... - * - x86 uses uncached accesses which have a strongly ordered memory model and - * - MIPS uses uncached accesses in mode 2 on /dev/mem which has also a strongly ordered memory model - * - ARM uses a strongly ordered memory model for device memories. +/* This is not needed for... + * - x86: uses uncached accesses which have a strongly ordered memory model. + * - MIPS: uses uncached accesses in mode 2 on /dev/mem which has also a strongly ordered memory model. + * - ARM: uses a strongly ordered memory model for device memories. + * + * See also https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documen... */ #if IS_PPC // cf. http://lxr.free-electrons.com/source/arch/powerpc/include/asm/barrier.h asm("eieio" : : : "memory"); +#elif IS_SPARC +#ifdef defined(__sparc_v9__) || defined(__sparcv9) + /* Sparc V9 CPUs support three different memory orderings that range from x86-like TSO to PowerPC-like + * RMO. The modes can be switched at runtime thus to make sure we maintain the right order of access we + * use the strongest hardware memory barriers that exist on Sparc V9. */ + asm volatile ("membar #Sync" ::: "memory"); +#elif defined(__sparc_v8__) || defined(__sparcv8) + /* On SPARC V8 there is no RMO just PSO and that does not apply to I/O accesses... but if V8 code is run + * on V9 CPUs it might apply... or not... we issue a write barrier anyway. That's the most suitable + * operation in the V8 instruction set anyway. If you know better then please tell us. */ + asm volatile ("stbar"); +#else + #error Unknown and/or unsupported SPARC instruction set version detected. +#endif #endif }
diff --git a/hwaccess.h b/hwaccess.h index a4fd502..5378361 100644 --- a/hwaccess.h +++ b/hwaccess.h @@ -89,6 +89,10 @@ #define __FLASHROM_LITTLE_ENDIAN__ 1 #endif
+#elif IS_SPARC +/* SPARC is big endian in general (but allows to access data in little endian too). */ +#define __FLASHROM_BIG_ENDIAN__ 1 + #endif /* IS_? */
#if !defined (__FLASHROM_BIG_ENDIAN__) && !defined (__FLASHROM_LITTLE_ENDIAN__) @@ -357,6 +361,10 @@ int libpayload_wrmsr(int addr, msr_t msr);
/* PCI port I/O is not yet implemented on MIPS. */
+#elif IS_SPARC + +/* PCI port I/O is not yet implemented on SPARC. */ + #elif IS_ARM
/* Non memory mapped I/O is not supported on ARM. */ diff --git a/platform.h b/platform.h index f57fd12..9cde054 100644 --- a/platform.h +++ b/platform.h @@ -45,9 +45,12 @@ defined(__aarch64__) #define __FLASHROM_ARCH__ "arm" #define IS_ARM 1 +#elif defined (__sparc__) || defined (__sparc) + #define __FLASHROM_ARCH__ "sparc" + #define IS_SPARC 1 #endif
-#if !(IS_X86 || IS_MIPS || IS_PPC || IS_ARM) +#if !(IS_X86 || IS_MIPS || IS_PPC || IS_ARM || IS_SPARC) #error Unknown architecture #endif
-
Carl-Daniel Hailfinger -
Stefan Tauner