im-tomu / foboot Goto Github PK

View Code? Open in Web Editor NEW

99.0 99.0 32.0 6 MB

Bootloader for Fomu

License: Apache License 2.0

Verilog 35.99% Python 7.71% C 55.07% Makefile 0.70% Assembly 0.41% Shell 0.12%

foboot's People

Contributors

Stargazers

Watchers

foboot's Issues

Issue building new updater -- Unable to open booster.bin

Please let me know if I missed a step. This is what I ran:

cd hw
python3 foboot-bitstream.py --revision pvt --seed 19

cd ../booster
cc -O2 -o make-booster -I ./include make-booster.c

cd ../releases
bash ./release.sh pvt

With the last step, I get this error:

+++ dirname ./release.sh
++ cd ./..
++ pwd
+ root=/home/tim/fomu/foboot
+ platform=pvt
+ input=/home/tim/fomu/foboot/hw/build
+ '[' -z pvt ']'
+ '[' pvt = evt ']'
+ '[' pvt = evt-spi ']'
+ '[' pvt = pvt ']'
+ spi_id=0xc2152815
+ cd /home/tim/fomu/foboot
++ git describe --tags --dirty=+
+ release=v2.0.3-53-gaf4d063+
+ output=/home/tim/fomu/foboot/releases/v2.0.3-53-gaf4d063+
+ mkdir -p /home/tim/fomu/foboot/releases/v2.0.3-53-gaf4d063+
+ cp /home/tim/fomu/foboot/hw/build/gateware/top.bin /home/tim/fomu/foboot/releases/v2.0.3-53-gaf4d063+/pvt-foboot-v2.0.3-53-gaf4d063+.dfu
+ cp /home/tim/fomu/foboot/hw/build/gateware/top-multiboot.bin /home/tim/fomu/foboot/releases/v2.0.3-53-gaf4d063+/pvt-multiboot-v2.0.3-53-gaf4d063+.bin
+ cp /home/tim/fomu/foboot/hw/build/software/bios/bios.elf /home/tim/fomu/foboot/releases/v2.0.3-53-gaf4d063+/pvt-bios-v2.0.3-53-gaf4d063+.elf
+ cp /home/tim/fomu/foboot/hw/build/software/include/generated/csr.h /home/tim/fomu/foboot/releases/v2.0.3-53-gaf4d063+/pvt-csr-v2.0.3-53-gaf4d063+.h
+ cp /home/tim/fomu/foboot/hw/build/software/include/generated/soc.h /home/tim/fomu/foboot/releases/v2.0.3-53-gaf4d063+/pvt-soc-v2.0.3-53-gaf4d063+.h
+ cd /home/tim/fomu/foboot/booster
+ ./make-booster 0xc2152815 /home/tim/fomu/foboot/hw/build/gateware/top-multiboot.bin /home/tim/fomu/foboot/releases/v2.0.3-53-gaf4d063+/pvt-updater-v2.0.3-53-gaf4d063+.dfu
Unable to open booster.bin (try running 'make'): No such file or directory

Support metadata like the TinyFPGA Bootloader

It would be good to support / have the same style of board metadata that the TinyFPGA board does.

See below;

FPGA Board Metadata

Each FPGA board implementing the TinyFPGA USB Bootloader may have different locations for the bootloader image, user image, user data, and other information. These differences are driven by the FPGA's multi-boot capabilities/requirements and the size of the FPGA configuration image.

In order for a common bootloader and programmer application to program user images and user data to the correct locations, the programmer must know where these locations are in the SPI flash. It is also useful to identify the board with a name and unique serial number. This information along with other required and optional metadata is stored in the non-volatile security register pages of the SPI flash and optionally in the main SPI flash memory.

The programmer application will search security register pages 0-3 for valid metadata. The metadata is stored in JSON format. JSON was choosen because it is compact enough, is well understood, and easier to read and understand than a binary format.

Below is an example of how the metadata may be structured and formatted for the TinyFPGA BX board:

SPI Flash Security Register Page 1 (write-protected)

