Can you merge this with #311 ?

Do you mean you don't want to merge this branch itself, but together with #311 OR that this will be merged first and #311 should be rebased on top of this?

[Re setting sizes from Makefiles]
@ewenmcneill - I totally agree that your solution is more flexible and probably could be incorporated in all buildenv's targets, but I'm not sure if this PR is the right place to do this.

@mateusz-holenko Fair enough. I do agree it'd be worth getting this PR to a state where we're happy we can merge it, and merging it soon.

I can easily make another PR after this is merged to add that flexibility back in again. (It was there previously as the previous upstream litex default sizes were "0", which meant specifying anything was an override; whereas the change to using max() as the way of 'setting the default' means it's only possible to change the RAM size up from the command line.)

FWIW, I was only aiming at restoring the same level of flexibility that was there previously; rather than adding more flexibility in as well. I definitely agree that additional flexibility is either "use upstream litex" or "we should do a larger design of how to do that".

Ewen

@ewenmcneill - I cherry-picked more commits from you branch. Will you have some spare time to test the current version of this branch on the HW?
You mentioned that you have an access to TinyFPGA BX, right?

I'm currently testing it on Arty - I do that by simply running:

• the default HDMI2USB firmware on lm32,
• Micropython on vexriscv,
• Zephyr on vexrsicv
  and observing if it boots correctly and responds to an input on uart.

You mentioned that you have an access to TinyFPGA BX, right?

@mateusz-holenko Yes, I have a TinyFPGA BX among other devices. I was testing with TinyFPGA BX mostly because it was convenient and tiny to use for "laptop" development :-)

Seems to me like it's working. With the steps below to build PR #348, I get basically the same results as I was getting with my changes (compare, eg, with #277 (comment)).

git fetch origin pull/348/head:pr348
git checkout pr348
git submodule update --init --recursive
scripts/download-env.sh
make clean
make gateware
scripts/build-micropython.sh
make image-flash

gives me a working litex BIOS, with 10kB of RAM, and a working MicroPython.

I notice that you're temporarily pinned to my MicroPython WIP change. Possibly we should merge that into the FuPy MicroPython if we're agreed that's the direction we want to go? Then you could change the pin back to the FuPy one.

Ewen

(LX P=tinyfpga_bx.minimal F=micropython R=pr348) ewen@parthenon:/src/fpga/litex-
buildenv$ make firmware-connect
flterm --port=/dev/ttyUSB0 --speed=115200
[FLTERM] v2.4-29-g47d3b15 Starting...

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

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

 BIOS built on Apr  6 2020 09:27:48
 BIOS CRC passed (931d7dc5)

 Migen git sha1: 3f9809b
 LiteX git sha1: 536ae0e6

--=============== SoC ==================--
CPU:       LM32 @ 16MHz
ROM:       32KB
SRAM:      10KB

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
Timeout
Booting from flash...
Executing booted program at 0x20058008

--============= Liftoff! ===============--
MicroPython v1.9.4-1430-ge23216bf2 on 2020-04-06; litex with lm32
>>> print("Hello World!")
Hello World!
>>> 

(LX P=tinyfpga_bx.minimal F=micropython R=pr348) ewen@parthenon:/src/fpga/litex-
buildenv$ git log -2
commit 421a402a68824dda81395c58675c1d55c21a0261 (HEAD -> pr348)
Author: Mateusz Holenko <mholenko@antmicro.com>
Date:   Fri Apr 3 11:02:18 2020 +0200

    micropython: temporarily change the fork
    
    The new fork containt a commit removing an outdated `hw`
    directory generated by LiteX.

commit d9d9cf24393e5ea39808d25fb33a693ebdc7cbe4
Author: Ewen McNeill <ewen@naos.co.nz>
Date:   Fri Mar 13 22:19:22 2020 +1300

    micropython: link to litex hw includes
    
    (Instead of relying on third_party/ports/fupy having a cached copy of the
    "hw" includes, which could get out of date; and was out of date after updating
    litex; modern litex has a different set of CSR routines.)
(LX P=tinyfpga_bx.minimal F=micropython R=pr348) ewen@parthenon:/src/fpga/litex-
buildenv$ 

@ewenmcneill - Any idea if the ROM is coming from SPI flash? (I guess we should also put the ROM source in the BIOS output?)

@ewenmcneill - Any idea if the ROM is coming from SPI flash? (I guess we should also put the ROM source in the BIOS output?)

@mithro I can't see how the TinyFPGA rom segment wouldn't be coming from the SPI flash, given

It was definitely coming from the SPI Flash in the version I was working on, because I looked at the linker maps.

Ewen

ETA 2020-04-06 now that I've grabbed the laptop I built on, this is the TinyFPGA BX linker map:

(LX P=tinyfpga_bx.minimal F=micropython R=pr348) ewen@parthenon:/src/fpga/litex-
buildenv$ cat build/tinyfpga_bx_base_lm32.minimal/software/include/generated/regions.ld 
MEMORY {
	sram : ORIGIN = 0x01000000, LENGTH = 0x00002800
	csr : ORIGIN = 0x82000000, LENGTH = 0x00010000
	spiflash : ORIGIN = 0x20000000, LENGTH = 0x00100000
	rom : ORIGIN = 0x20050000, LENGTH = 0x00008000
	user_flash : ORIGIN = 0x20058000, LENGTH = 0x000a7f00
}
(LX P=tinyfpga_bx.minimal F=micropython R=pr348) ewen@parthenon:/src/fpga/litex-
buildenv$ 

Note how the rom segment overlaps the spiflash segment, and is immediately before the user_flash segment.

Also FWIW, MicroPython boots just as slowly as it did before, ie, consistent with slow SPI single speed no cache :-)

@ewenmcneill - Great! Just wanted to check. @mateusz-holenko Is this ready to merge now then?

@mithro I tested it on Arty and both the default HDMI2USB and Micropython boot fine.
I was planning to test it today also on Nexys Video and netv2.

Otherwise I believe it's ready to be merged.

I notice that you're temporarily pinned to my MicroPython WIP change. Possibly we should merge that into the FuPy MicroPython if we're agreed that's the direction we want to go? Then you could change the pin back to the FuPy one.

@ewenmcneill That was exactly my idea. Could you create a PR to FuPy MicroPython? Once it's merged I will point back to the original repository.

@mithro Travis is red, but it's caused by some network problems when downloading conda packages:

('Connection broken: OSError("(104, \'ECONNRESET\')")', OSError("(104, 'ECONNRESET')"))

It happens a lot lately :(

All other tests passed.

Tested on nexys_video and netv2 - the default firmware boots nicely to prompt.

The only problem was that for nexys_video I had to disable CAS module as there were errors during synthesis because user_btn5 and cpu_reset signals are using the same pin.

Targets tested on HW:

• arty
• nexys_video
• netv2
• tinyfpga_bx

Great! Let's merge for now and continue with more pull requests.

@ewenmcneill That was exactly my idea. Could you create a PR to FuPy MicroPython? Once it's merged I will point back to the original repository.

fupy/micropython#58, which I've just merged since I have commit rights on that repo, and since we all seem in agreement with the approach.

We'll want to revert 421a402 (which changes it to use my fork/branch) fairly soon. @mateusz-holenko Do you want do do that revert? Or should I create a revert commit/PR? (The two are currently the same, other than the merge commit in the FuPy MicroPython version.)

Ewen

@mithro Great!

@ewenmcneill I created a PR: #385