[PATCH v2 00/11] MAX78000FTHR Implementation

jcksn@duck.com posted 11 patches 4 months, 4 weeks ago
Only 0 patches received!
There is a newer version of this series
hw/misc/max78000_gcr.c | 351 ++++++++++++++++++++++++++++++++
[PATCH v2 00/11] MAX78000FTHR Implementation
Posted by jcksn@duck.com 4 months, 4 weeks ago
 v2 changes: Addresses comments by Peter. For each device: - Switched soc
to use sysbus_realize - Standardized switch case bracing, indentation, and
error case - Added valid min and max access size - Changed endianness to
DEVICE_LITTLE_ENDIAN - Added reset method, if not already implemented -
Added migration support - Split soc integration into separate commit
Machine Implementation: Added user guide URL Removed refclk. According to
https://developer.arm.com/documentation/ddi0403/d/System-Level-Architecture/System-Address-Map/The-system-timer--SysTick/SysTick-Control-and-Status-Register--SYST-CSR
the systick clock can be either the processor clock or an implementation
defined external reference clock. As far as I can tell based on the user
guide, the MAX78000 does not define an external reference clock. I have not
confirmed this in hardware. Changed IRQ count to 120 and noted that the
user guide is unclear on this number Fixed unimplemented device lengths and
names ICC: Removed ICC_Invalidate Added number to device names UART: Fixed
interrupts, allowing async UART Added number to device names GCR: Changed
string-based device search to prop links for device reset Changed
cpu_physical_memory_write to address_space_write TRNG: Changed source of
randomness to qemu_guest_getrandom_nofail Did not change interrupt
generation > Your interrupt generation code in this device doesn't look >
right: the interrupt is supposed to be generated when each > new random
number is ready, so in our "generation takes > zero time" model a read from
DATA should provoke a new > interrupt immediately (assuming the interrupt
is enabled): > you need to simulate the ready status bit going low and >
then high again. I believe the interrupt generation is fine in this case;
by latching it high so long as the interrupt is enabled, the interrupt
handler gets called repeatedly until it receives the desired amount of data
and disables the interrupt. I've tested this and it works with the maxim
sdk's implementation of asynchronous trng. > See also my comments on an
earlier patch about the usual > logic being to have an update function
which does > "set interrupt to (condition && enabled)". In this case there
is only one possible interrupt condition (is there random data ready),
which is always true when enabled. As such I don't think a handler function
is really necessary > A minor note on email patchseries formatting:
something odd > seems to have happened with your cover letter. Patches in a
> series are supposed to be followups to the cover letter, but > in this
case each patch email has a header > In-reply-to:
20250510042043.2056265-1-jcksn@duck.com > but that doesn't match the
message-id of the cover letter mail > (which was >
16B81215-B460-4A49-910E-E5FB479837C8.1@smtp-inbound1.duck.com > ). > > It
looks like something has rewritten the message-ID header > between when git
generated it and it got to the mailing list. > I don't know if that's
something you can fix at your end. > (Otherwise I guess you could work
around it by sending the cover > letter first, finding out what message-ID
it got given, and then > generating the patch emails with the
--in-reply-to=<identifier> > option of git send-email so they come out as
replies to the > cover letter. But that seems a bit of a faff :-/ ) This is
probably because my emails are forwarded through duckduckgo with the @
duck.com address. I've attempted the suggested workaround.
Testing with my own email addresses suggests it just kicks the problem
one email down the chain; may just submit directly in the future if this
does not work. v1: This patch series implements basic support for the
MAX78000FTHR machine https://github.com/JacksonDonaldson/max78000Test
Contains instructions for building a test program against the MAX78000FTHR
as well as results of the test suite run on QEMU and hardware.
Jackson Donaldson (11):
MAX78000: Add MAX78000FTHR Machine MAX78000: ICC Implementation MAX78000:
Add ICC to SOC MAX78000: UART Implementation MAX78000: Add UART to SOC
MAX78000: GCR Implementation MAX78000: Add GCR to SOC MAX78000: TRNG
Implementation MAX78000: Add TRNG to SOC MAX78000: AES implementation
MAX78000: Add AES to SOC hw/arm/Kconfig | 15 ++ hw/arm/max78000_soc.c | 234
+++++++++++++++++++++ hw/arm/max78000fthr.c | 50 +++++ hw/arm/meson.build |
2 + hw/char/Kconfig | 3 + hw/char/max78000_uart.c | 285
++++++++++++++++++++++++++ hw/char/meson.build | 1 + hw/misc/Kconfig | 12
++ hw/misc/max78000_aes.c | 232 +++++++++++++++++++++
hw/misc/max78000_gcr.c | 351 ++++++++++++++++++++++++++++++++
hw/misc/max78000_icc.c | 120 +++++++++++ hw/misc/max78000_trng.c | 127
++++++++++++ hw/misc/meson.build | 4 + include/hw/arm/max78000_soc.h | 50
+++++ include/hw/char/max78000_uart.h | 78 +++++++
include/hw/misc/max78000_aes.h | 68 +++++++ include/hw/misc/max78000_gcr.h
| 131 ++++++++++++ include/hw/misc/max78000_icc.h | 33 +++
include/hw/misc/max78000_trng.h | 35 ++++ 19 files changed, 1831
insertions(+) create mode 100644 hw/arm/max78000_soc.c create mode 100644
hw/arm/max78000fthr.c create mode 100644 hw/char/max78000_uart.c create
mode 100644 hw/misc/max78000_aes.c create mode 100644
hw/misc/max78000_gcr.c create mode 100644 hw/misc/max78000_icc.c create
mode 100644 hw/misc/max78000_trng.c create mode 100644
include/hw/arm/max78000_soc.h create mode 100644
include/hw/char/max78000_uart.h create mode 100644
include/hw/misc/max78000_aes.h create mode 100644
include/hw/misc/max78000_gcr.h create mode 100644
include/hw/misc/max78000_icc.h create mode 100644
include/hw/misc/max78000_trng.h -- 2.34.1