One of the SPI flash security register pages contains fixed data about the board that does not change. This is the name of the board, the hardware revision of the board, and serial number unique to the board name. This security register page should be write protected as it should never be changed. If the rest of the SPI flash is erased, this minimal amount of information will help the user to find recovery instructions.
{"boardmeta":{
  "name": "TinyFPGA BX",
  "fpga": "ice40lp8k-cm81",
  "hver": "1.0.0",
  "serial": 10034
}}
SPI Flash Security Register Page 2 (not write-protected)

A seperate SPI flash security register page should contain or point to information that can change. This includes the bootloader version number, update URL for new bootloader releases for this board, and an address map for the SPI flash that describes where the bootloader, user image, and user data belong. Using this information the programmer application is able to discover where to put new user images and data without any input from the user or built-in knowledge about the board. It makes the board plug-and-play.

Optionally, an additional desc.tgz file may be included in the SPI flash itself, or on the update page. This desc.gz file contains the information necessary to develop with the board. At a minimum it describes the FPGA name, package, and a mapping from FPGA pins to board IOs and peripherals.
{"bootmeta": "@0xFF000+445"}
SPI Flash Memory Address 0xFF000
{
  "bootloader": "TinyFPGA USB Bootloader",
  "bver": "2.0.0",
  "update": "https://tinyfpga.com/update/tinyfpga-bx",
  "addrmap": {
    "bootloader": "0x00000-0x2FFFF",
    "userimage":  "0x30000-0x4FFFF",
    "userdata":   "0x50000-0xFBFFF",
    "desc.tgz":   "0xFC000-0xFFFFF"
  }
}
A detailed explanation of the metadata structure will be added here.

Fix RGB LED ordering

Both hacker and production boards have different LED mappings, and both are "incorrect". For example:

    rgb_write(r, LEDDPWRG); // Red
    rgb_write(g, LEDDPWRB); // Green
    rgb_write(b, LEDDPWRR); // Blue

All platforms should have a consistent LED ordering, and the LEDD block should be mapped as you'd expect.

RAM load doesn't work for me

@swillner am I doing something wrong here?

I can't get RAM load to work. I'm building examples/riscv-blink with make LOAD_RAM_ADDR=0x10001000, and loading it with dfu-util -D riscv-blink.dfu. The first bytes of the .elf look good:

10001000 <_ftext>:
10001000:       23c0006f                j       1000123c <crt_init>
10001004:       17ab0f23                sb      s10,382(s6)
10001008:       1000                    addi    s0,sp,32
1000100a:       1000                    addi    s0,sp,32

When I try to load it, the fomu gets stuck in the write phase (rapid blue blinking) with this message from dfu-util:

Download        [                         ]   0%            0 bytesError during download get_status

or, dfu-util says it finished but the fomu is in the red error blinking mode.

I've tried it with different fomu and different foboot versions (v2.0.2, v2.0.3, and v2.0.3-55-ge928b86).

fomu can be be bricked by flashing too large of an image

Summary

Issue: Flashing a large file (4MB) with dfu-utilwill brick fomu.

Recommendation: Cut a new release of foboot.

This issue has already been fixed in master (e76d5f9), but the fix is not included in the current release (v2.0.3).

Details

I encountered this when I built a version of micropython with a different toolchain that resulted in an erroneously large binary. Upon flashing my fomu became unresponsive (e.g. no lights, no dfu).

The following describes reproducing the issue to confirm:

Before

Tested using fomu-pvt running foboot v2.0.2 (v2.0.3 does not have any changes that would impact this behavior).

[Nov24 09:58] usb 2-1: new full-speed USB device number 7 using xhci_hcd
[  +0.151663] usb 2-1: New USB device found, idVendor=1209, idProduct=5bf0, bcdDevice= 1.01
[  +0.000012] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000005] usb 2-1: Product: Fomu PVT running DFU Bootloader v2.0.2
[  +0.000003] usb 2-1: Manufacturer: Foosn

$ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [1209:5bf0] ver=0101, devnum=7, cfg=1, intf=0, path="2-1", alt=0, name="Fomu PVT running DFU Bootloader v2.0.2", serial="UNKNOWN"

Build and flash a BAD binary (too large)

