cortex-m mpu: support configuring regions with difficult alignment

The existing configuration code assumes that provided addresses are
at least as aligned as the requested size, which is not true on
NPCX797WC (and likely others) where RAM regions are only 64k-aligned
but have larger sizes (like 256k).

Use a new greedy approach to configuring the MPU which handles these
situations corrently: for any given request take the largest possible
chunk from the bottom of the memory region (subject to size and address
alignment). Maximize the space by aggressively using MPU subregions-
this means that in many well-aligned situations this algorithm selects a
larger region than the requested size and enables one subregion, but in
more difficult situations it is capable of enabling subregions with more
exotic positions.

BUG=b:169276765
BRANCH=zork
TEST=With a test harness to print out computed configurations, manually
     verified the correctness of a variety taken from real chip
     configurations (request first, MPU region(s) indented):
     0x20000000 size 0x1000 # stm32f03x
         0x20000000 size 0x8000 srd fe
     0x20000000 size 0x2000 # stm32f03x
         0x20000000 size 0x10000 srd fe
     0x20000000 size 0x2800 # stm32l100
         0x20000000 size 0x4000 srd e0
     0x20000000 size 0x4000 # stm32f412
         0x20000000 size 0x20000 srd fe
        0x80000 size 0xc000 # it8320
            0x80000 size 0x20000 srd f8
     0xff200000 size 0xa0000 # ish5p4
         0xff200000 size 0x100000 srd e0
     0x200b0000 size 0x20000 # npcx797wb
         0x20080000 size 0x80000 srd e7
     0x10070000 size 0x40000 # npcx797wb
         0x10000000 size 0x80000 srd 7f
         0x10080000 size 0x80000 srd f8
     0x200c0000 size 0x10000 # npcx796f
         0x20080000 size 0x80000 srd ef
     0x10090000 size 0x30000 # npcx796f
         0x10080000 size 0x80000 srd f1
     0x10090000 size 0x20
         0x10090000 size 0x100 srd fe

     Further verified MPU configuration with the new algorithm succeeds
     on Dalboz, and test/mpu.c passes on Dragonclaw.

Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I71d8e2b37c7e20fc7a39166b90eea0b7f7ebcf43
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2434601
Reviewed-by: Edward Hill <ecgh@chromium.org>

1 files changed, 10 insertions, 0 deletions

diff --git a/include/util.h b/include/util.h
index 17c1b3aed8..3d788d01cb 100644
--- a/include/util.h
+++ b/include/util.h
@@ -197,6 +197,16 @@ bool bytes_are_trivial(const uint8_t *buffer, size_t size);
 bool is_aligned(uint32_t addr, uint32_t align);
 
 /**
+ * Get the alignment of x; the number of trailing zero bits.
+ *
+ * x must not be zero, otherwise the result is undefined (and will panic
+ * in debug builds).
+ *
+ * @return the number of consecutive zero bits in x starting from the lsb
+ */
+int alignment_log2(unsigned int x);
+
+/**
  * Reverse's the byte-order of the provided buffer.
  */
 void reverse(void *dest, size_t len);