在ARM STREX LDREX和原子操作 - 他们可以在I / O寄存器的工作吗？ [英] Atomic operations in ARM strex and ldrex - can they work on I/O registers?

问题描述

假设我在修改的几个比特的内存映射I / O寄存器，这可能是另一个进程或和ISR可以在同一个寄存器修改其他位。

Suppose I'm modifying a few bits in a memory-mapped I/O register, and it's possible that another process or and ISR could be modifying other bits in the same register.

能否LDREX和STREX可用于防止这种？我的意思是，他们可以在原则上，因为你可以LDREX，然后更改位（s）和STREX回来，如果STREX失败则意味着另一个操作可能已经改变了reg，你必须重新开始。但是，这些STREX / LDREX机制在非缓存区中使用？

Can ldrex and strex be used to protect against this? I mean, they can in principle because you can ldrex, and then change the bit(s), and strex it back, and if the strex fails it means another operation may have changed the reg and you have to start again. But can the strex/ldrex mechanism be used on a non-cacheable area?

我已经试过这对树莓PI，与I / O寄存器映射到用户空间，而LDREX操作给我一个总线错误。如果我改变LDREX / STREX一个简单的LDR / STR它工作正常（但不是原子更多...）还有，LDREX / STREX程序在普通内存做工精细。指针是32位对齐。

I have tried this on raspberry pi, with an I/O register mapped into userspace, and the ldrex operation gives me a bus error. If I change the ldrex/strex to a simple ldr/str it works fine (but is not atomic any more...) Also, the ldrex/strex routines work fine on ordinary RAM. Pointer is 32-bit aligned.

原来这就是STREX / LDREX机制的限制？或与BCM2708实施，或在内核设置它的方式有问题？ （或somethinge else-也许我已经映射错）？

