While the kernel boots in under 30 seconds, it <a href="https://asciinema.org/a/293450

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

It seems my kernel is too big to fit into: <div class="snippet-clipboard-content n

<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clip

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

<a class="user-mention notranslate" data-hovercard-type="user" data-hover

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

FYI - this is the current state: <div class="highlight highlight-source-diff notra

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

boot hadbadge from flash,about litex-hub/litex-boards

Comments (43)

enjoy-digital commented on July 18, 2024 1

@pdp7: just for info, i'm looking at that currently on Arty.

from litex-boards.

pdp7 commented on July 18, 2024

I'm trying to get the Hackaday Badge to boot from the SPI flash as it takes 2 mintues to load the kernel and rootfs over serial.

Repo version:

pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ git log --oneline -1
cab81d5 (HEAD -> master, origin/master, origin/HEAD) sim: use new sdram verbosity parameter

Repo diff:

diff --git a/soc_linux.py b/soc_linux.py
index ecf875b..34105c0 100644
--- a/soc_linux.py
+++ b/soc_linux.py
@@ -104,7 +104,7 @@ def SoCLinux(soc_cls, **kwargs):
 
         def add_spi_flash(self, dummy_cycles):
             # TODO: add spiflash1x support
-            spiflash_pads = self.platform.request("spiflash4x")
+            spiflash_pads = self.platform.request("spiflash")
             self.submodules.spiflash = SpiFlash(
                 spiflash_pads,
                 dummy        = dummy_cycles,

From linux-on-litex-vexriscv/soc_linux.py:

            "emulator_ram": 0x20000000,
            "ethmac":       0xb0000000,
            "spiflash":     0xd0000000,
            "csr":          0xf0000000,
        }}

so we know that 0xd0000000 will be the memory address that represent the contents of flash.

Generating the fbi files:

emulator$ python3 ~/dev/enjoy/litex/build/lib/litex/soc/software/mkmscimg.py -f -o emulator.bin.fbi emulator.bin
emulator$ cd ../buildroot/
buildroot$ python3 ~/dev/enjoy/litex/build/lib/litex/soc/software/mkmscimg.py -f -o rootfs.cpio.fbi rootfs.cpio
buildroot$ python3 ~/dev/enjoy/litex/build/lib/litex/soc/software/mkmscimg.py -f -o Image.fbi Image
buildroot$ python3 ~/dev/enjoy/litex/build/lib/litex/soc/software/mkmscimg.py -f -o rv32.dtb.fbi rv32.dtb

Here is the images.json.fbi:

{
	"buildroot/Image.fbi":        "0x00000000",
	"buildroot/rootfs.cpio.fbi":  "0x00400000",
	"buildroot/rv32.dtb.fbi":     "0x00B00000",
	"emulator/emulator.bin.fbi":  "0x00B01000"
}

However, flashing this would overwrite the gateware (e.g. bistream) stored on the flash, so I added a prefix of 0x00010000:

{
	"buildroot/Image.fbi":        "0x00010000",
	"buildroot/rootfs.cpio.fbi":  "0x00410000",
	"buildroot/rv32.dtb.fbi":     "0x00B10000",
	"emulator/emulator.bin.fbi":  "0x00B11000"
}

From litex/soc/software/bios/boot.c:

#define KERNEL_IMAGE_FLASH_OFFSET      0x00000000 //  0MB
#define ROOTFS_IMAGE_FLASH_OFFSET      0x00400000 //  4MB
#define DEVICE_TREE_IMAGE_FLASH_OFFSET 0x00B00000 // 11MB
#define EMULATOR_IMAGE_FLASH_OFFSET    0x00B01000 // 11MB + 4KB

I modified litex/soc/software/bios/boot.c:

diff --git a/ b/litex/soc/software/bios/boot.c
index dd1ab2c8..59f41fa5 100644
--- a/litex/soc/software/bios/boot.c
+++ b/litex/soc/software/bios/boot.c
@@ -408,10 +408,10 @@ static int copy_image_from_flash_to_ram(unsigned int *flash_address, unsigned in
 }
 #endif
 
