Due to an error, we were double-advancing the FIFO buffer. The end
result was that the second half of most reads were getting ignored.
This wasn't found during earlier testing because only 64-byte buffers
were tested.
This corrects this error by avoiding double-advancing the buffer.
Signed-off-by: Sean Cross <sean@xobs.io>
During development, the ROM address was at offset 0x2001a000
(due to the fact that the test program was located immediately
following the bitstream).
In normal Fomus, the ROM address is at offset 0x20040000, in order
to take into account additional bitstreams and bootloaders.
Correct the address to the offset in order to get examples working
with existing Fomus.
Signed-off-by: Sean Cross <sean@xobs.io>
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 <sean@xobs.io>
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 <sean@xobs.io>
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 <sean@xobs.io>
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 <sean@xobs.io>
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 <sean@xobs.io>
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 <sean@xobs.io>
Sean Cross