Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Saturday August 11 2018, @12:53AM   Printer-friendly
from the another-day-another-CPU dept.

Although a wide range of potential applications exists for the ARMV8-M processors, developers working on secure real-time applications will certainly see the largest benefit. So far, the ARMV8-M architecture can be found in M23 and M33 Cortex-M and M35P processors. Let’s take a look at the new features included in ARMV8-M and how these processors differ from previous generation ARMV7-M parts.

[...] The ARMV8-M feature that really sets the M23, M33, and M35P apart is their support for ARM TrustZone. TrustZone is a security extension that provides hardware isolation within the microcontroller so that developers can create secure and unsecure regions. These regions can be locations in RAM, Flash, or even interrupts and peripherals. The separation between secure and unsecure regions creates isolation within the microcontroller, allowing developers to protect mission-critical code and data.

The isolation creates two new modes that the processor can be running in: secure and unsecure. When in secure mode, the executing code can access all memory within both the secure and unsecure zones. However, if the processor is executing in the unsecure zone, only the unsecure regions can be seen. The secure regions are hidden and cannot be executed from the unsecure state without special code being added, which creates a gateway to access a secure call. This makes it possible to use secure functions while hiding what is happening behind the scenes. 

There are several other new features that developers will find interesting besides the TrustZone extension. These include:

  • Simpler MPU setup
  • Flexible breakpoint configuration
  • Improved trace support
  • Instruction set enhancements
  • Dynamic reprioritization of interrupts

Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Interesting) by Anonymous Coward on Saturday August 11 2018, @01:55AM (13 children)

    by Anonymous Coward on Saturday August 11 2018, @01:55AM (#720158)

    If you are sane, you don't play with fire. You keep your IRQ handler trivial. When the top-level handler gets run, it calls a handler for each IRQ with a bit currently set. You clear the cause from hardware as required, then schedule work for later. That scheduled work could be in a task with a scheduling priority, but the handlers themselves always run to completion without being interrupted.

    If you are less sane, you look at the bits that are set to determine how urgent you feel they are. You then reenable anything more urgent than the ones you have to handle, and then you deal with IRQs in whatever fucked-up order you prefer. You can have lengthy IRQ handlers... maybe even find a way to run them in a python interpreter. Go wild. It's dumb, but the simple design I described will support all the foot-shooting you desire.

    Starting Score:    0  points
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  

    Total Score:   2  
  • (Score: 2) by RS3 on Saturday August 11 2018, @02:38AM (9 children)

    by RS3 (6367) on Saturday August 11 2018, @02:38AM (#720165)

    It sounds like you know your stuff, but I'm a little concerned with: "the handlers themselves always run to completion without being interrupted".

    So no preemption? Trouble is, some handlers HAVE to be run fast and can't wait for the others to complete.

    • (Score: 0) by Anonymous Coward on Saturday August 11 2018, @03:01AM (8 children)

      by Anonymous Coward on Saturday August 11 2018, @03:01AM (#720174)

      You can have preemption without direct hardware support for it. I gave two methods.

      In the first method, slower work is done later. This is the Linux style. The true handler just wakes up a task and maybe (if a shared interrupt or otherwise desired) tells the peripheral to stop interrupting. (all true handlers are very fast) Tasks are scheduled as normal, any way you like, with whatever sort of priority system the OS supports. A more throughput-oriented choice would run everything all from one task, and of course you could split the difference with several tasks each handling several IRQ sources. By "task", I don't necessarily mean a normal task, though that is common with RTOSes. Older Linux systems, such as the 2.2.xx kernels, used the bottom-half-handler concept. It gets the same job done, roughly as if running everything in a top-priority task.

      In the second method, not recommended, you immediately determine what interrupts should be able to preempt the current ones. You then enable them. After enabling them, you proceed to handle the ones you have in the order that you prefer. As you finish dealing with each one, you enable it again and also enable anything of higher priority.

      • (Score: 2) by RS3 on Saturday August 11 2018, @03:57AM (1 child)

        by RS3 (6367) on Saturday August 11 2018, @03:57AM (#720195)

        The beauty of your approach is that it's truly programmable, like a computer should be, rather than hard-wired IRQ priorities.

        I think it's a thing that got started by the IBM PC and most people just go along with the crowd, like much of society generally.

        I've played a bit with PCI stuff, but it's been a few years. IIRC, I think PCI interrupt priority is programmable?

        I wish you would use a login. I can never be sure which AC I'm replying to, and hence rarely do.

      • (Score: 2) by RS3 on Saturday August 11 2018, @04:04AM (4 children)

        by RS3 (6367) on Saturday August 11 2018, @04:04AM (#720197)

        Oh, but again, some hardware needs attention (handler) fast, so you need some kind of scheme where the OS understands how long it's allowed to hold off a particular handler, and how critical it is regarding preemption. But that's why Intel added the NMI, and the complaint is that IBM didn't implement it well. But considering the whole world of microcomputing in the late 70s - early 80s, and considering how much and fast it grew, it's obvious that people figured out how to deal with it.

        And if you think about it, reset is just another level of NMI.

        • (Score: 2) by Dr Spin on Saturday August 11 2018, @08:50AM (3 children)

          by Dr Spin (5239) on Saturday August 11 2018, @08:50AM (#720263)

          The PDP11 did the whole job perfectly well. IBM deliberately fouled up the PC to protect its other products which were not cost effective by comparison.

          Yes, you do need hardware interrupt priorities: you can't have a hard disk wait for serial I/O (or any similar situation).

          Intel most certainly did not invent NMI. They just used it wrong. NMI is to handle _unrecoverable errors_ - eg Power fail detect.

          Make the interrupt number the same thing as its priority - easy for the hardware and the programmer. If you wish to downgrade the priority of a task,
          then you give it a different interrupt number. The OS should do this in un-interruptable code. This change is unlikely to happen often, and does not
          need any hardware support except to be possible. The code to move a few words around does not take long to execute, even on an 8051.

          Software interrupts (traps) are very useful - for undefined/unimplemented instructions, virtualisation and debugging, amongst other things. You might as well
          use the same mechanism as for hardware ones. (KISS). The base address of the interrupt structure only need be set when the OS is loaded. There is no
          need to change it later.

          Obviously, these days, memory regions, and all I/O addresses (I/O was memory mapped in PDP11) need to have protection in the traditional way.

          --
          Warning: Opening your mouth may invalidate your brain!
          • (Score: 0) by Anonymous Coward on Saturday August 11 2018, @09:38AM (2 children)

            by Anonymous Coward on Saturday August 11 2018, @09:38AM (#720271)

            I'll start with the specific example you gave: "you can't have a hard disk wait for serial I/O". It's actually the other way around. A hard disk interface can wait. A serial port can't wait too long without losing data.

            So then, here is a reasonable way to make it work:

            The top-level handler (for example, address 0x0018 on ARM or 0x00500 on PowerPC) calls the handler for the hard disk or serial.

            For the hard disk, you simply mark a hard disk task as "runnable" and set a flag to run the scheduler. You then unmask all the other interrupts, start returning from the interrupt, act on the flag (run the scheduler), and then probably (depending on priority) end up in the task that will transfer data to/from the hard disk. If you need to support shared interrupts, change "unmask all the other interrupts" to instead by "clear a flag in the hard drive interface to deassert the interrupt".

            For the serial port, it is probably the same. This is in fact what modern Linux does, but on the 16 MHz 80386SX there wasn't enough CPU power if the serial port didn't have much of a FIFO. In such a case, you might move a few bytes ASAP, but you'd still do all the rest in a separate task. Normal modern hardware, even for low-end IoT devices, doesn't have so much difficulty.

            For both devices, the handler is so short that it doesn't really impact any other handler. All the slow stuff is off in a properly scheduled task.

            The less-reasonable way works too of course. With that, an interrupt for the hard disk would immediately reenable the interrupt for the serial port. An interrupt for the serial port would not reenable the hard disk, because the serial port gets priority.

            It all works out, without any need for the IRQ controller to directly support priorities.

            FYI, I did professional RTOS kernel development prior to switching my career more toward emulation and reverse engineering. Also, if you search a bit, you might be able to find a genuine Linus Torvalds rant about IRQ controllers being better off with bitmaps instead of numeric hardware priority.

            • (Score: 2) by RS3 on Saturday August 11 2018, @01:05PM (1 child)

              by RS3 (6367) on Saturday August 11 2018, @01:05PM (#720290)

              Awesome post, thanks. I really wish you'd use a login- sometimes you ACs are a blur.

              I've always been in favor of more intelligent IO, and we've seen hard disk controllers become more and more intelligent and add more and more buffering, DMA, etc. There are some intelligent serial IO adapters available, including external boxes that run code, buffer, handshake with the host, etc.

              Serial port is a great example for me as I'm also hw and sw eng. I don't know the history, but as long as I've been around serial has had "handshaking" lines that rarely get used. I always thought hardware should honor those lines, but I realize some data can't wait. Buffering was big and expensive back in the day, and still could be an issue for some very tiny PIC and other nanoprocessors (what I call them). XON / XOFF may not be available either. So the burden is back on the host computer to respond quickly. We saw the 16550 come into being, and some software slowly learn to use it, but not all. (waaaa, that's too hard). To be fair, some devices need byte-at-a-time communication, so there's that. Please don't ask me how I know...

              Again (if you're the same AC) I like your interrupt priority under software programmability concept, but you can still do it that way with the Intel 8259- you just have to have a master IRQ handler who controls interrupt priority, 8259 bit masks, etc. Of course I'm referring to the IBM PC architecture.

              It's still always going to be a race and compromise when many things contend for basically a single bus.

              • (Score: 0) by Anonymous Coward on Saturday August 11 2018, @08:29PM

                by Anonymous Coward on Saturday August 11 2018, @08:29PM (#720352)

                The really technical AC posts are all me. I have an old account actually, but I guess I need to do password recovery. It has been a while, I have way too many passwords to deal with, and hard drives containing password managers sometimes die. I'm the Albert who wrote ps, maintained procps from about 1997 to 2007, and did a few kernel patches. I put the Open Source efforts aside for now due to having 11 kids.

                From the above and your post https://soylentnews.org/comments.pl?sid=27021&cid=719376 [soylentnews.org] it looks like you might be the sort of person to get a job where I work. If interested, email albert at users.sf.net for more info. It is this: https://news.ycombinator.com/item?id=17442484 [ycombinator.com]

      • (Score: 2) by RS3 on Saturday August 11 2018, @04:14AM

        by RS3 (6367) on Saturday August 11 2018, @04:14AM (#720204)

        When I was a kid in the late 70s, the next door kid's dad had worked at Burroughs and has some very interesting patents for basically cache RAM. He didn't call it that.

        Anyway, he and a few other engineers formed a company and were designing a CPU- minicomputer- before microprocessors got so big and fast. I remember very large logic drawings, SCSI cables, very large circuit boards covered in TTL (I assume) chips. We've come a long way baby.

        Get an FPGA and do your IRQ system the way you want to. Or just a simple register, OR gates, etc. Feed it into NMI so nobody can mask off interrupts.

        https://hackaday.com/2018/08/06/learn-fpga-fast-with-hackadays-fpga-boot-camp/ [hackaday.com]

  • (Score: 2) by MichaelDavidCrawford on Saturday August 11 2018, @04:49AM (2 children)

    by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Saturday August 11 2018, @04:49AM (#720222) Homepage Journal

    ... that allocating memory from an interrupt handler is ill-advised.

    A dataflow diagram would have clued me into that instantly. Sucks to be me, I had not used them in years by then.

    --
    Yes I Have No Bananas. [gofundme.com]
    • (Score: 2) by RS3 on Saturday August 11 2018, @05:26AM (1 child)

      by RS3 (6367) on Saturday August 11 2018, @05:26AM (#720231)

      Oh, gosh. What CPU / system architecture?

      • (Score: 3, Interesting) by MichaelDavidCrawford on Saturday August 11 2018, @07:37AM

        by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Saturday August 11 2018, @07:37AM (#720246) Homepage Journal

        DSP/BIOS is now called TI RTOS Kernel. I liked it.

        I ported the Apple Firewire Reference Platform to DSP/BIOS. It originally targeted VxWorks. I wrote a driver for a !@#$%^&*() Firewire Link-Layer chip.

        My particular code wasn't doing any signal processing or real-time. It was to enable firewire storage for the Zaxcom Deva 3 wireless audio recorder. It sold like hotcakes.

        --
        Yes I Have No Bananas. [gofundme.com]