-#define KERNEL_IMAGE_FLASH_OFFSET      0x00000000 //  0MB
-#define ROOTFS_IMAGE_FLASH_OFFSET      0x00400000 //  4MB
-#define DEVICE_TREE_IMAGE_FLASH_OFFSET 0x00B00000 // 11MB
-#define EMULATOR_IMAGE_FLASH_OFFSET    0x00B01000 // 11MB + 4KB
+#define KERNEL_IMAGE_FLASH_OFFSET      0x00010000 //  0MB
+#define ROOTFS_IMAGE_FLASH_OFFSET      0x00410000 //  4MB
+#define DEVICE_TREE_IMAGE_FLASH_OFFSET 0x00B10000 // 11MB
+#define EMULATOR_IMAGE_FLASH_OFFSET    0x00B11000 // 11MB + 4KB
 
 void flashboot(void)
 {

from litex-boards.

pdp7 commented on July 18, 2024

It seems my kernel is too big to fit into:

pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ cat images.json.fbi 
{
	"buildroot/Image.fbi":       "0x00010000",
	"buildroot/rootfs.cpio.fbi": "0x00410000",
	"buildroot/rv32.dtb.fbi":    "0x00B10000"
}

pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ du -sk buildroot/Image.fbi
4964	buildroot/Image.fbi
pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ du -sk buildroot/rootfs.cpio
3968	buildroot/rootfs.cpio

In [10]: print(0x00410000-0x00010000)     
4194304

from litex-boards.

pdp7 commented on July 18, 2024

pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ lxterm --images=images.json.fbi /dev/ttyUSB0 --speed=1e6 --no-crc --flash
[LXTERM] Starting....
�����lr��l'




           ��	���� __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|
   Build your hardware, easily!

 (c) Copyright 2012-2020 Enjoy-Digital
 (c) Copyright 2007-2015 M-Labs

 BIOS built on Feb 16 2020 17:41:22
 BIOS CRC passed (74e9b464)

 Migen git sha1: --------
 LiteX git sha1: --------

--=============== SoC ==================--
CPU:       VexRiscv @ 48MHz
ROM:       32KB
SRAM:      4KB
L2:        8KB
MAIN-RAM:  32768KB

--========== Initialization ============--
Initializing SDRAM...
SDRAM now under hardware control
Memtest OK
Memspeed Writes: 82Mbps Reads: 119Mbps

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
[LXTERM] Received firmware download request from the device.
[LXTERM] Flashing buildroot/Image.fbi to 0x00010000 (5082540 bytes)...
[LXTERM] Upload complete (89.9KB/s).
[LXTERM] Flashing buildroot/rootfs.cpio.fbi to 0x00510000 (4063240 bytes)...
[LXTERM] Upload complete (89.9KB/s).
[LXTERM] Flashing buildroot/rv32.dtb.fbi to 0x00b10000 (1932 bytes)...
[LXTERM] Upload complete (95.3KB/s).
[LXTERM] Done.
KCCCCToo many consecutive errors, abortingLoading emulator.bin from flash...
Error: Invalid image length 0xffffffff
Booting from flash...
Error: Invalid image length 0xffffffff
No boot medium found

--============= Console ================--
litex> #*Q#(a���;�#&q#&7�H�ED�P=�@)���7�H�

from litex-boards.

pdp7 commented on July 18, 2024

@enjoy-digital commented in #35 (comment)

@pdp7: the default addresses for flashing are: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/boot.c#L411-L414 (+ your SPI Flash offset). You can modify it, but it needs to be consistent between the BIOS and flashing script. At startup, the BIOS will then copy the data from SPI Flash to the SDRAM and Emulator RAM and jump to Emulator RAM. In your case, it seems you are flashing the Linux images (not using the default addresses) but also "flashing" the emulator.bin to the Emulator RAM which will not work.
I need to update the Arty support with that, If you are not able to make it work, i'll try to update it tomorrow.

from litex-boards.

pdp7 commented on July 18, 2024

@pdp7: the default addresses for flashing are: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/boot.c#L411-L414 (+ your SPI Flash offset).

I see that linux-on-litex-vexriscv/soc_linux.py has:

self.add_constant("FLASH_BOOT_ADDRESS", 0x00400000)

I'm not sure if I need to change this or not?

In your case, it seems you are flashing the Linux images (not using the default addresses) but also "flashing" the emulator.bin to the Emulator RAM which will not work.

I did change:

diff --git a/litex/soc/software/bios/boot.c b/litex/soc/software/bios/boot.c
index dd1ab2c8..e475b99f 100644
--- a/litex/soc/software/bios/boot.c
+++ b/litex/soc/software/bios/boot.c
@@ -408,10 +408,10 @@ static int copy_image_from_flash_to_ram(unsigned int *flash_address, unsigned in
 }
 #endif
 
-#define KERNEL_IMAGE_FLASH_OFFSET      0x00000000 //  0MB
-#define ROOTFS_IMAGE_FLASH_OFFSET      0x00400000 //  4MB
-#define DEVICE_TREE_IMAGE_FLASH_OFFSET 0x00B00000 // 11MB
-#define EMULATOR_IMAGE_FLASH_OFFSET    0x00B01000 // 11MB + 4KB
+#define KERNEL_IMAGE_FLASH_OFFSET      0x00010000 //  0MB
+#define ROOTFS_IMAGE_FLASH_OFFSET      0x00510000 //  4MB
+#define DEVICE_TREE_IMAGE_FLASH_OFFSET 0x00B10000 // 11MB
+#define EMULATOR_IMAGE_FLASH_OFFSET    0x00B11000 // 11MB + 4KB
 
 void flashboot(void)
 {

@enjoy-digital: should I remove emulator.bin.fbi from images.json.fbi?

pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ cat images.json.fbi 

{
	"buildroot/Image.fbi":       "0x00010000",
	"buildroot/rootfs.cpio.fbi": "0x00510000",
	"buildroot/rv32.dtb.fbi":    "0x00B10000",
	"emulator/emulator.bin.fbi": "0x00B11000"
}

from litex-boards.

enjoy-digital commented on July 18, 2024

You should probably change FLASH_BOOT_ADDRESS to 0x00010000, otherwise it seems fine. I don't explain the "Too many consecutive errors" you have, i'll do some tests on Arty tomorrow.

from litex-boards.

pdp7 commented on July 18, 2024

@enjoy-digital thank you for the suggestion.

Does FLASH_BOOT_ADDRESS correspond to address in the flash chip?

I'm confused how this relates to:

            "spiflash":     0xd0000000,

from litex-boards.

pdp7 commented on July 18, 2024

FYI - this is the current state:

pdp7@x1:~/dev/enjoy/litex$ git diff
diff --git a/litex/soc/software/bios/boot.c b/litex/soc/software/bios/boot.c
index dd1ab2c8..e475b99f 100644
--- a/litex/soc/software/bios/boot.c
+++ b/litex/soc/software/bios/boot.c
@@ -408,10 +408,10 @@ static int copy_image_from_flash_to_ram(unsigned int *flash_address, unsigned in
 }
 #endif
 
-#define KERNEL_IMAGE_FLASH_OFFSET      0x00000000 //  0MB
-#define ROOTFS_IMAGE_FLASH_OFFSET      0x00400000 //  4MB
-#define DEVICE_TREE_IMAGE_FLASH_OFFSET 0x00B00000 // 11MB
-#define EMULATOR_IMAGE_FLASH_OFFSET    0x00B01000 // 11MB + 4KB
+#define KERNEL_IMAGE_FLASH_OFFSET      0x00010000 //  0MB
+#define ROOTFS_IMAGE_FLASH_OFFSET      0x00510000 //  4MB
+#define DEVICE_TREE_IMAGE_FLASH_OFFSET 0x00B10000 // 11MB
+#define EMULATOR_IMAGE_FLASH_OFFSET    0x00B11000 // 11MB + 4KB
 
 void flashboot(void)
 {

diff --git a/soc_linux.py b/soc_linux.py
index ecf875b..8a1285b 100644
--- a/soc_linux.py
+++ b/soc_linux.py
@@ -104,7 +104,7 @@ def SoCLinux(soc_cls, **kwargs):
 
         def add_spi_flash(self, dummy_cycles):
             # TODO: add spiflash1x support
-            spiflash_pads = self.platform.request("spiflash4x")
+            spiflash_pads = self.platform.request("spiflash")
             self.submodules.spiflash = SpiFlash(
                 spiflash_pads,
                 dummy        = dummy_cycles,
@@ -218,7 +218,7 @@ def SoCLinux(soc_cls, **kwargs):
 
         def configure_boot(self):
             if hasattr(self, "spiflash"):
-                self.add_constant("FLASH_BOOT_ADDRESS", 0x00400000)
+                self.add_constant("FLASH_BOOT_ADDRESS", 0x00010000)
 
         def generate_dts(self, board_name):
             json = os.path.join("build", board_name, "csr.json")

The results of trying to flash:

pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ cat images.json.fbi 
{
	"buildroot/Image.fbi":       "0x00010000",
	"buildroot/rootfs.cpio.fbi": "0x00510000",
	"buildroot/rv32.dtb.fbi":    "0x00B10000",
	"emulator/emulator.bin.fbi": "0x00B11000"
}
pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ lxterm --images=images.json.fbi /dev/ttyUSB0 --speed=1e6 --no-crc --flash
[LXTERM] Starting....
lr��lf




      ��	���� __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|
   Build your hardware, easily!

 (c) Copyright 2012-2020 Enjoy-Digital
 (c) Copyright 2007-2015 M-Labs

 BIOS built on Feb 16 2020 20:00:29
 BIOS CRC passed (1b634563)

 Migen git sha1: --------
 LiteX git sha1: --------

--=============== SoC ==================--
CPU:       VexRiscv @ 48MHz
ROM:       32KB
SRAM:      4KB
L2:        8KB
MAIN-RAM:  32768KB

--========== Initialization ============--
Initializing SDRAM...
SDRAM now under hardware control
Memtest OK
Memspeed Writes: 82Mbps Reads: 119Mbps

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
[LXTERM] Received firmware download request from the device.
[LXTERM] Flashing buildroot/Image.fbi to 0x00010000 (5082540 bytes)...
[LXTERM] Upload complete (89.9KB/s).
[LXTERM] Flashing buildroot/rootfs.cpio.fbi to 0x00510000 (4063240 bytes)...
[LXTERM] Upload complete (89.9KB/s).
[LXTERM] Flashing buildroot/rv32.dtb.fbi to 0x00b10000 (1932 bytes)...
[LXTERM] Upload complete (95.5KB/s).
[LXTERM] Flashing emulator/emulator.bin.fbi to 0x00b11000 (9592 bytes)...
[LXTERM] Upload complete (89.3KB/s).
[LXTERM] Done.
KCCCCToo many consecutive errors, abortingLoading emulator.bin from flash...
Error: Invalid image length 0xffffffff
Booting from flash...
Error: Invalid image length 0xffffffff
No boot medium found

--============= Console ================--
litex> 75E��@�E���	M� �$�#��>g��#"���H��]�'����#.���o�����o���o����o�7��o��e��o��7E��o��7e���o��7eE��o��7eE���o��7eE����o��7eE�E��o��7eE�����o��7eE��E��o��7eE��E���o��7eE��E�\��o��7eE��E�7��o��7eE��E�\i��o��7eE��E�\7E��o��7eE��E�\7i���o��7eE��E�\7iE#��o��7e

from litex-boards.

pdp7 commented on July 18, 2024

@mithro can you see anything wrong with what I am doing? thanks

from litex-boards.

pdp7 commented on July 18, 2024

@enjoy-digital thank for all your help! I recently bought an Arty A7 Artix-35T and I have Vivado installed. Could I try to reproduce the testing that you are doing?

from litex-boards.

enjoy-digital commented on July 18, 2024

With enjoy-digital/litex@9cb8f68 and litex-hub/linux-on-litex-vexriscv@e099b65 we can now boot from Flash on Arty. Since the Flash it too small for current Kernel Image/RootFS (we should probably disable some features to reduce it) the FPGA bitstream is not stored in the Flash.

To test it:

Be sure to update LiteX/Linux-on-LiteX-Vexriscv.
Install OpenOCD: https://github.com/enjoy-digital/openocd
./make.py --board=arty --build
./make.py --board=arty --fbi --flash
./make.py --board=arty --load

Then open lxterm: lxterm /dev/ttyUSBX --speed=1e6 and it should boot:

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
Timeout
Loading Image from flash...
Copying 4545524 bytes from 0xd0000000 to 0xc0000000...
Loading rootfs.cpio from flash...
Copying 8029184 bytes from 0xd0500000 to 0xc0800000...
Loading rv32.dtb from flash...
Copying 5017 bytes from 0xd0d00000 to 0xc1000000...
Loading emulator.bin from flash...
Copying 9600 bytes from 0xd0e00000 to 0x20000000...
Executing booted program at 0x20000000

--============= Liftoff! ===============--
VexRiscv Machine Mode software built Feb 17 2020 19:12:39
--========== Booting Linux =============--
[    0.000000] No DTB passed to the kernel
[    0.000000] Linux version 5.0.13 (florent@lab) (gcc version 8.3.0 (Buildroot 2019.08-rc2-00011-gad9efda578)) #1 Thu Sep 12 14:20:26 CEST 2019
[    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
[    0.000000] printk: bootconsole [sbi0] enabled
[    0.000000] Initial ramdisk at: 0x(ptrval) (8388608 bytes)
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x00000000c0000000-0x00000000cfffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00000000c0000000-0x00000000cfffffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000c0000000-0x00000000cfffffff]

Note that i have an old Arty, and it seems the Flash on new versions of Arty is different (FL128SAIF00) so you'll probably have to change the dummy_cycles (it should be 11+-4).

Also, i've not yet been able to flash using lxterm, so it's better using OpenOCD for now.

from litex-boards.

pdp7 commented on July 18, 2024

Also, i've not yet been able to flash using lxterm, so it's better using OpenOCD for now.

@enjoy-digital I've not used OpenOCD with Arty before. What adapter do you use?

I have a SEGGER J-Link. Any idea if that would work?

from litex-boards.

enjoy-digital commented on July 18, 2024

@pdp7: the JTAG programmer is already integrated on the Arty, you just need to plug the micro-usb cable :)

from litex-boards.

pdp7 commented on July 18, 2024

@enjoy-digital Awesome!

from litex-boards.

pdp7 commented on July 18, 2024

@enjoy-digital I tried

cab81d5 (HEAD -> master, origin/master, origin/HEAD) sim: use new sdram verbosity parameter
pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ ./make.py --board=arty --load

and got an error:

 CC       isr.o
 CC       main.o
 LD       emulator.elf
chmod -x emulator.elf
 OBJCOPY  emulator.bin
chmod -x emulator.bin
Open On-Chip Debugger 0.10.0+dev-01069-gee56c502 (2020-02-19-16:25)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter driver' not 'interface'
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
DEPRECATED! use 'adapter speed' not 'adapter_khz'
fpga_program
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description '*', serial '*' at bus location '*'

My dmesg has:

[11788.271508] usb 1-4: new high-speed USB device number 11 using xhci_hcd
[11788.297793] usb 1-4: New USB device found, idVendor=0403, idProduct=6010, bcdDevice= 7.00
[11788.297801] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[11788.297805] usb 1-4: Product: Digilent USB Device
[11788.297808] usb 1-4: Manufacturer: Digilent
[11788.297811] usb 1-4: SerialNumber: 210319AB5B5B
[11788.302579] ftdi_sio 1-4:1.0: FTDI USB Serial Device converter detected
[11788.302670] usb 1-4: Detected FT2232H
[11788.303018] usb 1-4: FTDI USB Serial Device converter now attached to ttyUSB0
[11788.305759] ftdi_sio 1-4:1.1: FTDI USB Serial Device converter detected
[11788.305846] usb 1-4: Detected FT2232H
[11788.306216] usb 1-4: FTDI USB Serial Device converter now attached to ttyUSB1

from litex-boards.

pdp7 commented on July 18, 2024

Oh, it is permissions:

28187 openat(AT_FDCWD, "/dev/bus/usb/001/011", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission denied)

I suppose I need udev rules but to brute force I just did chown.

Here it is now:

 CC       isr.o
 CC       main.o
 LD       emulator.elf
chmod -x emulator.elf
 OBJCOPY  emulator.bin
chmod -x emulator.bin
Open On-Chip Debugger 0.10.0+dev-01069-gee56c502 (2020-02-19-16:25)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter driver' not 'interface'
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
DEPRECATED! use 'adapter speed' not 'adapter_khz'
fpga_program
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 25000 kHz
Info : JTAG tap: xc7.tap tap/device found: 0x0362d093 (mfg: 0x049 (Xilinx), part: 0x362d, ver: 0x0)

and I have litex bios:

pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ lxterm /dev/ttyUSB1 --speed=1e6
[LXTERM] Starting....

litex>

from litex-boards.

pdp7 commented on July 18, 2024

@enjoy-digital I'm trying to run the build:

./make.py --board=arty --build

which ends in this error:

python3 -m litex.soc.software.mkmscimg bios.bin --little
make: Leaving directory '/home/pdp7/dev/enjoy/linux-on-litex-vexriscv/build/arty/software/bios'
/home/pdp7/dev/litex-buildenv/build/Xilinx/opt/Xilinx/Vivado/2017.3/bin/rdiArgs.sh: line 179: 29301 Segmentation fault      (core dumped) "$RDI_PROG" "$@"
Traceback (most recent call last):
  File "./make.py", line 358, in <module>
    main()
  File "./make.py", line 345, in main
    builder.build()
  File "/usr/local/lib/python3.7/dist-packages/litex-0.2.dev0-py3.7.egg/litex/soc/integration/builder.py", line 194, in build
    toolchain_path=toolchain_path, **kwargs)
  File "/usr/local/lib/python3.7/dist-packages/litex-0.2.dev0-py3.7.egg/litex/soc/integration/soc.py", line 874, in build
    return self.platform.build(self, *args, **kwargs)
  File "/usr/local/lib/python3.7/dist-packages/litex-0.2.dev0-py3.7.egg/litex/build/xilinx/platform.py", line 48, in build
    return self.toolchain.build(self, *args, **kwargs)
  File "/usr/local/lib/python3.7/dist-packages/litex-0.2.dev0-py3.7.egg/litex/build/xilinx/vivado.py", line 355, in build
    _run_script(script)
  File "/usr/local/lib/python3.7/dist-packages/litex-0.2.dev0-py3.7.egg/litex/build/xilinx/vivado.py", line 105, in _run_script
    raise OSError("Subprocess failed")
OSError: Subprocess failed

any suggestions?

I'm not very familiar with vivado. thanks!

from litex-boards.

pdp7 commented on July 18, 2024

I installed the current Vivado:

pdp7@x1:~/dev/enjoy/linux-on-litex-vexriscv$ which vivado
/home/pdp7/tools/Xilinx/Vivado/2019.2/bin/vivado

and build now works:

<snip>
INFO: [Common 17-206] Exiting Vivado at Thu Feb 20 00:23:40 2020...
buildroot/rv32.dtb: Warning (reg_format): /soc/spiflash@f0004800/flash@0:reg: property has invalid length (16 bytes) (#address-cells == 2, #size-cells == 1)
buildroot/rv32.dtb: Warning (unit_address_vs_reg): /soc/clk@f0009800/CLKOUT0: node has a reg or ranges property, but no unit name
buildroot/rv32.dtb: Warning (unit_address_vs_reg): /soc/clk@f0009800/CLKOUT1: node has a reg or ranges property, but no unit name
buildroot/rv32.dtb: Warning (unit_address_vs_reg): /soc/clk@f0009800/CLKOUT2: node has a reg or ranges property, but no unit name
buildroot/rv32.dtb: Warning (unit_address_vs_reg): /soc/clk@f0009800/CLKOUT3: node has a reg or ranges property, but no unit name
buildroot/rv32.dtb: Warning (unit_address_vs_reg): /soc/clk@f0009800/CLKOUT4: node has a reg or ranges property, but no unit name
buildroot/rv32.dtb: Warning (unit_address_vs_reg): /soc/clk@f0009800/CLKOUT5: node has a reg or ranges property, but no unit name
buildroot/rv32.dtb: Warning (unit_address_vs_reg): /soc/clk@f0009800/CLKOUT6: node has a reg or ranges property, but no unit name
buildroot/rv32.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
buildroot/rv32.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
buildroot/rv32.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
buildroot/rv32.dtb: Warning (avoid_default_addr_size): /soc/spiflash@f0004800/flash@0: Relying on default #address-cells value
buildroot/rv32.dtb: Warning (avoid_default_addr_size): /soc/spiflash@f0004800/flash@0: Relying on default #size-cells value
buildroot/rv32.dtb: Warning (avoid_unnecessary_addr_size): Failed prerequisite 'avoid_default_addr_size'
buildroot/rv32.dtb: Warning (unique_unit_address): Failed prerequisite 'avoid_default_addr_size'
 CC       isr.o
 CC       main.o
 LD       emulator.elf
chmod -x emulator.elf
 OBJCOPY  emulator.bin
chmod -x emulator.bin

However, this is what happens with the LiteX BIOS:

litex> reboot

        __   _ __      _  __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|
   Build your hardware, easily!

 (c) Copyright 2012-2020 Enjoy-Digital
 (c) Copyright 2007-2015 M-Labs

 BIOS built on Feb 20 2020 00:42:41
 BIOS CRC passed (325349ef)

 Migen git sha1: --------
 LiteX git sha1: --------

--=============== SoC ==================--
CPU:       VexRiscv @ 100MHz
ROM:       32KB
SRAM:      4KB
L2:        8KB
MAIN-RAM:  262144KB

--========== Initialization ============--
Ethernet init...
Initializing SDRAM...
SDRAM now under software control
Read leveling:
m0, b0: |11111111111100000000000000000000| delays: 06+-06
m0, b1: |00000000000000111111111111110000| delays: 21+-07
m0, b2: |00000000000000000000000000000011| delays: 31+-01
m0, b3: |00000000000000000000000000000000| delays: -
m0, b4: |00000000000000000000000000000000| delays: -
m0, b5: |00000000000000000000000000000000| delays: -
m0, b6: |00000000000000000000000000000000| delays: -
m0, b7: |00000000000000000000000000000000| delays: -
best: m0, b1 delays: 21+-07
m1, b0: |11111111111100000000000000000000| delays: 06+-06
m1, b1: |00000000000000111111111111100000| delays: 20+-06
m1, b2: |00000000000000000000000000000011| delays: 31+-01
m1, b3: |00000000000000000000000000000000| delays: -
m1, b4: |00000000000000000000000000000000| delays: -
m1, b5: |00000000000000000000000000000000| delays: -
m1, b6: |00000000000000000000000000000000| delays: -
m1, b7: |00000000000000000000000000000000| delays: -
best: m1, b1 delays: 20+-06
SDRAM now under hardware control
Memtest OK
Memspeed Writes: 253Mbps Reads: 322Mbps

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
Timeout
Loading Image from flash...
Error: Invalid image length 0xa437004d
Booting from flash...
Error: Invalid image length 0xa437004d
Booting from network...
Local IP : 192.168.1.50
Remote IP: 192.168.1.100
Fetching from: UDP/69
Unable to download Image over TFTP
Network boot failed
Unable to download Linux images, falling back to boot.bin
Unable to download boot.bin over TFTP
Network boot failed
No boot medium found

--============= Console ================--
litex> help
LiteX BIOS, available commands:
mr         - read address space
mw         - write address space
mc         - copy address space
fe         - erase whole flash
fw         - write to flash
mdiow      - write MDIO register
mdior      - read MDIO register
mdiod      - dump MDIO registers

crc        - compute CRC32 of a part of the address space
ident      - display identifier

reboot     - reset processor
netboot    - boot via TFTP
serialboot - boot via SFL
flashboot  - boot from flash

memtest    - run a memory test
litex> flashboot
Loading Image from flash...
Error: Invalid image length 0xa437004d
Booting from flash...
Error: Invalid image length 0xa437004d
litex>

However, the flash is FL128SAIF00 so I will try adjusting the dummy cycles.

from litex-boards.

pdp7 commented on July 18, 2024

@enjoy-digital it seems like the dummy bytes might be 1?
https://www.cypress.com/file/196851/download

from litex-boards.

pdp7 commented on July 18, 2024

unrelated to Arty, @gregdavill now has prebuilt binaries for booting the hackaday badge from flash:
https://github.com/gregdavill/linux-on-litex-hadbadge

from litex-boards.

gregdavill commented on July 18, 2024

I've specifically skipped using the LiteX BIOS for flashing the images, because we already have a known-good DFU loader on the hadbadge. This removes one source of issues.

The builds you've linked to are using a version of litex from a few weeks ago, so I'll update that and get it working again, since some things I had to tweak directly in the BIOS; flash-offsets, etc, can be done in an easier way now.

from litex-boards.

enjoy-digital commented on July 18, 2024

@gregdavill: i'm happy to help if needed on the integration.
@pdp7: you can probably try dummy= 8 or 7 on your board. You can use the mr command of the BIOS to verify the data seen by the CPU.

from litex-boards.

gregdavill commented on July 18, 2024

This looks like it's working for me now.

https://github.com/gregdavill/linux-on-litex-vexriscv/tree/hadbadge-flash

When you clone this repo, make sure you also pull in the submodule. git clone --recursive
There should be no need to re-flash flash_images.bin if you've already got that on your badge.

Let me know how this works for you @pdp7

from litex-boards.

pdp7 commented on July 18, 2024

@gregdavill thanks! how did you decide on dummy bytes of 6 for hadbadge?
gregdavill/linux-on-litex-vexriscv@ebb5993#diff-d333d2919ed13c5156ec779d78eb84c0R183

from litex-boards.

gregdavill commented on July 18, 2024

Here is the instruction that the SpiFlashDualQuad driver in LiteX uses:

You'll notice there are technically only 4 dummy bytes, except SpiFlashDualQuad doesn't do anything for those two clocks for M[0-7] So you need 6.

I took a look at your last comments on that issue:

posted by @pdp7 in litex-hub/linux-on-litex-vexriscv#93 (comment)

...
litex> mr 0xd0000000 128
Memory dump:
0xd0000000  00 50 61 72 74 3a 20 4c 46 45 35 55 2d 34 35 46  .Part: LFE5U-45F
0xd0000010  2d 38 43 41 42 47 41 33 38 31 00 ff ff ff bd b3  -8CABGA381......
...

Looks like you're actually reading 1 byte too far. A bitstream from trellis starts with the bytes: 0xFF 0x00.
If you had set a dummy value of 8, this makes sense. As the driver essentially reads over the correct byte, and returns the next one. This is probably why you were having trouble getting this to work.

from litex-boards.

pdp7 commented on July 18, 2024

@gregdavill Ah ok, thank you. So the problem was that I thought it was using Fast Read (where the datasheet says 8) but it was really using Fast Read Quad.

from litex-boards.

pdp7 commented on July 18, 2024

@gregdavill I see that you are using spiflash4x:
https://github.com/gregdavill/linux-on-litex-vexriscv/blob/hadbadge-flash/soc_linux.py#L108

            spiflash_pads = self.platform.request("spiflash4x")

however, I had been using spiflash. Could this account for the difference in dummy bytes needed since it seems I was not using Fast Read Quad?

from litex-boards.

gregdavill commented on July 18, 2024

Yes, that is likely the case.
It does appear as if SpiFlashSingle makes use of 0x0B FAST_READ command.

from litex-boards.

pdp7 commented on July 18, 2024

This looks like it's working for me now.

https://github.com/gregdavill/linux-on-litex-vexriscv/tree/hadbadge-flash

When you clone this repo, make sure you also pull in the submodule. git clone --recursive
There should be no need to re-flash flash_images.bin if you've already got that on your badge.
@gregdavill
I ran the build OK as far as I can tell:

pdp7@x1:~/dev/greg/linux-on-litex-vexriscv$ python3 ./make.py --board=hadbadge --build

Here is the log

Copy the rootfs and kernel image:

pdp7@x1:~/dev/greg/linux-on-litex-vexriscv$ cp ~/dev/enjoy/linux-on-litex-vexriscv/buildroot/rootfs.cpio ~/dev/enjoy/linux-on-litex-vexriscv/buildroot/Image buildroot/
pdp7@x1:~/dev/greg/linux-on-litex-vexriscv$ ls buildroot/
board  Config.in  configs  external.desc  external.mk  Image  rootfs.cpio  rv32.dtb

Flash the hadbadge:

pdp7@x1:~/dev/greg/linux-on-litex-vexriscv$ python3 ./make.py --board=hadbadge --flash

which results in (partial?) error:

dfu-util: Could not open file build/hadbadge/gateware/ecp5_bitstream.bit for reading: No such file or directory

Here is the log

It seems to get stuck at booting Linux:

pdp7@x1:~/dev/greg/linux-on-litex-vexriscv$ lxterm /dev/ttyACM0 --speed=1e6
[LXTERM] Starting....
        __   _ __      _  __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|

 (c) Copyright 2012-2020 Enjoy-Digital
 (c) Copyright 2007-2015 M-Labs

 BIOS built on Feb 18 2020 21:30:47
 BIOS CRC passed (494989aa)

 Migen git sha1: 084e2a2
 LiteX git sha1: bd6fd3da

--=============== SoC ==================--
CPU:       VexRiscv @ 48MHz
ROM:       32KB
SRAM:      4KB
L2:        8KB
MAIN-RAM:  32768KB

--========== Initialization ============--
Initializing SDRAM...
SDRAM now under hardware control
Memtest OK
Memspeed Writes: 76Mbps Reads: 96Mbps

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
Timeout
Loading emulator.bin from flash...
Loading Image from flash...
Loading rootfs.cpio from flash...
Loading rv32.dtb from flash...
Executing booted program at 0x20000000

--============= Liftoff! ===============--
VexRiscv Machine Mode software built Feb 20 2020 14:08:39
--========== Booting Linux =============--

from litex-boards.

gregdavill commented on July 18, 2024

Sorry, you'll need to run

pdp7@x1:~/dev/greg/linux-on-litex-vexriscv$ python3 ./make.py --board=hadbadge --build --flash

If you just re-run with only --flash those files are created.
The have different names now, it's ecp5_bitstream.bit and flash_image.bin

from litex-boards.

gregdavill commented on July 18, 2024

Looks like you have an old ecppack that doesn't have the compression options:
https://gist.github.com/pdp7/9f670149c7c7e586973955c6c2a0994e#file-make-flash-hadbadge-greg-txt-L182

Just remove the --compress option here:
https://github.com/gregdavill/linux-on-litex-vexriscv/blob/hadbadge-flash/make.py#L264

from litex-boards.

pdp7 commented on July 18, 2024

@pdp7: you can probably try dummy= 8 or 7 on your board. You can use the mr command of the BIOS to verify the data seen by the CPU.

@enjoy-digital Thanks! The Arty does work now with dummy bytes of 7. Dummy bytes of 8 was invalid.

How should a variant of a board by handled?

I seems like old Arty needs 11 but newer, like mine, needs SPIFLASH_DUMMY_CYCLES = 7

from litex-boards.

pdp7 commented on July 18, 2024

Looks like you have an old ecppack that doesn't have the compression options:
https://gist.github.com/pdp7/9f670149c7c7e586973955c6c2a0994e#file-make-flash-hadbadge-greg-txt-L182

Just remove the --compress option here:
https://github.com/gregdavill/linux-on-litex-vexriscv/blob/hadbadge-flash/make.py#L264

@gregdavill
Thanks, I made the change:

diff --git a/make.py b/make.py
index cce2ddc..dc975d3 100755
--- a/make.py
+++ b/make.py
@@ -261,7 +261,7 @@ class HADBadge(Board):
     # create a compress bitstream with faster SPI parameters. This speeds up loading.
         build_name = 'build/hadbadge/gateware/top.config'
         ecp5_bitstream = 'build/hadbadge/gateware/ecp5_bitstream.bit'
-        os.system(f'ecppack {build_name} --compress --spimode qspi --freq 38.8 --bit {ecp5_bitstream}')
+        os.system(f'ecppack {build_name} --spimode qspi --freq 38.8 --bit {ecp5_bitstream}')
         
         
         os.system("dfu-util -d 1d50:614b --alt 2 --download build/hadbadge/gateware/ecp5_bitstream.bit")

However, I get a CRC error:

pdp7@x1:~/dev/greg/linux-on-litex-vexriscv$ lxterm /dev/ttyACM0 
[LXTERM] Starting....

        __   _ __      _  __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|
   Build your hardware, easily!

 (c) Copyright 2012-2020 Enjoy-Digital
 (c) Copyright 2007-2015 M-Labs

 BIOS built on Feb 20 2020 15:03:47
 BIOS CRC passed (52006b80)

 Migen git sha1: --------
 LiteX git sha1: --------

--=============== SoC ==================--
CPU:       VexRiscv @ 48MHz
ROM:       32KB
SRAM:      4KB
L2:        8KB
MAIN-RAM:  32768KB

--========== Initialization ============--
Initializing SDRAM...
SDRAM now under hardware control
Memtest OK
Memspeed Writes: 82Mbps Reads: 119Mbps

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
Timeout
Loading Image from flash...
CRC failed (expected d7eea437, got 96419fc1)
Booting from flash...
Error: Invalid image length 0x615000ff
No boot medium found

--============= Console ================--

I created gist with full build log: https://gist.github.com/pdp7/1c0ba6ef94dacfdaf228ecd72ca5d707

from litex-boards.

gregdavill commented on July 18, 2024

Interesting, from the Litex terminal there, can you run these commands:
mr 0xd0400000 64 and mr 0xd0880000 64

from litex-boards.

pdp7 commented on July 18, 2024

@gregdavill
here is the output:

litex> mr 0xd0400000 64
Memory dump:
0xd0400000  a4 8d 4d 00 37 a4 ee d7 73 10 40 10 97 01 4a 00  [email protected].
0xd0400010  93 81 c1 1e b7 62 00 00 73 b0 02 10 93 86 41 34  .....b..s.....A4
0xd0400020  13 06 10 00 af a6 c6 00 63 9e 06 0c 97 26 4a 00  ........c....&J.
0xd0400030  93 86 c6 fd 17 87 4d 00 13 07 47 28 63 d8 e6 00  ......M...G(c...
litex> mr 0xd0880000 64
Memory dump:
0xd0880000  00 00 3e 00 85 3a 3b 98 30 37 30 37 30 31 30 30  ..>..:;.07070100
0xd0880010  45 42 36 30 30 34 30 30 30 30 34 31 45 44 30 30  EB6004000041ED00
0xd0880020  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
0xd0880030  30 30 30 30 31 31 35 45 34 37 31 33 36 39 30 30  0000115E47136900

from litex-boards.

pdp7 commented on July 18, 2024

@gregdavill
This might be relevant:

pdp7@x1:~/dev/greg/linux-on-litex-vexriscv$ hexdump -C buildroot/Image |head
00000000  73 10 40 10 97 01 4a 00  93 81 c1 1e b7 62 00 00  |[email protected]..|
00000010  73 b0 02 10 93 86 41 34  13 06 10 00 af a6 c6 00  |s.....A4........|
00000020  63 9e 06 0c 97 26 4a 00  93 86 c6 fd 17 87 4d 00  |c....&J.......M.|
00000030  13 07 47 28 63 d8 e6 00  23 a0 06 00 93 86 46 00  |..G(c...#.....F.|
00000040  e3 cc e6 fe 13 04 05 00  93 84 05 00 13 86 01 34  |...............4|
00000050  23 20 a6 00 17 e1 47 00  13 01 c1 fa ef 20 90 2b  |# ....G...... .+|
00000060  ef 00 00 03 17 52 48 00  13 02 c2 26 23 2a 02 00  |.....RH....&#*..|
00000070  17 c1 47 00 13 01 01 f9  37 25 00 00 33 01 a1 00  |..G.....7%..3...|
00000080  13 05 04 00 93 85 04 00  ef 20 10 32 6f 00 d0 0c  |......... .2o...|
00000090  b7 05 00 c0 17 05 00 00  13 05 c5 f6 b3 85 a5 40  |...............@|
pdp7@x1:~/dev/greg/linux-on-litex-vexriscv$ hexdump -C buildroot/rootfs.cpio |head
00000000  30 37 30 37 30 31 30 30  45 42 36 30 30 34 30 30  |07070100EB600400|
00000010  30 30 34 31 45 44 30 30  30 30 30 30 30 30 30 30  |0041ED0000000000|
00000020  30 30 30 30 30 30 30 30  30 30 30 30 31 31 35 45  |000000000000115E|
00000030  34 37 31 33 36 39 30 30  30 30 30 30 30 30 30 30  |4713690000000000|
00000040  30 30 30 30 46 44 30 30  30 30 30 30 30 31 30 30  |0000FD0000000100|
00000050  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
00000060  30 30 30 30 30 32 30 30  30 30 30 30 30 30 2e 00  |00000200000000..|
00000070  30 37 30 37 30 31 30 30  45 42 36 30 30 39 30 30  |07070100EB600900|
00000080  30 30 34 31 45 44 30 30  30 30 30 30 30 30 30 30  |0041ED0000000000|
00000090  30 30 30 30 30 30 30 30  30 30 30 30 30 32 35 45  |000000000000025E|
pdp7@x1:~/dev/greg/linux-on-litex-vexriscv$

from litex-boards.

pdp7 commented on July 18, 2024

@gregdavill I built and installed prjtrellis and nextpnr from source:

Project Trellis - Open Source Tools for ECP5 FPGAs
Version 1.0-130-g4e4b95c
ecppack: ECP5 bitstream packer

and have left the compress option in there.

However, the ttyACM0 seems to not come up anymore after:

./make.py --board=hadbadge --build --flash

Here is log: https://gist.github.com/pdp7/5462b95fea8230dd807c0a90bf5bd591

I think this is a problem dfu-util: Error during download:

Opening DFU capable USB device...
ID 1d50:614b
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
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%       492951 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
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 1d50:614b
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #4 ...
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	[======================== ]  98%     14557184 bytes
dfu-util: Error during download
dfu-util: can't detach
Resetting USB to switch back to runtime mode

after this the normal HAD bootup screen is gone.

I have to recover with the stock gateware from Supercon workshop:

make: *** [Makefile:8: dfu_flash_all] Error 74
pdp7@x1:~/tmp/dev-tmp/supercon/hackaday_supercon_2019_logic_noise_FPGA_workshop/includes/stock_badge$ make
dfu-util -d 1d50:614a,1d50:614b -a 0 -D soc.bit
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 1d50:614b
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%      1236313 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
dfu-util -d 1d50:614a,1d50:614b -a 1 -D ipl.bin -R
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 1d50:614b
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
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%       298320 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode

from litex-boards.

gregdavill commented on July 18, 2024

Hmm, your flash regions look fine, There are 2 32bit words in front of the data section that contain length and crc.

I've had the hadbadge lockup and need to re-install the ipl/soc back onto the main flash before, so there might be some subtle bugs in the code there.

The usbcdc I've written is likely still very buggy, I've had it not show up a few times. Often disconnecting usb, power cycling the badge, selecting the cartridge using the ipl, then re-inserting the usb cable is enough.

But in the worst case. You may have to re-generate the bitstream, to get a different placement seed that works.

I also notice you're using a different buildroot Image. Maybe that's the difference? I'm still using the one I built at 36c3.

from litex-boards.

gregdavill commented on July 18, 2024

Looks like the issue here might be the buildroot binaries you have. It almost appears like your Image is too big, but from the log that actually doesn't appear so, your rootfs.cpio is pretty large though, it overflows into the next flash region...
My code doesn't have any error checking in there, so this went un-noticed...

I've just rebuilt my buildroot. following steps here: https://github.com/litex-hub/linux-on-litex-vexriscv#generating-the-linux-binaries-optional

Which resulted in an Image that was too big for the space I'd allocated. So I had to move rootfs.cpio around, that only needs 1 line changed.
gregdavill/linux-on-litex-vexriscv@ebb5993#diff-d333d2919ed13c5156ec779d78eb84c0R189
["buildroot/rootfs.cpio", "ROOTFS_IMAGE", "0x00900000"],

This worked for me, and I got to a login prompt.

from litex-boards.

pdp7 commented on July 18, 2024

@gregdavill Thanks, it works now!

I was trying to use:

4232	buildroot/Image
7844	buildroot/rootfs.cpio

so I copied the rootfs and Image from your OrangeCrab branch and changed the offset for ROOTFS_IMAGE as you suggested:

4336	buildroot/Image
3968	buildroot/rootfs.cpio

rootfs size: 5242880
0x00900000-0x00400000                                                                                                                                                                                      

rootfs size:  6291456
0x00f00000-0x00900000

pdp7@x1:~/dev/greg/linux-on-litex-vexriscv$ lxterm /dev/ttyACM0 
[LXTERM] Starting....

        __   _ __      _  __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|
   Build your hardware, easily!

 (c) Copyright 2012-2020 Enjoy-Digital
 (c) Copyright 2007-2015 M-Labs

 BIOS built on Feb 21 2020 13:26:13
 BIOS CRC passed (f068c563)

 Migen git sha1: --------
 LiteX git sha1: --------

--=============== SoC ==================--
CPU:       VexRiscv @ 48MHz
ROM:       32KB
SRAM:      4KB
L2:        8KB
MAIN-RAM:  32768KB

--========== Initialization ============--
Initializing SDRAM...
SDRAM now under hardware control
Memtest OK
Memspeed Writes: 82Mbps Reads: 119Mbps

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
Timeout
Loading Image from flash...
Copying 4652188 bytes from 0xd0400000 to 0xc0000000...
Loading rootfs.cpio from flash...
Copying 4062720 bytes from 0xd0900000 to 0xc0800000...
Loading rv32.dtb from flash...
Copying 1924 bytes from 0xd0f00000 to 0xc1000000...
Loading emulator.bin from flash...
Copying 9584 bytes from 0xd0f01000 to 0x20000000...
Executing booted program at 0x20000000

--============= Liftoff! ===============--
VexRiscv Machine Mode software built Feb 21 2020 13:28:33
--========== Booting Linux =============--
[    0.000000] No DTB passed to the kernel
[    0.000000] Linux version 5.0.13 (greg@xps) (gcc version 8.3.0 (Buildroot 2020.02-git-00561-g29e464a1ea)) #1 Sun Dec 29 08:05:17 ACDT 2019
[    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')

from litex-boards.

pdp7 commented on July 18, 2024

@gregdavill did an awesome job getting the badge to boot from flash:
gregdavill/linux-on-litex-vexriscv@ebb5993
It is currently in his branch:
https://github.com/gregdavill/linux-on-litex-vexriscv/commits/hadbadge-flash

It works OK for me! We just need to get it merged

from litex-boards.

enjoy-digital commented on July 18, 2024

Closing since working. Booting linux from flash is a bit hacky since the space is generally a limited and we don't have a file system, making it difficult to provide a generic solution in LiteX. The hacky initial support has been removed and it's now recommended to use a SDCard for standalone boot, but we could re-introduce Linux boot from SPI-Flash if there is a real need for it.

from litex-boards.

boot hadbadge from flash about litex-boards HOT 43 CLOSED

Comments (43)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent