betrusted-io / betrusted-soc Goto Github PK

This is likely a known issue, but in any case: I was trying to recursively clone the current master branch (3ea245d) but it misses some repositories, which are either private or non-existent:

$ git clone https://github.com/betrusted-io/betrusted-soc.git
$ cd betrusted-soc
$ git submodule init
$ git submodule update --init --recursive
…
Submodule 'litex/data/cpu/vexriscv/verilog/ext/VexRiscv' (https://github.com/betrusted-io/VexRiscv.git) registered for path 'deps/pythondata-cpu-vexriscv/pythondata_cpu_vexriscv/verilog/ext/VexRiscv'
Cloning into '/home/odroid/boards/betrusted/betrusted-soc/deps/pythondata-cpu-vexriscv/pythondata_cpu_vexriscv/verilog/ext/VexRiscv'...
Submodule path 'deps/pythondata-cpu-vexriscv/pythondata_cpu_vexriscv/verilog/ext/VexRiscv': checked out '1fe75962036140413d99f7dc9b948b347b10d333'
Submodule 'src/test/resources/VexRiscvRegressionData' (https://github.com/betrusted-io/VexRiscvRegressionData.git) registered for path 'deps/pythondata-cpu-vexriscv/pythondata_cpu_vexriscv/verilog/ext/VexRiscv/src/test/resources/VexRiscvRegressionData'
Cloning into '/home/odroid/boards/betrusted/betrusted-soc/deps/pythondata-cpu-vexriscv/pythondata_cpu_vexriscv/verilog/ext/VexRiscv/src/test/resources/VexRiscvRegressionData'...
Username for 'https://github.com': 
Password for 'https://github.com': 

remote: Repository not found.
fatal: Authentication failed for 'https://github.com/betrusted-io/VexRiscvRegressionData.git/'
fatal: clone of 'https://github.com/betrusted-io/VexRiscvRegressionData.git' into submodule path '/home/odroid/boards/betrusted/betrusted-soc/deps/pythondata-cpu-vexriscv/pythondata_cpu_vexriscv/verilog/ext/VexRiscv/src/test/resources/VexRiscvRegressionData' failed
Failed to clone 'src/test/resources/VexRiscvRegressionData'. Retry scheduled
Cloning into '/home/odroid/boards/betrusted/betrusted-soc/deps/pythondata-cpu-vexriscv/pythondata_cpu_vexriscv/verilog/ext/VexRiscv/src/test/resources/VexRiscvRegressionData'...
Username for 'https://github.com': Password for 'https://github.com': 

remote: Repository not found.
fatal: Authentication failed for 'https://github.com/betrusted-io/VexRiscvRegressionData.git/'
fatal: clone of 'https://github.com/betrusted-io/VexRiscvRegressionData.git' into submodule path '/home/odroid/boards/betrusted/betrusted-soc/deps/pythondata-cpu-vexriscv/pythondata_cpu_vexriscv/verilog/ext/VexRiscv/src/test/resources/VexRiscvRegressionData' failed
…
fatal: repository 'https://git.llvm.org/git/compiler-rt/' not found
fatal: clone of 'https://git.llvm.org/git/compiler-rt' into submodule path '/home/odroid/boards/betrusted/betrusted-soc/deps/rom-locate/deps/litex/litex/soc/software/compiler_rt' failed
Failed to clone 'litex/soc/software/compiler_rt'. Retry scheduled
Cloning into '/home/odroid/boards/betrusted/betrusted-soc/deps/rom-locate/deps/litex/litex/soc/software/compiler_rt'...
fatal: repository 'https://git.llvm.org/git/compiler-rt/' not found
fatal: clone of 'https://git.llvm.org/git/compiler-rt' into submodule path '/home/odroid/boards/betrusted/betrusted-soc/deps/rom-locate/deps/litex/litex/soc/software/compiler_rt' failed
Failed to clone 'litex/soc/software/compiler_rt' a second time, aborting
Submodule path 'deps/rom-locate/deps/migen': checked out 'e2e6c726c9c34209cd326d0a80df63668285a378'
Failed to recurse into submodule path 'deps/rom-locate/deps/litex'
Submodule path 'deps/valentyusb': checked out '89ec5c8db68d52a69b3dde00a6b869850dbf37a4'
Submodule path 'fw/curve25519-dalek': checked out '2a1aaa72e88248f83d06afd064cac0dfc093857f'
Submodule path 'fw/embedded-graphics': checked out 'c58e96a39d45f6ca5c5b13da2c671a36ba2db2cc'
Submodule path 'fw/engine25519-as': checked out '63271299e47b40303461259c2555b76d6b0dddad'
Submodule path 'fw/x25519-dalek': checked out '6c4684b473a286235e5f4d9ca31272ae372839f2'
Failed to recurse into submodule path 'deps/pythondata-cpu-vexriscv'
Failed to recurse into submodule path 'deps/rom-locate'

LiteX provides a S7MMCM that could simplify the CRG and would compute automatically the MMCME2_ADV's parameters from specified input/outputs. It also has DRP support.

An example of use: https://github.com/enjoy-digital/litex/blob/master/litex/boards/targets/arty.py#L35-L42

Is it something you would like to use? I'm happy to create a pull request if so.

It would be good to have the system reboot itself if it locks up, or if something goes really wrong.

Just a reminder to try the new/improved readpac32 macro before committing to one version or the other.

i have trouble using the hardware JTAG interface over the Raspberry Pi Debug HAT after the system is fully booted: the JTAG programmer reports

TDO seems to be stuck at 1

i think the GPIO/retrospective JTAG interface in the SoC interferes with the external programmer, the GPIO JTAG preventing the external programmer from properly driving the TCK/TMS/TDI signals.

(if i repeatedly reboot the precursors board, then there are short time windows during the bootup when the external JTAG programmer works - when the PROG pin is not driven anymore, but the FPGA is not yet programmed / the GPIO JTAG outputs are not yet driven.)

could you add support for putting the SoC's GPIO/retrospective JTAG pins into HIGZ?

if this is part of the in-depth defense (to make tinkering over JTAG more difficult), than an accompanying xous command to activate it would also be useful (e.g. jtag highz). running any other JTAG commands (e.g. jtag dna) could start driving the JTAG signals again.

once the hardware is in, I'm going to need help configuring this correctly with the right scripts, hooks and security ...

need to get some CI testing going

Might be of interest for this project: https://plundervolt.com/ (the culprit seems to be also, that the data are not encrypted in memory, but just during all transfers).

The system cannot actually be powered off while VBUS is active (plugged into a charger) (this is a feature not a bug).

However, we do create the "illusion" of being powered down in this state by cycling the screen into a UI state that reflects powered off. The power system needs to be refactored to also come out of power-down while plugged in (at the moment, it gets stuck in a screen-off UI state gutter, so the fix is probably just scanning the power-on key while in the power-off state and resetting the power bits when the power-on key is detected).

When I run python3 ./betrusted_soc.py on my machine I get this error:

INFO:SoCIRQHandler:usbdev IRQ added at Location 19. Traceback (most recent call last): File "./betrusted_soc.py", line 2197, in <module> ret = main() File "./betrusted_soc.py", line 2109, in main soc = BetrustedSoC(platform, args.revision, xous=args.xous, usb_type=args.usb_type, uart_name=uart_name, bios_path=None, app_uart=args.app_uart) File "./betrusted_soc.py", line 1843, in __init__ self.submodules.usb = dummyusb.DummyUsb( TypeError: __init__() got an unexpected keyword argument 'burst'

I have pip installed all the python dependencies in the README.md. How can I debug this further?

I assume this is out of scope for now, and it may be more appropriate bundled in the other crypto issue...

Alongside edd25519, certain cryptocurrencies require secp256k1 also to peform adequately. Grin for example, which is arguably the most cypherpunk currency with core value of maximum simplicity, and original code was written entirely in rust, needs secp256k1.

after issue #20 is completed, set up CI to run the simulations so we can have regressions on the IP.

At the very least, we should smoke-test that the IP simulations build, and we can dump the wavefrom files as artifacts that we can review later on.

Down the road, we can consider introducing automated feature extraction to determine if the blocks work, but at the moment, we're typically relying on human judgment to review the results of the wavefrom files to confirm 100% functionality of the IP.

TRNG interface should have a FIFO, so that burst requests can be met quickly, and attempts to get TRNGs when the pool is exhausted fail appropriately.

In the process of this refactoring, a second FIFO should also be added that will be made private to the kernel in its own 4k page, and this FIFO will have priority on TRNG pool.

I came across your presentation for 36C3 and was wondering if you started working on TRNG and crypto cores:

I couldn't find anything related to that in betrusted-io repos. I am currently working on PUFs and TRNGs hobby-grade cores for the ECP5 using Migen/LiteX and would be interested in your approach.

As a side node, are you aware of the new CrossLink-NX FPGA from Lattice? If you are unhappy with prjxray this should significantly lower the power consumption compared to the ECP5 and @daveshah1 mentioned on Twitter that the architecture and bitstream was very similar to ECP5. In fact, he already started working on prjoxide.

Build a pipeline that:

• builds betrusted-soc Python & verilog
• builds the Xous kernel and creates a ROM image
• boots the Xous kernel in xvlog and dumps state after transition to user mode

See commit 935f3a0

Page read burst length should be 16 according to the datasheet, but we're only getting stable operation with a length of 4 in practice.

Marking as enhancement because the system works with length 4, but we are missing some potential cache read performance by having it shorter than a cache line length.

IP simulations are betrusted-independent.

If we split sim/ to a separate repo we can do CI integration on the IP more easily.

This may also require submoduling the IP for betrusted (as shared by the EC and SOC).

Initial code tests integrating the dirty bit feature of the memlcd.py driver into hal_lcd.rs did not go as expected. Not a show-stopper but something to look into down the road.

COM bus instability was noted on an instance of the EC-SOC link with a particular routing seed.

• Make the outside-facing registers of the COM block ODDR2/IDDR2 so that all fabric routing delays are eliminated.
• Review the EC for opportunities to tighten up the timing loop, and see if nextpnr/yosys has introduced options yet for I/O timing constraints since the block was written.
• consider reducing the clock rate of the COM bus.

Just checked the datasheet, and to guarantee atomicity of time during a read or write, time needs to be updated as a single block I2C access and not several separate I2C accesses, or else you may get e.g. seconds from one quanta and minutes from another.

In the current design, all timing constraints are defined manually. Vivado (and open-source tools like NextPnr) are able to propagate constraints through clocking primitives and generate the output constraints automatically for most use-cases. Defining all constraints manually is of course valid but makes things difficult to change/maintain. Is it something wanted? Or would you be happy with a pull request that let the tool derivate automatically more timing constraints and only provide the useful ones?

Hi there!

I wanted to generate the SoC with LiteX, but am getting recursive clone errors for a enjoy-digital/black-parrot repository:

git clone --recurse-submodules https://github.com/betrusted-io/betrusted-soc.git
...
Username for 'https://github.com': 
Password for 'https://github.com': 
remote: Repository not found.
fatal: Authentication failed for 'https://github.com/enjoy-digital/black-parrot.git/'
fatal: clone of 'https://github.com/enjoy-digital/black-parrot.git' into submodule path '/home/blake/src/betrusted-soc/deps/rom-locate/deps/litex/litex/soc/cores/cpu/blackparrot/pre-alpha-release' failed
Failed to clone 'litex/soc/cores/cpu/blackparrot/pre-alpha-release'. Retry scheduled

Can someone help resolve? Thanks! Been enjoying playing and hacking on my Precursor so far. 👍

EDIT: Looks like compiler-rt is having similar issues, though it seems to be stuck in some redirect loop:

Cloning into '/home/blake/src/betrusted-soc/deps/rom-locate/deps/litex/litex/soc/software/compiler_rt'...
fatal: unable to access 'https://git.llvm.org/git/compiler-rt/': Maximum (20) redirects followed
fatal: clone of 'https://git.llvm.org/git/compiler-rt' into submodule path '/home/blake/src/betrusted-soc/deps/rom-locate/deps/litex/litex/soc/software/compiler_rt' failed
Failed to clone 'litex/soc/software/compiler_rt'. Retry scheduled

LCD_FB is hard coded to a memory location inside hal_lcd.rs:

There is probably a way to reference the linker symbol _lcdfb in a Rust-y fashion but I can't seem to find one that doesn't also cause the RLS on VScode to barf immediately.