Re: Teensy 4.1 Implementation
> Your board code should be setting the init-nsvtor property on > the armv7m object to 0x0020, if it isn't already. I'm going to add that property right away! > Yes, this would be in line with the way we use -kernel on other > M-profile board models. Got it! Thank you for correcting my understanding! > I'll have a think about which one of those I prefer, and maybe > write a patch... I do think it would be better with such a solution, yes. I personally think querying init-nsvtor would reduce complexity and "make sense". Or perhaps both? Something as simple as adding a function taking a functing the base load address as a parameter, and another that queries init-nsvtor and call it with that value? Everyone would happy :p I will go with the "padded 0 bytes" plan for now, so that I can move on with the rest of the implementation, but please do ping me if you do end up upstreaming such a patch! As always, thanks again! Saana Le mar. 23 août 2022 à 16:22, Peter Maydell a écrit : > On Tue, 23 Aug 2022 at 15:00, Shiny Saana wrote: > > From experimentation and dissasembly on the ROM, (located in > 0x0020_), the very first int (converted to BE) is "0x2020_1000" , which > is located to "OCRAM2", also referred as "ROM RAM" by the documentation, > and the next int is "0x0020_2091", which both points inside the ROM itself > , and which when forcibly disassembled in Ghidra does look like a function. > > So I'm pretty confident the initial vector base address is 0x0020_. > > Right. In fact, rereading the datasheet, I see that I overlooked > that the IOMUXC_GPR_GPR16 reset value is actually specified. Bits > [31:7] of that are the CM7_INIT_VTOR, which is to say that they're > bits [31:7] of the initial vector table address. And they're set > so that is 0x0020_. > > Your board code should be setting the init-nsvtor property on > the armv7m object to 0x0020, if it isn't already. > > > Regarding the "kernel loading" issue, I believe that I was initially > > mistaken. From other examples online, I believed that it was the way > > to load the Teensy image. But thinking and discussing it with another > > ARM dev, wouldn't the ROM itself actually be considered the kernel? > > Yes, this would be in line with the way we use -kernel on other > M-profile board models. > > > Knowing that, if the call to armv7m_load_kernel() is mandatory, > > maybe it would make sense to load the ROM in C code via this > > function, with the compiled ROM addresses from 0x_ to > > 0x001F_ being padded with 0. > > That's one way to do it. I think it would be better to adjust > armv7m_load_kernel() so that it loaded the file to a board-specific > ROM base, which would avoid the need for the weird zero-padding. > Two options: > * we could make armv7m_load_kernel() take a base address as well as >a size for the region it loads the "kernel" to > * we could have armv7m_load_kernel() be clever enough to query >the CPU to find out what the VTOR value is and load the >"kernel" there > > I'll have a think about which one of those I prefer, and maybe > write a patch... > > thanks > -- PMM >
Re: Teensy 4.1 Implementation
On Tue, 23 Aug 2022 at 15:00, Shiny Saana wrote: > From experimentation and dissasembly on the ROM, (located in 0x0020_), > the very first int (converted to BE) is "0x2020_1000" , which is located to > "OCRAM2", also referred as "ROM RAM" by the documentation, and the next int > is "0x0020_2091", which both points inside the ROM itself , and which when > forcibly disassembled in Ghidra does look like a function. > So I'm pretty confident the initial vector base address is 0x0020_. Right. In fact, rereading the datasheet, I see that I overlooked that the IOMUXC_GPR_GPR16 reset value is actually specified. Bits [31:7] of that are the CM7_INIT_VTOR, which is to say that they're bits [31:7] of the initial vector table address. And they're set so that is 0x0020_. Your board code should be setting the init-nsvtor property on the armv7m object to 0x0020, if it isn't already. > Regarding the "kernel loading" issue, I believe that I was initially > mistaken. From other examples online, I believed that it was the way > to load the Teensy image. But thinking and discussing it with another > ARM dev, wouldn't the ROM itself actually be considered the kernel? Yes, this would be in line with the way we use -kernel on other M-profile board models. > Knowing that, if the call to armv7m_load_kernel() is mandatory, > maybe it would make sense to load the ROM in C code via this > function, with the compiled ROM addresses from 0x_ to > 0x001F_ being padded with 0. That's one way to do it. I think it would be better to adjust armv7m_load_kernel() so that it loaded the file to a board-specific ROM base, which would avoid the need for the weird zero-padding. Two options: * we could make armv7m_load_kernel() take a base address as well as a size for the region it loads the "kernel" to * we could have armv7m_load_kernel() be clever enough to query the CPU to find out what the VTOR value is and load the "kernel" there I'll have a think about which one of those I prefer, and maybe write a patch... thanks -- PMM
Re: Teensy 4.1 Implementation
Thank you again for your time! I didn't know at all about the generic loader!! It feels to me that it will definitely be very useful in loading the Teensy image. (To give more background: the Teensy-Arduinon toolchain first compiles an .elf and then convert that to an Intex hex file. We can retrieve that .elf in /tmp after compilation, but if all you have is an ihex (which is the case for my use-case), then you're out of luck.) To answer your question: > Do you know what the hardware sets the initial vector > base address to? (that is, where the ROM itself puts its > reset/interrupt vector table). I couldn't find anything in > the datasheet that said that. >From experimentation and dissasembly on the ROM, (located in 0x0020_), the very first int (converted to BE) is "0x2020_1000" , which is located to "OCRAM2", also referred as "ROM RAM" by the documentation, and the next int is "0x0020_2091", which both points inside the ROM itself , and which when forcibly disassembled in Ghidra does look like a function. So I'm pretty confident the initial vector base address is 0x0020_. Regarding the "kernel loading" issue, I believe that I was initially mistaken. From other examples online, I believed that it was the way to load the Teensy image. But thinking and discussing it with another ARM dev, wouldn't the ROM itself actually be considered the kernel? The teensy ihex image (converted to raw binary) could then be loaded via the generic loader (and then, document that behavior in QEMU, and for user convenience, in my own program using QEMU, I could merely provide a script that handles the arguments for them). Knowing that, if the call to armv7m_load_kernel() is mandatory, maybe it would make sense to load the ROM in C code via this function, with the compiled ROM addresses from 0x_ to 0x001F_ being padded with 0. I'm *absolutely not sure* if this is a good idea, but that's the one I got from the understanding that I have. As always, thank you again for the help (and for using some of your time to go through the documentation yourself, I genuinely appreciate the help a great lot.) Saana Le mar. 23 août 2022 à 15:09, Peter Maydell a écrit : > On Sun, 21 Aug 2022 at 01:05, Shiny Saana wrote: > > I've been able to write an initial Teensy 4.1 machine, for now with > > only the few important memory regions initialized, and successfully > > ran some hand-written ARM code on it. > > Great, that's good progress! > > > The documentation ( https://www.pjrc.com/teensy/IMXRT1060RM_rev3.pdf ), > > in section 9.7.1, gives some informations on how, in the actual > > Teensy board, the ROM, executed at boot, initialize the board > > peripherals, and also reads from a data structure included in the > > Flash memory (the user-provided program) where the CPU should jump > > to after the ROM has done its work (somewhere in that same Flash memory, > > usually). > > > > I was able to successfully dump the ROM of the real board and > > confirm this behavior. Given that the current plan is not to > > emulate every peripherals, I am of the opinion that writing a very > > simple ROM that merely reads this Flash provided data structure and > > jumps to the provided address sounds like a good starting point, so > > that I can keep iterating on writing more and more complex code > > through the provided Teensy toolchain, and implementing needed > > peripherals. > > > > As such, I have several questions: > > > > 1/ To replicate this behaviour, is this considered the correct > > approach by the current QEMU maintainers? > > Yes, I think this is probably a reasonable way to go. > > > 2/ If so, I have not been able to find any function that would be > > able to load data into a memory region "statically". Does one > > exist? Is there an alternative to this process? > > Depends exactly what you want to do. If you want "let the user > load data to an arbitrary address", then the "generic loader" > is usually helpful: > https://www.qemu.org/docs/master/system/generic-loader.html > > If you mean "C code within QEMU loads data to a specific place", > rom_add_blob_fixed_as() is probably what you want. This is how > hw/arm/boot.c loads both user-provided data files and the > hand-coded mini-bootloader into the guest. > > > 3/ Regarding loading the "kernel" of the board, as part of the > > init process, I am calling the usual "armv7m_load_kernel" function > > with its usual parameters. However, it seems to load it as the > > very start of the address space, which is not where the flash > > memory is, and so is not where the kernel should be loaded. I > > wasn't able to find a workaround. Is there something I'm missing? > > The behaviour of armv7m_load_kernel() depends on what kind > of file you pass to -kernel. If you pass -kernel an ELF file, > then it will get loaded to the addresses as specified by > the ELF file, so you can use that to put data anywhere you like. > If you pass it a raw binary file then, yeah, at the
Re: Teensy 4.1 Implementation
On Sun, 21 Aug 2022 at 01:05, Shiny Saana wrote: > I've been able to write an initial Teensy 4.1 machine, for now with > only the few important memory regions initialized, and successfully > ran some hand-written ARM code on it. Great, that's good progress! > The documentation ( https://www.pjrc.com/teensy/IMXRT1060RM_rev3.pdf ), > in section 9.7.1, gives some informations on how, in the actual > Teensy board, the ROM, executed at boot, initialize the board > peripherals, and also reads from a data structure included in the > Flash memory (the user-provided program) where the CPU should jump > to after the ROM has done its work (somewhere in that same Flash memory, > usually). > > I was able to successfully dump the ROM of the real board and > confirm this behavior. Given that the current plan is not to > emulate every peripherals, I am of the opinion that writing a very > simple ROM that merely reads this Flash provided data structure and > jumps to the provided address sounds like a good starting point, so > that I can keep iterating on writing more and more complex code > through the provided Teensy toolchain, and implementing needed > peripherals. > > As such, I have several questions: > > 1/ To replicate this behaviour, is this considered the correct > approach by the current QEMU maintainers? Yes, I think this is probably a reasonable way to go. > 2/ If so, I have not been able to find any function that would be > able to load data into a memory region "statically". Does one > exist? Is there an alternative to this process? Depends exactly what you want to do. If you want "let the user load data to an arbitrary address", then the "generic loader" is usually helpful: https://www.qemu.org/docs/master/system/generic-loader.html If you mean "C code within QEMU loads data to a specific place", rom_add_blob_fixed_as() is probably what you want. This is how hw/arm/boot.c loads both user-provided data files and the hand-coded mini-bootloader into the guest. > 3/ Regarding loading the "kernel" of the board, as part of the > init process, I am calling the usual "armv7m_load_kernel" function > with its usual parameters. However, it seems to load it as the > very start of the address space, which is not where the flash > memory is, and so is not where the kernel should be loaded. I > wasn't able to find a workaround. Is there something I'm missing? The behaviour of armv7m_load_kernel() depends on what kind of file you pass to -kernel. If you pass -kernel an ELF file, then it will get loaded to the addresses as specified by the ELF file, so you can use that to put data anywhere you like. If you pass it a raw binary file then, yeah, at the moment that gets loaded to address 0. There's no real reason for this limitation -- it's mainly because when that code was written we supported very few M-profile boards, and all of them booted from address 0. (That is, the board doesn't set either the init-svtor or init-nsvtor properties on the armv7m object to anything other than 0.) We could change how this works, but the difficulty is that the desire for "Just Do What I Mean" behaviour for a specific board tends to conflict with the desire for all boards to behave in a consistent manner. In particular, at the moment passing a binary file to -kernel means "I want this to be loaded so that it has the CPU vector table in it and execution starts from reset as the architecture says it should"; it can't both mean that consistently across M-profile boards and also mean "on the teeny board, be an image file intended to boot via the ROM loader". Loading the teeny images via the generic loader rather than via -kernel would be one way to sidestep this issue... Do you know what the hardware sets the initial vector base address to? (that is, where the ROM itself puts its reset/interrupt vector table). I couldn't find anything in the datasheet that said that. (By the way, calling armv7m_load_kernel() is mandatory even if you don't care about loading an image, because it's the function that arranges that the CPU gets reset correctly.) thanks -- PMM
Re: Teensy 4.1 Implementation
Hello! Thank you all again for your initial guidance. I've been able to write an initial Teensy 4.1 machine, for now with only the few important memory regions initialized, and successfully ran some hand-written ARM code on it. I was wondering what your opinions might be for implementing the next step, which in my opinion should be bootstrapping a "kernel" in the format the board actually expects. This is however the current roadblock I am hitting. The documentation ( https://www.pjrc.com/teensy/IMXRT1060RM_rev3.pdf ), in section 9.7.1, gives some informations on how, in the actual Teensy board, the ROM, executed at boot, initialize the board peripherals, and also reads from a data structure included in the Flash memory (the user-provided program) where the CPU should jump to after the ROM has done its work (somewhere in that same Flash memory, usually). I was able to successfully dump the ROM of the real board and confirm this behavior. Given that the current plan is not to emulate every peripherals, I am of the opinion that writing a very simple ROM that merely reads this Flash provided data structure and jumps to the provided address sounds like a good starting point, so that I can keep iterating on writing more and more complex code through the provided Teensy toolchain, and implementing needed peripherals. As such, I have several questions: 1/ To replicate this behaviour, is this considered the correct approach by the current QEMU maintainers? 2/ If so, I have not been able to find any function that would be able to load data into a memory region "statically". Does one exist? Is there an alternative to this process? 3/ Regarding loading the "kernel" of the board, as part of the init process, I am calling the usual "armv7m_load_kernel" function with its usual parameters. However, it seems to load it as the very start of the address space, which is not where the flash memory is, and so is not where the kernel should be loaded. I wasn't able to find a workaround. Is there something I'm missing? Sorry to bother you with so many questions. Thanks again, Saana Le mar. 16 août 2022 à 12:06, Peter Maydell a écrit : > On Tue, 16 Aug 2022 at 10:59, Alex Bennée wrote: > > Shiny Saana writes: > > > I personally don't need any of the GPIO interfaces, but if needed > > > by someone else, that could be a good second step to > > > work on once that part of the board is implemented. > > > > Handling GPIOs in QEMU is fine (we have things like the qdev_init_gpio_* > > functions to handle them). The problem is usually what to do with the > > actual general purpose pins which aren't wired to something we emulate > > in the board. Some boards expose their values via QMP properties but I > > suspect whats really needed is a generic mechanism for exposing GPIO to > > external scripts rather than have every board define it's own thing. > > Yes. However one key thing for trying to get a new board model > in is not to get tangled up in trying to improve/extend > the core QEMU facilities for something. That's much harder > than "my board model supports GPIO output lines to the same > extent as the other existing board models" :-) > > thanks > -- PMM >
Re: Teensy 4.1 Implementation
Shiny Saana writes:
> Thank you very much for your answer!
>
> Apologies if I mess up the process of communicating via mailing lists,
> it's my first time communicating via this channel.
Don't worry about it - mailing lists are absolutely a good place to
discuss things ahead of time. I suspect because the devel list looks
to be mostly consisting of PATCHes and discussion of them that puts off
people from asking questions up front.
> The project that requires me to implement this board in QEMU currently would
> require full USB interface and flash
> storage at the end of the day, and I feel on the same page that implementing
> UART via USB would indeed be a good
> place to start.
Does the board use a standardised host controller or something custom?
You can see all the current host controllers in hw/usb/meson.build:
# usb host adapters
softmmu_ss.add(when: 'CONFIG_USB_UHCI', if_true: files('hcd-uhci.c'))
softmmu_ss.add(when: 'CONFIG_USB_OHCI', if_true: files('hcd-ohci.c'))
softmmu_ss.add(when: 'CONFIG_USB_OHCI_PCI', if_true: files('hcd-ohci-pci.c'))
softmmu_ss.add(when: 'CONFIG_USB_EHCI', if_true: files('hcd-ehci.c'))
softmmu_ss.add(when: 'CONFIG_USB_EHCI_PCI', if_true: files('hcd-ehci-pci.c'))
softmmu_ss.add(when: 'CONFIG_USB_EHCI_SYSBUS', if_true: files('hcd-ehci.c',
'hcd-ehci-sysbus.c'))
softmmu_ss.add(when: 'CONFIG_USB_XHCI', if_true: files('hcd-xhci.c'))
softmmu_ss.add(when: 'CONFIG_USB_XHCI_PCI', if_true: files('hcd-xhci-pci.c'))
softmmu_ss.add(when: 'CONFIG_USB_XHCI_SYSBUS', if_true:
files('hcd-xhci-sysbus.c'))
softmmu_ss.add(when: 'CONFIG_USB_XHCI_NEC', if_true: files('hcd-xhci-nec.c'))
softmmu_ss.add(when: 'CONFIG_USB_MUSB', if_true: files('hcd-musb.c'))
softmmu_ss.add(when: 'CONFIG_USB_DWC2', if_true: files('hcd-dwc2.c'))
softmmu_ss.add(when: 'CONFIG_USB_DWC3', if_true: files('hcd-dwc3.c'))
softmmu_ss.add(when: 'CONFIG_TUSB6010', if_true: files('tusb6010.c'))
softmmu_ss.add(when: 'CONFIG_IMX', if_true: files('chipidea.c'))
softmmu_ss.add(when: 'CONFIG_IMX_USBPHY', if_true: files('imx-usb-phy.c'))
softmmu_ss.add(when: 'CONFIG_VT82C686', if_true: files('vt82c686-uhci-pci.c'))
specific_ss.add(when: 'CONFIG_XLNX_VERSAL', if_true:
files('xlnx-versal-usb2-ctrl-regs.c'))
specific_ss.add(when: 'CONFIG_XLNX_USB_SUBSYS', if_true:
files('xlnx-usb-subsystem.c'))
So hopefully you can just use an existing model. Search for the TYPE_FOO
variable for your given host controller to see how the board models
instantiate it.
> I personally don't need any of the GPIO interfaces, but if needed by someone
> else, that could be a good second step to
> work on once that part of the board is implemented.
Handling GPIOs in QEMU is fine (we have things like the qdev_init_gpio_*
functions to handle them). The problem is usually what to do with the
actual general purpose pins which aren't wired to something we emulate
in the board. Some boards expose their values via QMP properties but I
suspect whats really needed is a generic mechanism for exposing GPIO to
external scripts rather than have every board define it's own thing.
>
> I have jotted down a few lines based on the MPS2 implementation, which made
> me get a feel of how a board is
> implemented. I'll look at the board you recommended too, thanks a lot for the
> recommendation!
>
> As for upstreaming, once (if?) I get a working "MVP", and if I cannot figure
> out the best way to submit the patches, I'll
> keep in touch to figure it out, if that's alright!
The submitting patches document has a lot of information on this
including a guide to using sourcehut to publish a branch as emails if
setting up local email is too tricky.
>
> Again, thanks a bunch!
>
> //Saana
>
> Le lun. 15 août 2022 à 16:58, Peter Maydell a
> écrit :
>
> On Sat, 13 Aug 2022 at 18:54, Shiny Saana wrote:
> > I'd like to implement support for emulating the teensy 4.1 board (
> > https://www.pjrc.com/store/teensy41.html) to QEMU.
> >
> > I'm honestly quite lost as to where to start at the moment, since
> > I can't really find any emulated Cortex-M7 that would be close to
> > that board already implemented.
>
> Hi! Yes, implementing a new board and SoC model is quite a bit of
> work, and unfortunately the process isn't really documented, so
> the best thing is to look for some other existing SoC model and
> do something similar. In this case, we implement the Cortex-M7
> CPU itself, but we don't implement the IMXRT1062 SoC that it uses,
> or any similar SoC in that family. (We do have some of the older
> A-profile IMX boards, so it's possible some device models are
> reusable -- but equally they might be very different.)
>
> As a pattern, I would look at the stm32vldiscovery machine.
> This is a Cortex-M3 system based on the stm32f100 SoC, where
> we have implemented a few of the SoC devices and have stub
> implementations of most of the rest. That's a fairly recently
> added M-profile SoC and it's written in the
Re: Teensy 4.1 Implementation
On Tue, 16 Aug 2022 at 10:59, Alex Bennée wrote: > Shiny Saana writes: > > I personally don't need any of the GPIO interfaces, but if needed > > by someone else, that could be a good second step to > > work on once that part of the board is implemented. > > Handling GPIOs in QEMU is fine (we have things like the qdev_init_gpio_* > functions to handle them). The problem is usually what to do with the > actual general purpose pins which aren't wired to something we emulate > in the board. Some boards expose their values via QMP properties but I > suspect whats really needed is a generic mechanism for exposing GPIO to > external scripts rather than have every board define it's own thing. Yes. However one key thing for trying to get a new board model in is not to get tangled up in trying to improve/extend the core QEMU facilities for something. That's much harder than "my board model supports GPIO output lines to the same extent as the other existing board models" :-) thanks -- PMM
Re: Teensy 4.1 Implementation
Thank you very much for your answer! Apologies if I mess up the process of communicating via mailing lists, it's my first time communicating via this channel. The project that requires me to implement this board in QEMU currently would require full USB interface and flash storage at the end of the day, and I feel on the same page that implementing UART via USB would indeed be a good place to start. I personally don't need any of the GPIO interfaces, but if needed by someone else, that could be a good second step to work on once that part of the board is implemented. I have jotted down a few lines based on the MPS2 implementation, which made me get a feel of how a board is implemented. I'll look at the board you recommended too, thanks a lot for the recommendation! As for upstreaming, once (if?) I get a working "MVP", and if I cannot figure out the best way to submit the patches, I'll keep in touch to figure it out, if that's alright! Again, thanks a bunch! //Saana Le lun. 15 août 2022 à 16:58, Peter Maydell a écrit : > On Sat, 13 Aug 2022 at 18:54, Shiny Saana wrote: > > I'd like to implement support for emulating the teensy 4.1 board ( > > https://www.pjrc.com/store/teensy41.html) to QEMU. > > > > I'm honestly quite lost as to where to start at the moment, since > > I can't really find any emulated Cortex-M7 that would be close to > > that board already implemented. > > Hi! Yes, implementing a new board and SoC model is quite a bit of > work, and unfortunately the process isn't really documented, so > the best thing is to look for some other existing SoC model and > do something similar. In this case, we implement the Cortex-M7 > CPU itself, but we don't implement the IMXRT1062 SoC that it uses, > or any similar SoC in that family. (We do have some of the older > A-profile IMX boards, so it's possible some device models are > reusable -- but equally they might be very different.) > > As a pattern, I would look at the stm32vldiscovery machine. > This is a Cortex-M3 system based on the stm32f100 SoC, where > we have implemented a few of the SoC devices and have stub > implementations of most of the rest. That's a fairly recently > added M-profile SoC and it's written in the "modern" style we'd > recommend for new code, so it's a good pattern to copy, and > because it only has a few 'real' devices it's hopefully not an > overwhelmingly large amount of code. > > An initial simple implementation would get a level of > functionality capable of basic "can run code and it will > be able to do serial port (UART) input and output". > (If you're hoping for/would need more than that, do say so, > so we can check how much effort what you're aiming for would be. > Some things QEMU doesn't really support very well, like > emulation of GPIO input/output line hardware lines being > connected to LEDs and switches... In any case "just a UART" > is a good first step.) > > You'll need detailed documentation of both the board and the > SoC. Handily a lot of that is collected here: > https://www.pjrc.com/teensy/datasheets.html > > If you're hoping to submit a new board model upstream you > should give some consideration to git commit structure > as you work on it -- for code review we need big changes like > a new board type to be broken up into smaller self-contained > pieces. It is possible to just write all the code first and > then split it into digestible pieces later, but personally > I find it much easier to try to keep the changes at least > roughly in a series of separate patches as I go along. > > Our "submitting a patch" page has some general advice > and information on our patch processes: > https://www.qemu.org/docs/master/devel/submitting-a-patch.html > > thanks > -- PMM >
Re: Teensy 4.1 Implementation
On Sat, 13 Aug 2022 at 18:54, Shiny Saana wrote: > I'd like to implement support for emulating the teensy 4.1 board ( > https://www.pjrc.com/store/teensy41.html) to QEMU. > > I'm honestly quite lost as to where to start at the moment, since > I can't really find any emulated Cortex-M7 that would be close to > that board already implemented. Hi! Yes, implementing a new board and SoC model is quite a bit of work, and unfortunately the process isn't really documented, so the best thing is to look for some other existing SoC model and do something similar. In this case, we implement the Cortex-M7 CPU itself, but we don't implement the IMXRT1062 SoC that it uses, or any similar SoC in that family. (We do have some of the older A-profile IMX boards, so it's possible some device models are reusable -- but equally they might be very different.) As a pattern, I would look at the stm32vldiscovery machine. This is a Cortex-M3 system based on the stm32f100 SoC, where we have implemented a few of the SoC devices and have stub implementations of most of the rest. That's a fairly recently added M-profile SoC and it's written in the "modern" style we'd recommend for new code, so it's a good pattern to copy, and because it only has a few 'real' devices it's hopefully not an overwhelmingly large amount of code. An initial simple implementation would get a level of functionality capable of basic "can run code and it will be able to do serial port (UART) input and output". (If you're hoping for/would need more than that, do say so, so we can check how much effort what you're aiming for would be. Some things QEMU doesn't really support very well, like emulation of GPIO input/output line hardware lines being connected to LEDs and switches... In any case "just a UART" is a good first step.) You'll need detailed documentation of both the board and the SoC. Handily a lot of that is collected here: https://www.pjrc.com/teensy/datasheets.html If you're hoping to submit a new board model upstream you should give some consideration to git commit structure as you work on it -- for code review we need big changes like a new board type to be broken up into smaller self-contained pieces. It is possible to just write all the code first and then split it into digestible pieces later, but personally I find it much easier to try to keep the changes at least roughly in a series of separate patches as I go along. Our "submitting a patch" page has some general advice and information on our patch processes: https://www.qemu.org/docs/master/devel/submitting-a-patch.html thanks -- PMM
