00:05 <esden> hey, is there a reason why SoCMemRegion got deleted in this commit? https://github.com/enjoy-digital/litex/commit/3ba7c29ed9468a04583889d2707f6f273fbe1d27#diff-914c022a0437d3895bdb48a73f52af52

00:05 <tpb> Title: soc: add add_constant/add_config methods · enjoy-digital/litex@3ba7c29 · GitHub (at github.com)

00:06 <esden> The commit message does not seem to be related to that class disappearing as far as I understand.

00:06 <esden> If that was intentional what is the replacement for SoCMemRegion?

00:16 <esden> Just to clarify this is what I am trying to build again. It did work only two weeks ago or so. :( https://github.com/esden/litex-boards/blob/icebreaker/litex_boards/targets/icebreaker.py#L203

00:16 <tpb> Title: litex-boards/icebreaker.py at icebreaker · esden/litex-boards · GitHub (at github.com)

02:05 <levi> Looks like it's the add_memory_region and similar methods here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc_core.py#L215

02:05 <tpb> Title: litex/soc_core.py at master · enjoy-digital/litex · GitHub (at github.com)

02:06 <levi> I am not sure; I ran into some similar issues trying to get a board updated to work with the latest litex after getting started in litex-buildenv

02:14 <mithro> xobs: https://github.com/SymbiFlow/prjxray-bram-patch

02:14 <tpb> Title: GitHub - SymbiFlow/prjxray-bram-patch: Tool for updating the contents of BlockRAMs found in Xilinx 7 series bitstreams. (at github.com)

02:15 <mithro> bunnie[m]: You might be interested in the above too....

02:18 <mithro> Was written by a student and still a WIP, so don't expect too much

02:25 <xobs> That's cool! I know that's one of the huge pain points for people doing FPGA work.

04:56 <bunnie[m]> ooh cool

04:58 <bunnie[m]> ah yes...the patch loop going through fasm intermediate representation. neato!

06:49 <_florent_> esden: SoCMemRegion was supposed to be used internally (but that's true it was not specified anywhere), i'll look at your design and update it

06:51 <esden> no worries I have removed that

06:51 <_florent_> mithro: nice tool, that will indeed be very useful

06:52 <_florent_> esden: so have you been able to fix your design?

06:52 <esden> not sure if I still have to deal with the memory stuff or not maybe for gdb?

06:52 <esden> xobs: helped me a bunch to navigate the api changes and stuff

06:53 <esden> also I had to disable the bios building as it is waaaaay too large

06:53 <_florent_> esden: i think you were using these two lines to define a memory region that is only used by the linker

06:53 <esden> so I am back to doing the jump to my program immediatly trick that xobs has as the bios is useless for me anyways

06:54 <esden> I really wish litex was bit less in "flux" let's say. It was really hard to get things to work again. :(

06:54 <esden> but it blinks now and I can write a c program for it which is very nice

06:55 <esden> but I do have a bit of a feeling that I am shooting with a bazooka at a fly here :D

06:55 <esden> but having the csr headers autogenerate is nice

06:57 <esden> Thanks for explaining the line. You are probably right, the linker script does not look right to me. I had to change the definitions by hand when I was copying out the autogenerated files into my C project.

06:58 <_florent_> yes sorry for the changes, we should really specify what is for internal use / what is the user API. I'm generally trying to provide retro-compatibility for the API, but that's more difficult when users are using internal elements of LiteX.

06:59 <esden> I need to tidy things up and hopefully will be able to submit a pull request at least with the icebreaker platform file.

07:00 <esden> Yeah of course. The internal API stuff was not the only issue though. :)

07:00 <esden> the change of the csr access function name threw me off too.

07:01 <_florent_> esden: if you want to define a linker region, you can do it with add_memory_region, similar to: https://github.com/timvideos/litex-buildenv/blob/master/targets/ice40_up5k_b_evn/base.py#L103-L105

07:01 <tpb> Title: litex-buildenv/base.py at master · timvideos/litex-buildenv · GitHub (at github.com)

07:01 <esden> and that the bios became suddenly massive

07:01 <esden> I was trying to do it "the intended way" but had to disable the bios completely to move forward.

07:02 <esden> Ohh great, thanks for the link. I will look at it. :)

07:39 <_florent_> esden: BTW, i have an iCEBreaker board and could help more if needed. If you do a PR with your iCEBreaker design to litex-boards, i could maintain it and make sure it still build with Travis-CI.

07:40 <_florent_> esden: so before the changes, you were able to use the LiteX Bios with the iCEBreaker and it's no longer the case?

07:40 <esden> Awesome! Yeah it was definitely a plan from the beginning to send the stuff up stream to you. :)

07:40 <esden> Yeah before the recent changes it was fitting, barely but it was fitting.

07:41 <esden> At the end still not very useful as I don't really need or want it. I rather have the space available for the application. :)

