jesultra

I am interested in this as well. My application does TCP communication via mio, and also uses rusb (currently only synchronously). Ideally, I would like to be able to wait...

I think Jett's concern was in part that if ROM_EXT uses memory mapped flash accesses, then reading any flash word that has ECC failure will result in a RISC-V trap,...

...and by the way, the same goes for how the ROM decides which of the two slots of ROM_EXT to jump to. It should also not use memory mapped reads,...

Do we have ROM_EXT linked for both bank A and B? I would like to try composing an image that uses both slots, and then corrupt one or the other...

To answer the question from the last paragraph in Fatih's comment. Yes, we do plan on "keeping the error" to raise a failure later. Specifically, when ROM_EXT looks at the...

No, the main part of the work is still to do, unless I am misunderstanding something. My understanding is this: If the CPU core attempts to read from memory mapped...

Yes, it was me who originally requested that tx_empty were to remain event type. But thinking about it, Jett is right that it is more consistent to have tx_empty be...

You are right, we can probably live with built-in pullup (or pulldown), and do not require the ability to strongly drive the D2 and D3 pins while doing non-quad SPI.

I believe that the ability to control weak pill from the pinmux will satisfy the needs of ChromeOS, since the SPI IP seems to always tri-state the D2 and D3...

We do want to wake on edges on the two pins called lid_open and pwrb, and we also want to wake up on edges on ac_present. Or maybe equally good...