| Age | Commit message (Collapse) | Author |
|---|
|
|
|
doc update
|
|
|
|
Port NXP iMX RT10XX
|
|
|
|
|
|
rt1064 work with cdc msc example
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
drop supporting both device mode on both ports.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
eptri: clear proper endpoint when opening IN port
|
|
|
|
When opening a USB port, we ensure the buffer is NULL and has
a length of 0.
Due to a mistake in specifying the endpoint type, we never actually
cleared the value when opening an IN endpoint. This patch fixes
the comparison when opening an IN endpoint.
This fixes issue #218.
Signed-off-by: Sean Cross <[email protected]>
|
|
current board that doesn work with flto is spresense and mimxrt10xx (due
to xip image_vector_table is optimized out).
|
|
LTO is temporary disabled
|
|
WIP: Add Valentyusb eptri
|
|
Fix issue 207
|
|
When compiled without usb support, we don't want to call the USB ISR.
Signed-off-by: Sean Cross <[email protected]>
|
|
These functions are unused in the current implementation.
Signed-off-by: Sean Cross <[email protected]>
|
|
When BOARD=fomu, use the riscv cross-compiler. Otherwise, use the
default arm compiler. This can be overridden by passing
CROSS_COMIPLE on the command line.
Note that there are now three common risc-v prefixes:
- riscv32-unknown-elf- : Common for users who compile their own
- riscv64-unknown-elf- : Upstream multiarch toolchain from SiFive
- riscv-none-embed- : xPack embedded version of SiFive toolchain
Here we assume users are using the `riscv-none-embed-` toolchain from
xPack, because it appears to be growing more common. Additionally,
there is much confusion surrounding `riscv64-unknown-elf-`, which
actually includes both 32- and 64-bit runtimes and can generate software
for both.
Signed-off-by: Sean Cross <[email protected]>
|
|
This toolchain seems popular in the embedded space, and is generally
preferred over the upstream SiFive toolchain. It can produce both
32- and 64-bit binaries, so its prefix is riscv-none-embed-.
Signed-off-by: Sean Cross <[email protected]>
|
|
Use the name `valentyusb` as the vendor for the `valentyusb`
project, rather than the manufacturer name of the Fomu device.
This is because the `valentyusb` core can be used across multiple
vendors, much like how other cores can be used across chip vendors.
Signed-off-by: Sean Cross <[email protected]>
|
|
While Fomu is produced by Foosn, the actual name of the hardware
block is `valentyusb`. Rename the module to match that.
Signed-off-by: Sean Cross <[email protected]>
|
|
This gates the majority of the debug and logging features behind
testable macros.
Signed-off-by: Sean Cross <[email protected]>
|
|
This appears to be stable, and works well.
Signed-off-by: Sean Cross <[email protected]>
|
|
Signed-off-by: Sean Cross <[email protected]>
|
|
Signed-off-by: Sean Cross <[email protected]>
|
|
THis bit isn't used anymore, so remove it.
Signed-off-by: Sean Cross <[email protected]>
|
|
Now that we have the `USB_NEXT_EV` register, take advantage of
it to work around issue #207.
Signed-off-by: Sean Cross <[email protected]>
|
|
The Fomu bitstream now includes a `USB_NEXT_EV` register to
indicate which is the next logical event to process. Add this
register to the CSR definition.
Signed-off-by: Sean Cross <[email protected]>
|
|
Signed-off-by: Sean Cross <[email protected]>
|
|
Signed-off-by: Sean Cross <[email protected]>
|
|
Signed-off-by: Sean Cross <[email protected]>
|
|
Signed-off-by: Sean Cross <[email protected]>
|
|
This is able to transfer lots of data back and forth across MSC.
Signed-off-by: Sean Cross <[email protected]>
|
|
Signed-off-by: Sean Cross <[email protected]>
|
|
Signed-off-by: Sean Cross <[email protected]>
|
|
This simply executes an "ebreak" instruction.
Signed-off-by: Sean Cross <[email protected]>
|