07:42 <esden> It was more of an excercise to see that we got the SoC to work and are able to use the build system to create a working binary.

07:42 <esden> Much more useful would be generating of a "C project skeleton".

07:43 <_florent_> That would be good to have it working, and when space it needed (which is generally the case with iCE40 :)) the BIOS could be moved to the SPI Flash

07:43 <esden> Also I think xobs said that him disabling the bios and just forcing the 4 byte jump to application thing is not the intended way to do it and a bit of a hack.

07:43 <esden> Ohh the bios was in SPI flash all the time.

07:43 <esden> there is no way in hell it would ever fit onto the ICE40

07:44 <_florent_> ah ok, then there is no reason it's no longer possible

07:45 <_florent_> if i want to help, should i use https://github.com/esden/litex-boards/tree/icebreaker? or do you have something you already updated?

07:45 <tpb> Title: GitHub - esden/litex-boards at icebreaker (at github.com)

07:45 <esden> well I say "no way" there are always ways and means. But it was not fitting on the ice40 earlier either.

07:46 <esden> I have done some work over here. I have not pushed it yet.

07:46 <esden> I need to clean up the mess I made. :)

07:46 <esden> I will be pushing it to the icebreaker branch you pointed out though.

07:46 <esden> I will let you know as soon as I have done so. :)

07:48 <_florent_> ok, i'm just going to do a quick test with the old files to see

08:03 <esden> _florent_: will add_mem_regions overwrite the setting for a region if called a second time on the same name of a region?

08:06 <_florent_> it should produce an error if you use the same name

08:06 <_florent_> telling you that is has already been defined

08:08 <esden> ok, well that is the point why xobs used the other method to access it. We need to override the default.

08:13 <esden> ok rebased and force pushed updated files to my branch

08:16 <esden> Keep in mind that the address where the bios in the flash is at the moment is not compatible with the master iceprog.

08:17 <esden> iceprog by default deletes bigger pages so you need to use the newly added `-i 4` option that I added in this pull request when flashing the bios at the 0x0001a000 address. Or you need to move the bios to 0x00020000 and waste some more flash space. :) https://github.com/cliffordwolf/icestorm/pull/247

08:17 <tpb> Title: Added an option to choose the erase block size. by esden · Pull Request #247 · cliffordwolf/icestorm · GitHub (at github.com)

08:20 <esden> Ohh I just realized, the bios probably is overrunning now because I could not override the rom block size in the linker script... duh...

08:36 <esden> Ok, here is what I have so far regarding wishbone-tool and LED blinking. https://github.com/icebreaker-fpga/icebreaker-litex-examples

08:36 <tpb> Title: GitHub - icebreaker-fpga/icebreaker-litex-examples: Example litex Risc-V SOC and some example code projects in multiple languages. (at github.com)

08:39 <esden> _florent_: I can create a pull request from my icebreaker branch if you want. Unless you have some suggestions and want me to tweak and clean things before I do that.

08:44 <_florent_> esden: yes sure, that will be probably be easier. You can do that, then we could merge and i will test/update it if needed.

08:44 <_florent_> esden: so from what i understand, with your target you want to be able to create a minimal SoC with a CPU or with the UART bridge?

08:53 <esden> Yeah the goal is to get a bare bones CPU that I can program in C, Rust, Micropython. That can have some gpio or some some other fun cores connected to the icebreaker Pmods.

08:53 <esden> I have sent in the pull request: https://github.com/litex-hub/litex-boards/pull/51

08:53 <tpb> Title: Add iCEBreaker FPGA support by esden · Pull Request #51 · litex-hub/litex-boards · GitHub (at github.com)

08:53 <esden> there is also a link to the example code I mentioned above.

08:54 <esden> The overarching motivating project is the TWANG game port to the icebreaker.

09:36 <_florent_> Thanks for the PR, it's merged. I'll play with it in the next days and see if i can get the BIOS working again.

17:55 <sajattack[m]> turns out having fpgas close amplified dodgy rca is a bad idea

17:55 <sajattack[m]> * turns out having fpgas close to amplified dodgy rca is a bad idea

17:58 <mithro> esden: BTW the bios should have gotten smaller again. The bios size increase was reverted and LTO has been enable which gives somewhere between 10% and 40% depending on your configuration

18:02 <esden> _florent_: awesome thank you for merging! :)

18:06 <esden> mithro: ok that is nice. :) But first, after thinking about it I don't think the problem here was the actual size increase but the fact that I had to disable the linker rom address remap. And second, I don't really need the bios. It would be nicer if we could have a way to provide an alternative demo program as part of litex. The bios functionality is not really useful on tiny boards like the iCEBreaker or Fomu. :)

18:07 <esden> in this case we just want the bare metal and header definitions so we can program it like a small microcontroller.

18:10 <esden> That said I am glad I can finally write some C programs for it. It took long enough to get here.