Build Linux about fusesoc

[olofk]

Well, you sort of asked in the right place since I did a heavy update on the build instructions on the OpenCores wiki last week. :)

As you have noticed, there are problems with openrisc.net, but you can use the kernel from here https://github.com/skristiansson/linux in the meantime. That should be the same version as is recommended on the wiki.

Regarding the BOOTLOADER_BIN=vmlinux parameter to fusescoc, there is no such parameter, so that won't do anything at all unfortunately. I'm not sure about the exact procedure, but you probably need to combine the FPGA image and the linux image to a single file that you can download to the Flash. You also need to add a proper bootloader so that the OpenRISC will start by reading the vmlinux image from SPI Flash to RAM. This is a bit trickier though. The default bootloader for Atlys (available in rtl/verilog/rom.v) will just clear a register and then end up in an endless loop. That might seem like a stupid thing to do, but I presume in this case that the intention is that users should connect a debugger to the JTAG port and load software that way.

I haven't played with the Atlys image very much unfortunately, so I might be wrong on some details here

[KarlTao]

Hi there,
Since old version can do this, I browsed orpsocv2, and I found the Makefile doing the combining work. It uses "promgen" command to generate the .mcs file from vmlinux and orpsoc_top.bin. And this is a Xilinx command, I don't need the old or32 toolchain to be installed to run it. So I tried copied this line from makefile and run it. It does generate the .mcs file but programmed to the Atlys board, no HDMI output. So I think the ORPSoC is still loading its initial ROM rather than the vmlinux. Can you give me a clue how to make it load the linux rather than the initial rom?

Thank you very much!

I attach the Makefile doing the combining below:

////* Generate MCS with bootloader specified by user, if BOOTLOADER_BIN defined.*/
ifeq ($(BOOTLOADER_BIN),)
$(MCS_FILE): $(BIT_FILE_FOR_SPI)
@echo; echo "\t#### Generating .mcs file for SPI load ####";
$(Q)promgen -spi -p mcs -w -o $@ -s $(SPI_FLASH_SIZE_KBYTES) -u 0 $<
else
$(MCS_FILE): $(BIT_FILE_FOR_SPI)
@echo; echo "\t#### Generating .mcs file with bootloader for SPI load ####";
$(Q)promgen -spi -p mcs -w -o $@ -s $(SPI_FLASH_SIZE_KBYTES) -u 0 $<
-data_file up $(SPI_BOOTLOADER_SW_OFFSET_HEX) $(BOOTLOADER_BIN)
endif

[olofk]

Yes, promgen is the right thing to use here, but that only solves half the problem. When the CPU boots up it will execute the instructions in the bootrom (https://github.com/openrisc/orpsoc-cores/blob/master/systems/atlys/rtl/verilog/rom.v#L58) which will just put it in an endless loop. You need to replace the contents of this boot rom with instructions that gets the data out from the SPI flash. There is probably something hidden deep inside of orpsocv2 that you can use, bit it's a bit messy.

As a side note, I'm working on a collection of useful bootloaders that I'm going to add to orpsoc-cores soon that can be used for any board. I'm planning to put a SPI Flash loader there once I have dug up the one from orpsocv2 and polished it up a bit. I'm afraid that is no help for you right now, but I wanted to let you know that we at least are working on better solutions for these kinds of problems

[hzq1001]

Hi olof,

I'm wondering if you have already updated the bootloaders you mentioned above. I'm also looking for instructions on booting linux on atlys board, and I hope I can use fusesoc instead of orpsocv2.

Thanks,
Patrick

[olofk]

Hi Patrick,

I'm not all the way there yet. I have created a bootloader that can boot images in the uImage format (created by mkimage in uboot). This works fine for de0 nano, and is now the default bootloader for that system. I have tried to do the same thing on my lx9 microboard (which should be similar to Atlys), but haven't gotten it to work yet. It works fine in simulations, but not on real hw. I haven't had time to debug this further

[olofk]

Closing this due to inactivity and as it's not really relevant to FuseSoC