script to create a patterned flash image, to allow easy identification of offsets.

#!/usr/bin/env python3

SZ = (4096 * 1024)//4

with open('BAD.flash-pattern.dfu', 'wb') as out:
    for b in range(SZ):
        out.write(b.to_bytes(4, byteorder='big'))

produces a 4MB file

$ ls -al BAD.flash-pattern.dfu
-rw-r--r-- 1 r r 4194304 Nov 24 10:03 BAD.flash-pattern.dfu

WARNING running this commands will BRICK your fomu. You will NOT be able to recover over usb.

$ dfu-util -D BAD.flash-pattern.dfu
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1209:5bf0
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0101
Device returned transfer size 4096
Copying data from PC to DFU device
Download        [=========================] 100%      4194304 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!

fomu flashes red and is non-responsive to dfu-util.

After unplugging and replugging still non-responsive

[Nov24 10:07] usb 2-1: USB disconnect, device number 7
[Nov24 10:08] usb 2-1: new full-speed USB device number 8 using xhci_hcd
[  +0.127932] usb 2-1: device descriptor read/64, error -71
[  +0.236052] usb 2-1: device descriptor read/64, error -71
[  +0.236020] usb 2-1: new full-speed USB device number 9 using xhci_hcd
[  +0.127964] usb 2-1: device descriptor read/64, error -71
[  +0.236062] usb 2-1: device descriptor read/64, error -71
[  +0.108050] usb usb2-port1: attempt power cycle
[  +0.411921] usb 2-1: new full-speed USB device number 10 using xhci_hcd
[  +0.000293] usb 2-1: Device not responding to setup address.
[  +0.207896] usb 2-1: Device not responding to setup address.
[  +0.207805] usb 2-1: device not accepting address 10, error -71
[  +0.127910] usb 2-1: new full-speed USB device number 11 using xhci_hcd
[  +0.000152] usb 2-1: Device not responding to setup address.
[  +0.208152] usb 2-1: Device not responding to setup address.
[  +0.207762] usb 2-1: device not accepting address 11, error -71
[  +0.000054] usb usb2-port1: unable to enumerate USB device

When connecting directly to the SPI and using fomu flash, you can confirm that the flash "wrapped" around and clobbered the low bytes of the SPI. The resulting overwrite corresponds to offset 0x003c0000 in BAD.flash-pattern.dfu

$ sudo ./fomu-flash/fomu-flash -p 0
00000000 00 0f 00 00 00 0f 00 01  00 0f 00 02 00 0f 00 03  |................|
00000010 00 0f 00 04 00 0f 00 05  00 0f 00 06 00 0f 00 07  |................|
00000020 00 0f 00 08 00 0f 00 09  00 0f 00 0a 00 0f 00 0b  |................|

Expected Behavior

When using a foboot build from 882ce04 the expected behavior occurs and you are prevented from flashing (using dfu-util) a payload that is too large

$ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [1209:5bf0] ver=0101, devnum=29, cfg=1, intf=0, path="2-1", alt=0, name="Fomu PVT running DFU Bootloader v2.0.3-57-g882ce04", serial="UNKNOWN"

$ dfu-util -D BAD.flash-pattern.dfu
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1209:5bf0
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0101
Device returned transfer size 4096
Copying data from PC to DFU device
Download        [=======                  ]  30%      1294336 bytes failed!
state(10) = dfuERROR, status(8) = Cannot program memory due to received address that is out of range

fomu continues to operate as usual.

Add support for tinyfpga-bx board

It would be good to replace the tinyfpga-bx bootloader with foboot.

Can't seem to update my Fomu

Windows10

As I got it, dfu-util -l says

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Cannot open DFU device 2972:0047
Cannot open DFU device 2972:0047
Found DFU: [1209:5bf0] ver=0101, devnum=3, cfg=1, intf=0, path="2-1.4", alt=0, name="Fomu PVT running DFU Bootloader v1.9.1", serial="UNKNOWN"

I then try to update it

