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