[flashrom] [PATCH 2/3] Add support for SPARC (maybe).

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Mon Jan 26 10:26:34 CET 2015


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 at 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 at alumni.tuwien.ac.at>
>>> Acked-by: Stefan Tauner <stefan.tauner at 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





More information about the flashrom mailing list