dfu-util -D F:\downloads\pvt-updater-v2.0.3.dfu

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2019 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 1209
Match product ID from file: 70b1
Opening DFU capable USB device...
ID 1209:5bf0
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0101
Device returned transfer size 1024
Copying data from PC to DFU device
Download        [=========================] 100%       112828 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!

I see no rainbow colours, but when I run dfu-utl -l again:

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2019 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Cannot open DFU device 2972:0047
Cannot open DFU device 2972:0047
Found DFU: [1209:5bf0] ver=0101, devnum=3, cfg=1, intf=0, path="2-1.4", alt=0, name="Fomu PVT running DFU Bootloader v2.0.3", serial="UNKNOWN"

All seems good. However, if I unplug and then put back into the USB, it seems to have reverted

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2019 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Cannot open DFU device 2972:0047
Cannot open DFU device 2972:0047
Found DFU: [1209:5bf0] ver=0101, devnum=3, cfg=1, intf=0, path="2-1.4", alt=0, name="Fomu PVT running DFU Bootloader v1.9.1", serial="UNKNOWN"```


Any idea what is going on?

Missing .dfu for hacker board in v1.8.1 release

In the foboot/releases/v1.8.1 directory, there are .dfu files for the evt and pvt boards, but not for the hacker board.

Rework code in SBLED so LED information is in the platform

Currently the SBLED has the following horrible hack;

foboot/hw/foboot-bitstream.py

Lines 343 to 360 in a4a3dad

    
           if revision == "pvt" or revision == "evt" or revision == "dvt": 
        
               self.comb += [ 
        
                   If(self.ctrl.storage[3], rgba_pwm[1].eq(self.raw.storage[0])).Else(rgba_pwm[1].eq(ledd_value[0])), 
        
                   If(self.ctrl.storage[4], rgba_pwm[0].eq(self.raw.storage[1])).Else(rgba_pwm[0].eq(ledd_value[1])), 
        
                   If(self.ctrl.storage[5], rgba_pwm[2].eq(self.raw.storage[2])).Else(rgba_pwm[2].eq(ledd_value[2])), 
        
               ] 
        
           elif revision == "hacker": 
        
               self.comb += [ 
        
                   If(self.ctrl.storage[3], rgba_pwm[2].eq(self.raw.storage[0])).Else(rgba_pwm[2].eq(ledd_value[0])), 
        
                   If(self.ctrl.storage[4], rgba_pwm[1].eq(self.raw.storage[1])).Else(rgba_pwm[1].eq(ledd_value[1])), 
        
                   If(self.ctrl.storage[5], rgba_pwm[0].eq(self.raw.storage[2])).Else(rgba_pwm[0].eq(ledd_value[2])), 
        
               ] 
        
           else: 
        
               self.comb += [ 
        
                   If(self.ctrl.storage[3], rgba_pwm[0].eq(self.raw.storage[0])).Else(rgba_pwm[0].eq(ledd_value[0])), 
        
                   If(self.ctrl.storage[4], rgba_pwm[1].eq(self.raw.storage[1])).Else(rgba_pwm[1].eq(ledd_value[1])), 
        
                   If(self.ctrl.storage[5], rgba_pwm[2].eq(self.raw.storage[2])).Else(rgba_pwm[2].eq(ledd_value[2])), 
        
               ]

What should be done is that the "platform" should define the RGB and rgb0/rgb1/rgb2 relationship and the SBLED should just ask which one is the red/green/blue.

Add platform abstraction layer to parameterise for different platforms

Need to be able to parameterise the software to allow the same s/w binary to run on different platforms.

An incomplete list would be

USB PID/VID
FPGA bitstream header used to search for valid images
LED capabilites
User input capabilities (touch vs. button)

Some/all of this could come from a litex platform capabilities mechanism.

dfu detach not required to start program

According to the readme a dfu-util -e has to be executed after downloading an image to start the new bitstream.

In my experience, running the riscv-blink on a fomu hacker board the program immediately starts execution after dfu download is complete.

Running Fomu DFU Bootloader v1.7.3-1-g82cb20c and dfu util v0.8 on Ubuntu.

Can someone explain me where in the bootloader the reset is executed after download?

Move to litex defined fomu platform

I'm just starting to learn litex, seems like somewhere there must be a platform defined for fomu that this can just use. If there isn't we should create one.

These seem like fairly simple tasks, I'd be happy to take this on.

Figure out how to unfork from litex-buildenv

It would be good to get foboot and litex-buildenv back into a similar and/or closer platform.

tinyusb examples don't seem to work with current head of master (e928b868)

tinyusb/examples/device/cdc_dual_ports doesn't seem to work with the foboot updater that I build at current master head, e928b86.

The tinyusb examples work with the foboot 2.0.3 release. Also, I checked out c9571b5 and rebuild myself to make sure it wasn't something in my build environment. That worked with the tinyusb examples as well.

I'm filing this so I have a place to record my findings if I get time to do any bisection of the CLs.

Booting from RAM

@xobs I was recently working on a support for foboot in Renode. The current master, available on github supports Fomu platform capable of running foboot and booting software uploaded from host using dfu-util. The setup requires exporting virtual fomu device from Renode to the host system using USB/IP and from that moment on you interact with it the same way as with the real board.

During my adventure I tested two scenarios:

downloading software to the flash (works fine),
downloading it directly to RAM (had some problems).

As I understood from the sources, in order to direct the image to the RAM memory it must begin with a magic sequence followed by the address where this image should be stored.
What makes me wonder is that the whole image, inluding the magic sequence and the address, is written to RAM and then on reboot the CPU starts from it.

It seems to me that the first instruction CPU executes after reboot is the magic sequence. Shouldn't the start address be shifted by 8 to skip the metadata?

Auto-boot image after 5 seconds

There have been a few requests (im-tomu/fomu-workshop#52) to auto-start the current program if no data has been received after 5 seconds.

Needs better instructions for loading the bootloader

If you're not using fomu-flash there're no instructions for building a dfu-util-loadable image and loading it.

Instability seen with some Fomu with v2.0.3

With some (not all, maybe about 50%) of Fomu I've used, I see the following symptom when release v2.0.3 foboot has been installed, some but not all of the time:

$ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2019 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Failed to retrieve string descriptor 2
Found DFU: [1209:5bf0] ver=0101, devnum=86, cfg=1, intf=0, path="1-2.2", alt=0, name="UNKNOWN", serial="UNKNOWN"

The last line should be

Found DFU: [1209:5bf0] ver=0101, devnum=86, cfg=1, intf=0, path="1-2.2", alt=0, name="Fomu PVT running DFU Bootloader v2.0.3", serial="UNKNOWN"

Also, sometimes there is a noticeable pause before the reply comes back for dfu-util -l.

The good news: I have only observed this with v2.0.3. With v2.0.2, I see dependable behavior always returning the correct "name" string. Also, with recent head of master (and with my change back to 8b csr bus), it also works dependably.

string.h: No such file or directory

Hello,

I am unable to build the hw, I am running:

~/Projects/ice50/foboot/hw$ python3 foboot-bitstream.py --revision pvt --seed 19
...
INFO:SoC:--------------------------------------------------------------------------------
INFO:SoCBusHandler:Interconnect: InterconnectShared (2 <-> 4).
make: Entering directory '/storage/Projects/ice50/foboot/hw/build/software/bios'
  CC       ../../../../sw/src/dfu.c	dfu.o
../../../../sw/src/dfu.c:25:10: fatal error: string.h: No such file or directory
   25 | #include <string.h>
      |          ^~~~~~~~~~
compilation terminated.
make: *** [/storage/Projects/ice50/foboot/sw/Makefile:124: .obj/dfu.o] Error 1
make: Leaving directory '/storage/Projects/ice50/foboot/hw/build/software/bios'
Traceback (most recent call last):
  File "/storage/Projects/ice50/foboot/hw/foboot-bitstream.py", line 575, in <module>
    main()
  File "/storage/Projects/ice50/foboot/hw/foboot-bitstream.py", line 549, in main
    vns = builder.build(build_name="top")
  File "/storage/Projects/ice50/foboot/hw/deps/litex/litex/soc/integration/builder.py", line 212, in build
    self._generate_rom_software(not self.soc.integrated_rom_initialized)
  File "/storage/Projects/ice50/foboot/hw/deps/litex/litex/soc/integration/builder.py", line 192, in _generate_rom_software
    subprocess.check_call(["make", "-C", dst_dir, "-f", makefile])
  File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['make', '-C', '/storage/Projects/ice50/foboot/hw/build/software/bios', '-f', '/storage/Projects/ice50/foboot/sw/Makefile']' returned non-zero exit status 2.

I tried using picolibc:

diff --git a/sw/Makefile b/sw/Makefile
index 1c86a5b..8593cc2 100644
--- a/sw/Makefile
+++ b/sw/Makefile
@@ -25,7 +25,7 @@ ifeq ($(LITEX),1)
 BASE_DIR   := ../../../../sw
 LDSCRIPT   := $(BASE_DIR)/ld/linker.ld
 LD_DIR     := ../include/generated
-ADD_CFLAGS := -I../include -I$(BASE_DIR)/include
+ADD_CFLAGS := -I../include -I$(BASE_DIR)/include -I/usr/lib/picolibc/riscv64-unknown-elf/include
 ADD_LFLAGS := 
 PACKAGE    := bios
 else

but it seems it doesn't fit:

  CC       ../../../../sw/third_party/libbase/qsort.c	qsort.o
  CC       ../../../../sw/third_party/libbase/time.c	time.o
  CC       ../../../../sw/third_party/libbase/uart.c	uart.o
  LD       bios.elf
/usr/lib/riscv64-unknown-elf/bin/ld: section .srodata.landing_url_descriptor LMA [0000000000001a6c,0000000000001a7a] overlaps section .data LMA [0000000000001a6c,0000000000001a73]
collect2: error: ld returned 1 exit status
make: *** [/storage/Projects/ice50/foboot/sw/Makefile:98: bios.elf] Error 1
make: Leaving directory '/storage/Projects/ice50/foboot/hw/build/software/bios'
Traceback (most recent call last):
  File "/storage/Projects/ice50/foboot/hw/foboot-bitstream.py", line 575, in <module>
    main()
  File "/storage/Projects/ice50/foboot/hw/foboot-bitstream.py", line 549, in main
    vns = builder.build(build_name="top")
  File "/storage/Projects/ice50/foboot/hw/deps/litex/litex/soc/integration/builder.py", line 212, in build
    self._generate_rom_software(not self.soc.integrated_rom_initialized)
  File "/storage/Projects/ice50/foboot/hw/deps/litex/litex/soc/integration/builder.py", line 192, in _generate_rom_software
    subprocess.check_call(["make", "-C", dst_dir, "-f", makefile])
  File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['make', '-C', '/storage/Projects/ice50/foboot/hw/build/software/bios', '-f', '/storage/Projects/ice50/foboot/sw/Makefile']' returned non-zero exit status 2.

How do I fix this?

Add support for ECP5 hardware

It would be good to support ECP5 hardware like the OrangeCrab from @gregdavill and potentially other ECP5 hardware in the future.

Maximum writable file size through dfu

Hi - I am trying to upload a relatively large file (3MB) into a Fomu PVT (concatenating design and data).
I am aware of issue #330 and the fix, however I am unsure about the maximum size limit:

the 2.0.4 release message mentions 4MB
the dfu upload stops after 1306624 bytes
the code sets a 1.5MB limit (

foboot/sw/src/dfu.c

Line 40 in d9a72a8

#define FLASH_MAX_ADDR ((1024 * 1024) + (1024 * 512)) // 1.5 MB max

)
the flash layout says flash ends at 2MB (https://github.com/im-tomu/foboot/blob/master/doc/FLASHLAYOUT.md)

This overall seems to indicate 2MB flash. However, the PVT bom says 128Mbits ( https://github.com/im-tomu/fomu-hardware/tree/master/archive/pvt ) and the release message mentions 4MB? What would be the expected flash size on the PVT? (of course hoping the limit is conservative and there are a few more bytes after it ;) )

Thanks!

Fails to meet timing without specifying a seed

Commit 11f2fa8 broke the build. I see:
ERROR: Max frequency for clock 'clk48_$glb_clk': 44.42 MHz (FAIL at 48.00 MHz)

The commit before this is OK.

I'm using the toolchains from fomu-toolchain-linux_x86_64-v1.5.3

Replace PicoSoC XIP flash controller with LiteX version

Add DFU signature support?

Dfu-util complains with the follow error;

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!

Does foboot need to do anything or just yet code which generates the DFU image?

Can't build - ERROR: Conflicting init values for signal 1'0 (\cpu_interrupt [0] = 1'0 != 1'x).

git log
commit f34d5ffb5ec5a9ca0356516ef4c1d4883f07ac96 (HEAD -> master, origin/master, origin/HEAD)

pyhton3 python3 foboot-bitstream.py --revision pvt

Suffix successfully added to file
Warning: Initial value conflict for \usb_usb_core_response_pid_t_next_value [1] resolving to 1'1 but with init 1'0.
ERROR: Conflicting init values for signal 1'0 (\cpu_interrupt [0] = 1'0 != 1'x).
Traceback (most recent call last):
  File "foboot-bitstream.py", line 475, in <module>
    main()
  File "foboot-bitstream.py", line 450, in main
    vns = builder.build()
  File "/Users/ronaldv/Projects/repositories/foboot/hw/deps/litex/litex/soc/integration/builder.py", line 211, in build
    vns = self.soc.build(build_dir=self.gateware_dir, **kwargs)
  File "/Users/ronaldv/Projects/repositories/foboot/hw/deps/litex/litex/soc/integration/soc.py", line 1045, in build
    return self.platform.build(self, *args, **kwargs)
  File "/Users/ronaldv/Projects/repositories/foboot/hw/deps/litex/litex/build/lattice/platform.py", line 34, in build
    return self.toolchain.build(self, *args, **kwargs)
  File "/Users/ronaldv/Projects/repositories/foboot/hw/deps/litex/litex/build/lattice/icestorm.py", line 202, in build
    _run_script(script)
  File "/Users/ronaldv/Projects/repositories/foboot/hw/deps/litex/litex/build/lattice/icestorm.py", line 133, in _run_script
    raise OSError("Subprocess failed")
OSError: Subprocess failed

Building --no-cpu creates memory overlap

python3 foboot-bitstream.py --revision pvt --no-cpu


INFO:SoC:--------------------------------------------------------------------------------
ERROR:SoCBusHandler:Region overlap between rom and csr:
ERROR:SoCBusHandler:Origin: 0x00000000, Size: 0x00002000, Mode: RW, Cached: True Linker: False
ERROR:SoCBusHandler:Origin: 0x00000000, Size: 0x00010000, Mode: RW, Cached: False Linker: False

Stability after switching to eptri

We were testing Foboot code in the usb-test-suite (see example test output here). Software was so far compiled directly via Makefile in sw folder, which worked fine since headers there corresponded to the epfifo interface.

Recently Foboot master branch switched to eptri. I updated the CSR header manually to those output by foboot_bitstream.py, but host requests are still NAKed. Looking at signal states, it seems that the setuphandler_reset_pending signal is stuck high and the ISR does not reset it.

Is the code in usb-eptri.c stable? Does it work on hardware, or is it still WIP?

Should the Boot Flags have error correction?

The boot flags at https://github.com/im-tomu/foboot/blob/master/doc/BOOT-SEQUENCE.md#boot-flags don't have any error correction. It is unclear if this is a bad thing or not.

Suggestions;

Add parity bit?
Add something which makes it easy to tell the difference between a new - unsupported flag, verse random corruption?
Describe what happens if no valid boot flags are found or that is an incompatible configuration of flags set.

USB fails on hubs without TT

When a hub has no transaction translator, USB relies on the "address" field to determine which device to talk to.

Currently, foboot ignores the "address" field and assumes it's on a switched hub with a transaction translator. Such devices are rare in modern computing, so the workaround is to put Fomu into a downstream hub. However, we should add SET_ADDRESS support to fix these devices.

Add Spartan 6 support

@mithro "I'm very supportive of the idea of having Foboot running on Artix-7 and Spartan-6 FPGA hardware."

I have a few more obscure Spartan 6 boards Papilio Pro and LogiBone. Did you have a preference for supporting a particular board? I'll probably start with my pmod usb board and the logibone unless you have other preferences?

Potential typo bug in foboot/main.c

In the reboot function we have this piece of code:

    if (boot_config & 0x00000002) // DDR_EN
        picorvspi_cfg3_write(picorvspi_cfg3_read() | 0x40);
    if (boot_config & 0x00000002) // CFM_EN
        picorvspi_cfg3_write(picorvspi_cfg3_read() | 0x10);

The comments document different bit names, but the bit is the same (0x2 in both if conditions). This looks like a bug.

[167052.064423] usb 1-2: New USB device found, idVendor=1209, idProduct=5bf0, bcdDevice= 1.01
[167052.064426] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[167052.064427] usb 1-2: Product: Fomu DFU Bootloader v1.8.7
[167052.064428] usb 1-2: Manufacturer: Foosn

It would be good if it said something like

[167052.064423] usb 1-2: New USB device found, idVendor=1209, idProduct=5bf0, bcdDevice= 1.01
[167052.064426] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[167052.064427] usb 1-2: Product: Fomu Hacker running DFU Bootloader v1.8.7
[167052.064428] usb 1-2: Manufacturer: Foosn

[167052.064423] usb 1-2: New USB device found, idVendor=1209, idProduct=5bf0, bcdDevice= 1.01
[167052.064426] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[167052.064427] usb 1-2: Product: Fomu PVT running DFU Bootloader v1.8.7
[167052.064428] usb 1-2: Manufacturer: Foosn

Add 7 series support

I added the 7 series support to TinyFPGA-Bootloader in tinyfpga/TinyFPGA-Bootloader#30

This project seems to make that obsolete, I'd like to move the 7 series work here.

Once #2 is resolved I'd like to tackle making foboot a little more platform independent, separating the arch specific portions etc.

	if revision == "pvt" or revision == "evt" or revision == "dvt":
	self.comb += [
	If(self.ctrl.storage[3], rgba_pwm[1].eq(self.raw.storage[0])).Else(rgba_pwm[1].eq(ledd_value[0])),
	If(self.ctrl.storage[4], rgba_pwm[0].eq(self.raw.storage[1])).Else(rgba_pwm[0].eq(ledd_value[1])),
	If(self.ctrl.storage[5], rgba_pwm[2].eq(self.raw.storage[2])).Else(rgba_pwm[2].eq(ledd_value[2])),
	]
	elif revision == "hacker":
	self.comb += [
	If(self.ctrl.storage[3], rgba_pwm[2].eq(self.raw.storage[0])).Else(rgba_pwm[2].eq(ledd_value[0])),
	If(self.ctrl.storage[4], rgba_pwm[1].eq(self.raw.storage[1])).Else(rgba_pwm[1].eq(ledd_value[1])),
	If(self.ctrl.storage[5], rgba_pwm[0].eq(self.raw.storage[2])).Else(rgba_pwm[0].eq(ledd_value[2])),
	]
	else:
	self.comb += [
	If(self.ctrl.storage[3], rgba_pwm[0].eq(self.raw.storage[0])).Else(rgba_pwm[0].eq(ledd_value[0])),
	If(self.ctrl.storage[4], rgba_pwm[1].eq(self.raw.storage[1])).Else(rgba_pwm[1].eq(ledd_value[1])),
	If(self.ctrl.storage[5], rgba_pwm[2].eq(self.raw.storage[2])).Else(rgba_pwm[2].eq(ledd_value[2])),
	]

im-tomu / foboot Goto Github PK

foboot's People

Contributors

Stargazers

Watchers

Forkers

foboot's Issues

FPGA Board Metadata

SPI Flash Security Register Page 1 (write-protected)

SPI Flash Security Register Page 2 (not write-protected)

SPI Flash Memory Address 0xFF000

Summary

Details

Before

Build and flash a BAD binary (too large)

Expected Behavior

Recommend Projects

Recommend Topics

Recommend Org