So is this a limitation of the strex/ldrex mechanism? or a problem with the BCM2708 implementation, or the way the kernel has set it up? (or somethinge else- maybe I've mapped it wrong)?

推荐答案

谢谢你提我......

Thanks for mentioning me...

您不要在资源本身使用LDREX / STREX对。像SWP或测试，并设置或任何你的指令集支持（针对ARM是SWP和最近STREX / LDREX）。您对RAM使用这些指令，有的RAM地址同意由所有有关各方。共享资源的进程使用的RAM位置打过来资源的控制权，谁就赢，获取到后来居然解决资源。你绝不会使用SWP或LDREX / STREX在外围本身，这是没有意义的。我可以看到内存的系统不给你独家还好反应（EXOKAY），这是你需要走出LDREX / STREX无限循环的东西。

You do not use ldrex/strex pairs on the resource itself. Like swp or test and set or whatever your instruction set supports (for arm it is swp and more recently strex/ldrex). You use these instructions on ram, some ram location agreed to by all the parties involved. The processes sharing the resource use the ram location to fight over control of the resource, whoever wins, gets to then actually address the resource. You would never use swp or ldrex/strex on a peripheral itself, that makes no sense. and I could see the memory system not giving you an exclusive okay response (EXOKAY) which is what you need to get out of the ldrex/strex infinite loop.

您有共享资源的两种基本方法（当然也许更多，但这里有两个）。一种是使用共享内存的位置和共享资源的每个用户，打架拉拢的内存位置的控制。当你赢了你，然后跟我们的资源直接。完成后放弃在共享内存的位置控制。

You have two basic methods for sharing a resource (well maybe more, but here are two). One is you use this shared memory location and each user of the shared resource, fights to win control over the memory location. When you win you then talk to the resource directly. When finished give up control over the shared memory location.

另一种方法是你只有一次允许与外设的软件，没有人被允许过交谈的外设。任何希望得到的东西在外围进行询问一个资源来为他们做。这就像每个人都能够分享汽水喷泉，相较于汽水喷泉柜台后面，只有汽水喷泉员工被允许使用的软饮料喷泉。然后，你需要一个方案要么人排队或有乡亲拿一个号码，被要求有自己的饮料填补。随着单一的资源聊到外围，你必须拿出一个方案，FIFO为例，基本上使请求在本质上连载。

The other method is you have only one piece of software allowed to talk to the peripheral, nobody else is allowed to ever talk to the peripheral. Anyone wishing to have something done on the peripheral asks the one resource to do it for them. It is like everyone being able to share the soft drink fountain, vs the soft drink fountain is behind the counter and only the soft drink fountain employee is allowed to use the soft drink fountain. Then you need a scheme either have folks stand in line or have folks take a number and be called to have their drink filled. Along with the single resource talking to the peripheral you have to come up with a scheme, fifo for example, to essentially make the requests serial in nature.

这些都是荣誉系统。你期望别人交谈谁是不应该去跟周围，或谁没有赢得去跟外围右侧的外设。如果从说话到它寻找硬件解决方案，以prevent乡亲，好了，用MMU但现在你需要管理谁赢得了锁，他们如何获得MMU畅通（不使用荣誉系统），并再阻塞的方式

These are both on the honor system. You expect nobody else to talk to the peripheral who is not supposed to talk to the peripheral, or who has not won the right to talk to the peripheral. If you are looking for hardware solutions to prevent folks from talking to it, well, use the mmu but now you need to manage the who won the lock and how do they get the mmu unblocked (without using the honor system) and re-blocked in a way that

的情况下，你可能具有一个中断处理程序和一个前景任务共享的资源，则有一个或另一个是可触及的资源之一，另一个要求的请求。例如资源可能会被中断驱动的（例如串口），你有中断处理程序跟串口硬件直接，如果应用程序/ forground任务希望得到的东西做它填补了一个请求（把东西在FIFO /缓冲液）的中断，然后查看是否有在请求队列什么，如果是的话就可以了操作。

Situations where you might have an interrupt handler and a foreground task sharing a resource, you have one or the other be the one that can touch the resource, and the other asks for requests. for example the resource might be interrupt driven (a serial port for example) and you have the interrupt handlers talk to the serial port hardware directly, if the application/forground task wants to have something done it fills out a request (puts something in a fifo/buffer) the interrupt then looks to see if there is anything in the request queue, and if so operates on it.

当然，还有就是，禁止中断和重新启用关键部分，但这些都是如果你希望你的中断有计时/延迟一些想法......了解你在做什么，他们可以用来解决吓人这个应用程序+ ISR两个用户的问题。

Of course there is the, disable interrupts and re-enable critical sections, but those are scary if you want your interrupts to have some notion of timing/latency...Understand what you are doing and they can be used to solve this app+isr two user problem.

LDREX / STREX的非缓存存储器空间：

ldrex/strex on non-cached memory space:

我的外测试也许对时，你可以和不能使用LDREX / STREX更多的文字，可惜臂文档是不是在这方面的好。他们告诉你停止使用SWP，这意味着你应该使用STREX / LDREX。但随后切换到硬件手册它说你不要有支持单处理器系统上的独家运营。它说两件事情，LDREX / STREX都是为了多处理器系统，并意味着在多处理器系统上的处理器之间的资源共享。这也意味着，LDREX / STREX不一定支持单处理器系统。然后，它会变得更糟。 ARM的逻辑通常停止或者在处理器核心的边缘时，L1高速缓存包含该边界它不是AXI / AMBA总线上内。或者，如果您购买/使用则L2高速缓存的ARM逻辑停止在该层的边缘。然后，你进入了芯片供应商特定的逻辑。这是您阅读，它说你不需要支持单处理器系统上的独家访问硬件手册的逻辑。所以，问题是特定于供应商。它变得更糟的是，ARM的L1和L2缓存，只要我发现不支持LDREX / STREX，所以如果你对缓存则LDREX / STREX将一个系统，它的供应商code不支持他们的工作。如果你没有缓存上就是当你进入这些系统的麻烦（这是我写的东西EXTEST）。

My extest perhaps has more text on the when you can and cant use ldrex/strex, unfortunately the arm docs are not that good in this area. They tell you to stop using swp, which implies you should use strex/ldrex. But then switch to the hardware manual which says you dont have to support exclusive operations on a uniprocessor system. Which says two things, ldrex/strex are meant for multiprocessor systems and meant for sharing resources between processors on a multiprocessor system. Also this means that ldrex/strex is not necessarily supported on uniprocessor systems. Then it gets worse. ARM logic generally stops either at the edge of the processor core, the L1 cache is contained within this boundary it is not on the axi/amba bus. Or if you purchased/use the L2 cache then the ARM logic stops at the edge of that layer. Then you get into the chip vendor specific logic. That is the logic that you read the hardware manual for where it says you dont NEED to support exclusive accesses on uniprocessor systems. So the problem is vendor specific. And it gets worse, ARM's L1 and L2 cache so far as I have found do support ldrex/strex, so if you have the caches on then ldrex/strex will work on a system whose vendor code does not support them. If you dont have the cache on that is when you get into trouble on those systems (that is the extest thing I wrote).

这有LDREX / STREX这些处理器有足够的新的有通过合作pressor读取访问配置寄存器一家大银行。埋在有支持SWP指令位来判断，如果你有一个交换。剪掉了Cortex-M3的乡亲碰上没有交换的情况，并没有LDREX / STREX？

The processors that have ldrex/strex are new enough to have a big bank of config registers accessed through copressor reads. buried in there is a "swp instruction supported" bit to determine if you have a swap. didnt the cortex-m3 folks run into the situation of no swap and no ldrex/strex?

在Linux内核中的错误（也有一些其他的方面的ARM硬件和文件等误解），就是在支持LDREX / STREX在没有确定是否是多选择的LDREX / STREX解决方案，这样的处理器你可以（而且我知道两个实例）进入一个无限LDREX / STREX环路。如果你修改Linux code，以便它使用的SWP解决方案（这里有关于任何一个解决方案code那里）他们Linux会工作。为什么只有两个人谈过这个，我知道在互联网上，是因为你必须关闭缓存有它发生（据我所知），谁就会关闭两个高速缓存，并尝试运行Linux？它其实需要工作，成功地关闭缓存相当数量，修改到Linux需要得到它没有崩溃工作。

The bug in the linux kernel (there are many others as well for other misunderstandings of arm hardware and documentation) is that on a processor that supports ldrex/strex the ldrex/strex solution is chosen without determining if it is multiprocessor, so you can (and I know of two instances) get into an infinite ldrex/strex loop. If you modify the linux code so that it uses the swp solution (there is code there for either solution) they linux will work. why only two people have talked about this on the internet that I know of, is because you have to turn off the caches to have it happen (so far as I know), and who would turn off both caches and try to run linux? It actually takes a fair amount of work to succesfully turn off the caches, modifications to linux are required to get it to work without crashing.

没有，我不能告诉你的系统，也没有我现在不也永远有ARM的工作。这东西是所有的手臂文档中，如果你知道去哪里找，如何跨preT吧。

No, I cant tell you the systems, and no I do not now nor ever have worked for ARM. This stuff is all in the arm documentation if you know where to look and how to interpret it.

这篇关于在ARM STREX LDREX和原子操作 - 他们可以在I / O寄存器的工作吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！