Wednesday, 2018-09-05

*** tpb has joined #timvideos00:00
shorneCarlFK[m]: I reproduced the failure on the qemu build00:27
CarlFKshorne: cool - Ubuntu - beaver if it still helps01:18
CarlFKshorne: happy to try things, run scripts, etc.  but applying patches and submitting upstream ... seems like a bad idea01:19
shorneCarlFK: Can you try out this?
tpbTitle: GitHub - stffrdhrn/qemu at litex (at
shorneI just rebased, it builds01:32
shornehad to do a bit of fixups01:32
CarlFKwoot!  Sure thing01:32
xobsMorning all01:32
shornelooks ike rebase was pretty smooth, but not sure what will happen when we try to boot the bios01:32
shorneNeed to go out for the day01:33
xobsI can say with confidence that Ubuntu 18.04 is full of issues and seems like it was shipped in a beta state.01:33
xobsmithro, was there anything you wanted me to do with the etherbone stuff?  Making libraries and such?01:33
mithroxobs: Well, I think we should have a good library somewhere :-P01:34
mithroxobs: And at the moment, it seems like you'll be the most likely to write one :-)01:34
CarlFKshorne: should I report errors here or #qemu?01:39
CarlFKhm,m they may become mithro thins real soon , so here: util/memfd.c:40:12: error: static declaration of ‘memfd_create’ follows non-static declaration01:39
CarlFKmithro: getting your qemu fork to build01:40
CarlFKshorne: Ubuntu 18.04.1
tpbTitle: Ubuntu Pastebin (at
xobsCarlFK: Seems like a glibc-2.27 bug.  Here's a build patch that purports to fix it:
tpbTitle: [OE-core] [PATCH] qemu: fix memfd_create with glibc 2.27 (at
xobsThe big change seems to be to modify util/memfd.c to remove "#include <sys/memfd.h>"01:48
CarlFKxobs: the hope was that got applied by: (08:26:52 PM) shorne: I just rebased, it builds01:49
CarlFKand this means I can go grab some food now:  (08:27:43 PM) shorne: Need to go out for the day01:50
shorneCarlFK: hmm, thats the same failure as before01:52
shornemy for should have it fixed01:52
shorneare you on01:53
shornegit log --oneline -n301:53
shorneb427eaf359 (HEAD -> litex, shorne/litex) litex: or32 -> or1k in litex build script01:53
shornee29e8336cf litex: Ename I2C for openrisc to allow build to link01:53
shorneoh... ok thats just your conversation with xobs01:54
CarlFKshorne: yep02:01
CarlFKer, wait...02:01
CarlFK[email protected]:~/qemu$ git log --oneline -n302:02
CarlFKf90ea7ba7c (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20171012' into staging02:02
CarlFKcf5f7937b0 nvic: Fix miscalculation of offsets into ITNS array02:02
CarlFKa94bb9cd58 nvic: Add missing 'break'02:02
CarlFKahk litex brancy02:03
*** Kripton has quit IRC02:07
*** Kripton has joined #timvideos02:07
CarlFKshorne: next up: I'll test mithro's process
tpbTitle: HowTo LCA2018 FPGA Miniconf · timvideos/litex-buildenv Wiki · GitHub (at
*** roger_rabbit has joined #timvideos02:15
*** rohitksingh has joined #timvideos02:15
*** roger_rabbit has quit IRC02:16
CarlFKshorne:   LINK    alpha-softmmu/qemu-system-alpha02:17
CarlFK../hw/i2c/bitbang_i2c.o: In function `gpio_i2c_init':02:17
CarlFK/home/juser/qemu/hw/i2c/bitbang_i2c.c:234: undefined reference to `i2c_init_bus'02:17
tpbTitle: Ubuntu Pastebin (at
*** rohitksingh has quit IRC02:25
*** nitrix19 has joined #timvideos02:25
*** monoxane14 has joined #timvideos02:26
*** nitrix19 has quit IRC02:26
shorneCarlFK: hmm, why are you building alpha-softmmu02:27
shornefor some reason link now required CONFIG_I2C02:28
CarlFKshorne: umm, I just did ./configure;make02:28
shorneI guess everything now requires CONFIG_I2C ... which is wrong02:28
shornefor my build i did  configure --target-list=lm32-softmmu,or1k-softmmu02:29
shornewhich enables or1k and lm32,  which both have CONFIG_I2C enabled, which allows for the linking02:29
shornemabye this was broken before, but because we only enable lm32 and or1k its not an issue02:30
CarlFKtrying that - and I'll dig into the build script I hope to get working02:31
*** monoxane14 has quit IRC02:31
shorneCarlFK: can you try with the --larget-list option?   I updated the build scripts02:31
shornethe build script should work too... but it requires the whole litex environment02:31
shornealso  you cant just build outside the environment, because   litex depends on 'generated/csr.h'02:31
CarlFKyeah - I've set it up a few times in the last few weeks02:31
shorneI mean 'you can just build qemu outside the environment' ...02:32
shorneFor me I just created a 'generated/csr.h' in my build directory to work around it02:33
shornejust contains02:33
shorne#ifndef LITEX_CSR02:33
shorne#define LITEX_CSR02:33
shorne#define CONFIG_CPU_RESET_ADDR 0x10002:33
CarlFKwhat do I do with  --larget-list ?02:34
shorne                ../configure \02:34
shorne                                --target-list=lm32-softmmu,or1k-softmmu \02:34
shorne                                --python=/usr/bin/python2 \02:34
shorne                                --enable-fdt \02:35
shorne                                --disable-kvm \02:35
shorne                                --disable-xen \02:35
shorne                                --enable-debug \02:35
shorne                                --enable-debug-info02:35
shorneyou can run configure like that... I did it in a directory called 'build-litex'02:35
shornetarget-list not larget-list ?02:35
shorneI didnt do the --python option02:35
CarlFKok, got it02:35
CarlFK No such file or directory  #include "generated/mem.h"02:38
CarlFKCC      lm32-softmmu/hw/litex/hw.o   /home/juser/qemu/hw/litex/hw.c:20:1002:38
CarlFKer wait..02:39
tpbTitle: Ubuntu Pastebin (at
shorneyeah, sorry you need to created a 'generated/mem.h' too02:40
shornealongsize the csr.h02:40
shorneyou can just make it blank02:40
shornebut rally, we need to build in the litex environment02:40
CarlFK   cc1: all warnings being treated as errors02:43
tpbTitle: Ubuntu Pastebin (at
shorneok, those are lm32 issues... i didnt try building it02:48
shorneI know it I fixed on or1k02:48
shornegive me a second02:48
*** futarisIRCcloud has quit IRC02:50
shorne#define ROM_BASE 0x002:53
shorneto csr.h (probably should be in mem.h) but just there for quick hack02:53
CarlFK‘ROM_SIZE’ undeclared02:56
CarlFKadded #define ROM_SIZE 0x0, now:
tpbTitle: Ubuntu Pastebin (at
shorneyeah, I have some more patches02:58
shornenow lm32 needs CONFIG_I2C also02:58
shornegive me a minutes I will post the patch02:59
shorneI see, this bigbang i2c needs a config param03:04
*** futarisIRCcloud has joined #timvideos03:05
shornegit lo03:10
shorne01486aa52e (HEAD -> litex, shorne/litex) litex: Fix I2C configs to be configurable03:10
shorne888c05f1aa litex: Update lm32 litex as per new API's03:10
shorneI pushed a few fixes03:10
shorneb427eaf359 litex: or32 -> or1k in litex build script03:10
shorneCarlFK: you can try that, I fixed the alpha build issue03:11
shornealso, lm3203:11
shorneWe need to really clean up these patches03:11
*** thaytan has quit IRC03:11
CarlFKshorne: woot, completed. ./configure --target-list=lm32-softmmu,or1k-softmmu; make03:13
CarlFKtrying litex-buildenv$ vim ./scripts/ now03:13
shorneI noticed that the CSR/MEM configs uncover a bit of code.. it might cause some issues03:14
shornemight now03:14
shornemight not*03:14
*** thaytan has joined #timvideos03:16
*** ChanServ sets mode: +v thaytan03:16
CarlFKmithro: yo script don't work :p03:17
CarlFK+ QEMU_REMOTE=  good03:17
tpbTitle: GitHub - stffrdhrn/qemu: Official QEMU mirror. Please see for how to submit changes to QEMU. Pull Requests are ignored. (at
CarlFK+ git clone  bad!03:17
tpbTitle: GitHub - timvideos/qemu-litex (at
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
CarlFKrawr!!!! lol03:19
*** rohitksingh_work has joined #timvideos03:20
shorneCarlFK: I think you can just fix line 4403:22
CarlFKshorne: you would think...03:22
CarlFK./scripts/ line 45: cd: /home/juser/litex-buildenv/third_party/qemu-litex: No such file or directory03:23
tpbTitle: qemu-litex/ at master · timvideos/qemu-litex · GitHub (at
shorneah... problem is my fork is not 'qemu-litex' just qemu03:23
shorneso the directory doesnt match03:23
CarlFKyeah - im sure theres another var I have to set03:24
CarlFKmithro:  Run the ./ which will ... error :p03:24
mithroWhat is the error?03:25
CarlFKmithro: because i:  export QEMU_REMOTE=
tpbTitle: GitHub - stffrdhrn/qemu: Official QEMU mirror. Please see for how to submit changes to QEMU. Pull Requests are ignored. (at
shorneCarlFK: QEMU_SRC_DIR=$TOP_DIR/third_party/qemu03:25
CarlFKshorne: im trying not to break the defaults03:26
mithroDifferent scripts?03:26
shorneWe might want to define 'QEMU_SRC_DIR=${QEMU_SRC_DIR:-$TOP_DIR/third_party/qemu-litex}'03:27
CarlFKmithro: start by looking at the first and last line of
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
shorneCarlFK: line 44 could actually be correct, but we can remove the 'else'03:28
shornei.e. 1. clone timvideos/litex-qemu as 'origin'03:28
shorne2. (the else part) add stffrdhrn as remote and check it out03:29
shornethat way the directory structure qemu-litex is maintained by the timvideos repo03:29
*** esden has quit IRC03:30
shornewould need remote name QEMU_REMOTE_NAME=stffrdhrn03:30
shornejust an idea to workaround me having a different repo name03:31
*** olasd has quit IRC03:32
CarlFKthis might "work" export QEMU_REMOTE=" litex-qemu03:34
tpbTitle: GitHub - stffrdhrn/qemu: Official QEMU mirror. Please see for how to submit changes to QEMU. Pull Requests are ignored. (at
CarlFK+ git clone litex-qemu03:34
CarlFKCloning into 'litex-qemu'...03:34
tpbTitle: GitHub - stffrdhrn/qemu: Official QEMU mirror. Please see for how to submit changes to QEMU. Pull Requests are ignored. (at
CarlFKta da! :p03:34
CarlFKdoh.  qemu-litex not litex-qemu03:35
shornesorry, I flipped it a few times too03:36
shorneyeah, thats better03:36
CarlFKERROR: Unknown target name 'or32-softmmu'03:36
CarlFKconfigure --target-list=or32-softmmu --python=/usr/bin/python2 --enable-fdt --disable-kvm --disable-xen --enable-debug --enable-debug-info03:37
shornehmm, I thought I removed the or32 stuff03:39
shornecan you trace where it came from?03:39
*** olasd has joined #timvideos03:39
shorneit changed in qemu from or32 to or1k03:39
shorneI updated the build script for it too03:40
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
shornewe can change that line03:41
CarlFKyeah - just saw that03:41
CarlFKcrud - my git qemu-litex hack breaks this case git remote add timvideos-qemu-litex qemu-litex03:42
tpbTitle: GitHub - stffrdhrn/qemu: Official QEMU mirror. Please see for how to submit changes to QEMU. Pull Requests are ignored. (at
shorneyou can hard code qemu-litex03:44
CarlFKIn file included from /home/juser/litex-buildenv/third_party/qemu-litex/hw/litex/hw.c:19:0:03:44
CarlFK../generated/csr.h:3:10: fatal error: hw/common.h: No such file or directory03:44
*** esden has joined #timvideos03:44
shornegit clone $QEMU_REMOTE qemu-litex03:45
shorneon line 4403:45
CarlFKah right03:45
CarlFKshorne: whos problem is that ^^
tpbTitle: Ubuntu Pastebin (at
shorneCarlFK: looks like litex is expecting a hw/common.h from qemu03:49
shornemaybe its gone now03:49
shornelet me see03:49
shornehmm, its still there03:50
shornels -l hw/common.h03:51
shorne-rw-rw-r--. 1 shorne shorne 157 Sep  5 09:23 hw/common.h03:51
shornein qemu root, on branch litex03:51
shornedid you not get the litex branch checked out?03:51
shorneCarlFK: ^03:51
shornehw/common.h is something added for litex03:52
CarlFKI did.. export QEMU_BRANCH=litex   ... lets see if the script echo uses it like we expect...03:52
CarlFKBranch 'litex' set up to track remote branch 'litex' from 'origin'.03:54
*** Kripton has quit IRC03:56
shorneCarlFK: I think this part should be outside of the elf03:56
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
CarlFKshorne: move it to 69 and add ( cd $QEMU_SRC_DIR  .... ) ?03:58
shorneI think the ( cd $QEMU_SRC_DIR ) is done inside already03:59
shornenot needed03:59
CarlFKum... the  git checkout $QEMU_BRANCH needs to happen in QEMU_SRC_DIR,04:00
shornebut yes, just move it04:00
shornebut we can see in got if and else we do cd..04:00
shorneoh... but its in a ()04:00
shorneso its a different context04:00
shorneok, yes04:00
shorneUsually I dont use the ( )04:01
*** Kripton has joined #timvideos04:02
CarlFKshorne: still erroring :
tpbTitle: Ubuntu Pastebin (at
shorneCarlFK: ok, I see CC      or1k-softmmu/hw/litex/hw.o, so its a litex branch04:07
shornemaybe qemu root is not added to the include path any more04:07
shorneand it was before04:07
shornegive me a minute04:07
shorneok... it seems we will need to change it to '#include "hw/common.h"'04:19
shornenot <hw/common.h>04:19
shornebut.. it shouldnt really matter04:20
shornebut, the hw/common.h file should be in a different place04:20
shornei.e. under include04:23
shorneCarlFK: right, we dont need to move it just yet, but we need to change it to '#include "hw/common.h"' for qemu04:28
shornedue to patch:04:31
tpbTitle: make: switch from -I to -iquote · stffrdhrn/[email protected] · GitHub (at
CarlFK  hw/litex/hw.c:186:71: error: ‘serial_hds’ undeclared (first use in this function04:32
tpbTitle: Ubuntu Pastebin (at
shorneI thought I removed that04:32
shorneoh... because CSR_UART_BASE04:33
shornegit lo04:35
shorne43cff55845 (HEAD -> litex, shorne/litex) litex: serial_hds[] to serial_hd()04:35
shorneI pushed the fix for that04:35
CarlFKshorne: I think I see "git fetch" should get it.. but
tpbTitle: Ubuntu Pastebin (at
CarlFKI am a little surprised it didn't colide with change it to '#include "hw/common.h"' for qemu04:38
shorneCarlFK: this last one is a bit tricky its due to -drive serial=xx command line option being deprecated05:01
shorneso we need to proably change the command line options being sent to qemu05:02
shornei.e. we cant do this anymore05:03
shorneEXTRA_ARGS+=("-drive if=mtd,format=qcow2,file=$TARGET_BUILD_DIR/qemu.qcow2,serial=$SPIFLASH_MODEL")05:03
shorne^ from build-qemu.sh05:05
CarlFKshorne: obvious question: what replaced it?05:11
shorneCarlFK: they are saying now we should do something like '-device m25p80,drive=mtd'05:28
shorneor something05:28
shorneI dont quite under stand the qemu options :(05:28
shornefor now I just used our default05:28
shorneit might be wrong05:28
shornegit lo05:29
shorne58e6bd5b3e (HEAD -> litex, shorne/litex) litex: HACK: Disable drive serial option, deprecated05:29
shorne43cff55845 litex: serial_hds[] to serial_hd()05:29
shorneI pushed the compile fix05:29
CarlFKmithro: you might be interested in this: (11:56:31 PM) shorne: CarlFK: this last one is a bit tricky its due to -drive serial=xx command line option being deprecated05:29
CarlFKwhat's the difference between git pull and git fetch origin ?05:35
shorneCarlFK: pull, merges the changes into your current directory05:39
shornefetch just gets the changes to your computer, but your current directory doesnt update05:39
*** CuriousLearner has quit IRC05:39
shorneyou need a 'merge', or 'pull' to update the current working directory copy05:40
CarlFK 59         # Get any new data05:40
CarlFK 60         git fetch $CURRENT_QEMU_REMOTE_NAME05:40
CarlFKthank got we got it :p05:40
*** rails has quit IRC05:40
shorneah, thats why you were missing the serial_hd changes05:40
CarlFKwoot - made it to the end05:42
CarlFKthe script errored, but this is expected : qemu-system-or1k: -drive if=mtd,format=qcow2,file=build/arty_net_or1k//qemu.qcow2,serial=n25q128a13: Block format 'qcow2' does not support the option 'serial'05:43
shorneyes, I think we can just try to remove05:47
shorneIf you want to try something like -device=n25q128a13... it might work too05:48
shornebut not sure how the device is tied to the drive05:48
CarlFKqemu-system-or1k: -device=n25q128a13: invalid option05:50
shorneJust try to remove for now05:50
*** jeggott25 has joined #timvideos05:51
CarlFKqemu-system-or1k: /home/juser/litex-buildenv/third_party/qemu-litex/exec.c:2008: qemu_ram_set_idstr: Assertion `!new_block->idstr[0]' failed.05:51
CarlFKbuild/arty_net_or1k//qemu/or1k-softmmu/qemu-system-or1k -M litex -nographic -nodefaults -monitor telnet::10000,server,nowait -serial stdio -bios build/arty_net_or1k//software/bios/bios.bin -drive if=mtd,format=qcow2,file=build/arty_net_or1k//qemu.qcow2 -net nic -net tap,ifname=tap0,script=no,downscript=no -gdb tcp::1000105:51
*** jeggott25 has quit IRC05:51
shornehmm, seems something missing in litex/hw.c06:08
shornei.e. namking the memory06:08
shornemaybe we should not be naming it06:08
shornenot, sure about this one I would need to debug06:17
CarlFKwould ssh into my build box help?06:23
shornehmm, I could run on my machine, but done have much time, I guess it will help06:29
CarlFKssh -p 18822 [email protected]06:32
CarlFKi grabbed your public key from github06:32
shorneok, let me try06:39
shornehmm, its asking me for a password06:41
shorneeven if I provide my own identity file06:41
shornedid you get ssh-rsa?06:41
CarlFKI got these:
tpbTitle: Ubuntu Pastebin (at
shorneim in06:42
CarlFKshorne: have you been though the setup?  either way, here is what I did to get 'there'
tpbTitle: HowTo LCA2018 FPGA Miniconf · timvideos/litex-buildenv Wiki · GitHub (at
shorneok, issue with with liteeth_init06:46
shorneI have been through setup before06:46
shorneI debugged, it is initting qemu_ram_set_idstr (new_block=0x555556334130, name=0x555556333fc0 "liteeth.buffers", dev=0x555556330300)06:46
shorneits doing the same 1 2 times06:47
*** sc00bz1 has joined #timvideos06:50
*** sc00bz has quit IRC06:52
shorneCarlFK: ok... the assert should be fixed06:53
shorneI pushed a fix06:54
shorneyou want to try the build again?06:54
CarlFKIn file included from /home/juser/litex-buildenv/third_party/qemu-litex/hw/litex/hw.c:19:0:06:54
CarlFK../generated/csr.h:3:10: fatal error: hw/common.h: No such file or directory06:54
CarlFKI see it got this:  hw/net/liteeth.c | 3 ++-06:55
tpbTitle: Ubuntu Pastebin (at
shornehmm, we should see that anymore07:00
shorneah... unless you need to update the include07:01
shornei.e. it should be #include "hw/common.h" in the csr.h07:01
shorneCarlFK: it might have been regenerated07:01
CarlFKah, that's part of mithro's script?07:02
CarlFKI'll track that down07:08
shornesomewhere in the python I think how did you fix it before?07:08
CarlFKvim ...07:08
shorneI see07:08
CarlFK        r += "#include <hw/common.h>\n"07:13
CarlFKhmm, not sure how to force that run...07:14
CarlFKoh swell, 30 min ago in #v4l (01:33:20 AM) hverkuil1: can't be reached anymore, did something happen?07:16
CarlFKand now to test the changes I made I cant run ./scripts/ fatal: clone of ' ...07:17
CarlFKlets see if make clean cleans it enough...07:19
CarlFKswell.  Makefile:507: recipe for target 'subdir-capstone' failed07:20
shornemaybe its time for bed?07:25
CarlFKrm third_party/litex-qemu/ -rfrm third_party/litex-qemu/ -rf ... Makefile:941: recipe for target 'qemu-doc.txt' failed07:25
CarlFKlol - yeah, 2am.  bed time was about an hour ago07:25
shorneI think you need to delete the build dir too07:25
shornewhich has the Makefile07:25
shornebuild/qemu or something07:26
CarlFKMakefile:214: recipe for target 'accel/kvm/trace.c-timestamp' failed07:27
shornesomething is out of sync07:28
*** GingerGeek has joined #timvideos08:15
*** GingerGeek has quit IRC08:18
*** futarisIRCcloud has quit IRC09:14
CarlFKmithro: here's a PR cuz I don't know what repo it is from :p09:56
tpbTitle: Ubuntu Pastebin (at
CarlFKmithro: because (11:23:25 PM) shorne: CarlFK: right, we dont need to move it just yet, but we need to change it to '#include "hw/common.h"' for qemu
tpbTitle: make: switch from -I to -iquote · stffrdhrn/[email protected] · GitHub (at
*** ivodd has quit IRC10:05
*** ivodd has joined #timvideos10:26
*** ivodd has quit IRC10:57
*** ivodd has joined #timvideos11:32
*** felix_ has quit IRC12:11
*** felix_ has joined #timvideos12:18
*** rohitksingh_work has quit IRC12:30
*** sc00bz1 is now known as sc00bz13:22
*** waldo323 has joined #timvideos14:52
CarlFKmithro: I think I just deleted - but I also just made a fork...17:04
*** aps__ has joined #timvideos17:20
*** aps__ is now known as aps-sids17:23
*** aps-sids is now known as aps17:24
*** aps has quit IRC17:27
tinyfpgamithro: anyone doing unit tests with migen/litex?17:30
tinyfpgamithro: I think I need to rewrite my USB PHY in migen17:30
tinyfpgamithro: and I want to unit test each little block17:30
tinyfpgamithro: formal would also be slick17:31
*** Kripton has quit IRC17:35
*** Kripton has joined #timvideos17:39
cr1901_moderntinyfpga: formal will happen soon enough... until then look at the migen unit tests and sim examples for ideas17:43
cr1901_modernpython3 -m unittest will automatically look for a test subdir17:43
tinyfpgacr1901_modern: great, thanks!!17:43
*** aps has joined #timvideos17:47
*** rohitksingh has joined #timvideos18:23
*** rohitksingh has quit IRC18:36
*** rohitksingh has joined #timvideos18:37
*** rohitksingh has quit IRC18:51
*** rohitksingh has joined #timvideos18:56
*** rohitksingh has quit IRC19:06
mithroCarlFK: This is pretty bad...20:12
mithroCarlFK: When you delete a repo, it makes you enter the name of the repo...20:12
mithroCarlFK: I can get the code back, but things like issues, wiki, forks, etc are going to be problematic...20:14
mithroCarlFK: I've contacted support but I'm not hopeful20:18
CarlFK[m]Oh crap.  Issues.20:19
mithroCarlFK[m]: Yes, this is bad :-(20:20
CarlFK[m]mithro: it asks for the name of the repo, but not the name of the account, that is where things went South20:21
mithroCarlFK[m]: Nope, it asks for the full name - user/repo....20:21
tpbTitle: recovery - Recover a deleted repository github issues - Stack Overflow (at
_florent_support should be able to get it back20:27
mithro_florent_: emailed....20:27
CarlFK[m]After about 10 minutes the support replied and the original repository was recovered.20:29
CarlFK[m]Me crosses fingers20:29
CarlFK[m]I hit the contact us link and sent something too.20:30
mithroIt's back!21:14
CarlFKok, back to that PR21:36
*** aps has quit IRC21:40
cr1901_modernGood thing there seems to be a grace period before true deletion21:41
mithro_florent_: What is minerva? Seems to be another RISC-V CPU?21:47
mithroMinerva enables highly accurate, ultra-low power DNN accelerators (in the range of tens of milliwatts), making it feasible to deploy DNNs in power-constrained ... ?21:48
_florent_mithro: yes another RISC-V CPU (still experimental), but this one has something particular if you look at the cpu file :)21:50
mithrofrom minerva.core import Minerva as MinervaCPU ?21:51
cr1901_modernit's written in litex?21:51
mithro_florent_: Can't see where that comes from :-P21:52
_florent_cr1901_modern: migen yes21:52
mithro_florent_: I can't seem to find anything about the core?21:53
_florent_the code is not released yet21:54
cr1901_modern_florent_: Oh so this is _your_ riscv core :)?21:55
mithrocr1901_modern: How goes the ice40?22:00
cr1901_modernmithro: I ran into some consistency issues getting the design to route, so instead of doing what a rational person would do and just lower the clock speed, I tested some PLL configs and made a table of results22:01
cr1901_modernI should have booting litex-buildenv firmware by tonight22:01
mithro_florent_: At some point we should change litex so CPUs can just register themselves with litex so it doesn't need to change with every CPU configuration / variant / type22:08
CarlFKmithro: should I try to change the name on this commit from Joe User to me?
tpbTitle: Commits · CarlFK/litex-buildenv · GitHub (at
CarlFKmithro: can you take care of this one:
tpbTitle: Ubuntu Pastebin (at
cr1901_moderntinyfpga: Would you expect the warning to come up given this command line invocation of tinyprog?
tinyfpgacr1901_modern: the new safety checks ensure that anything you program with -p stays within the user bitstream area, and anything you program with -u stays within the user data area22:34
tinyfpgacr1901_modern: it’s needed because images that are too large can wrap around and overwrite the bootloader22:34
tinyfpgacr1901_modern: and right now the metadata doesn’t advertise the total size of the SPI flash22:35
tinyfpgacr1901_modern: if you are writing into the user data area, use -u along with the address22:35
cr1901_moderntinyfpga: Okay fair enough, but there is an issue w/ how litex-buildenv and HDMI2USB interacts with this (cc: mithro)22:35
cr1901_modernNormally, a litex-buildenv image consists of 2 or 3 parts: bitstream (BIOS embedded), bios, and payload22:36
cr1901_modernthey are typically concatenated into one file using a script called ""22:36
cr1901_moderntinyfpga is the first FPGA we have that is smart enough to not require this, but I'll have to somehow "notify" the top level makefile that tinyfpga doesn't need this22:37
cr1901_modern(specifically the BX series is smart enough :)...)22:37
*** CarlFK has quit IRC22:58
mithrocr1901_modern: why can't you just give it the image?23:00
cr1901_modernmithro: >(6:29:03 PM) tinyfpga: cr1901_modern: the new safety checks ensure that anything you program with -p stays within the user bitstream area23:01
cr1901_modernwhat happens if the bitstream + bios + payload exceeds the user bitstream area?23:02
mithrocr1901_modern: But isn't the "user bistream area" everything after the boot bitstream?23:02
cr1901_modernNo, it's up to address 0x5000023:02
cr1901_modernthen the "user data area" follows, which _is_ the rest of the spi flash23:03
tinyfpgamithro: there are two user areas, user bitstream and user data23:03
mithrotinyfpga: Out of interest, can the ice40 multiboot more than 2 images?23:04
tinyfpgamithro: up to 4 images23:04
mithrotinyfpga: So there are 3 user images and then user data?23:04
tinyfpgamithro: no, the BX is configured for 1 user image and one user data area23:05
cr1901_modernmithro: the first bitstream on tinyfpga is the bootloader. You don't want to touch that.23:05
cr1901_modernthe second bitstream is your application23:05
mithrotinyfpga: My first boot image can't boot another boot image?23:05
tinyfpgamithro: that would require changes to the bootloader area23:06
cr1901_modernafter the second bitstream, you can put "whatever data you want", but the tinyfpga bootloader doesn't know how to boot more than two images (itself and ONE user image)23:06
tinyfpgamithro: you can do it, but you have to rebuild your own multiboot image including the bootloader23:06
cr1901_moderntinyfpga: Oh, the bootloader uses both pins of the SB_WARMBOOT primitive?23:07
tinyfpgacr1901_modern: no, the bootloader only knows how to23:07
tinyfpga...boot the user image23:07
tinyfpgacr1901_modern: but if you build your own multiboot image and include the bootloader and your own images, then the first user image could then load a second and/or third user image23:08
tinyfpgacr1901_modern, mithro: this involves overwriting the bootloader...I don’t recommend it for anyone that is not willing/able to reprogram the SPI flash directly23:09
cr1901_modernright... if you don't have the proper header, the FPGA will look for the image at a garbage address and go into the weeds IIRC23:10
tinyfpgacr1901_modern, mithro: I don’t believe it is safe to assume you have free space after the user image, some of the multi-image tools for FPGAs may place other things like a golden boot image after the user image23:10
tinyfpgacr1901_modern, mithro: the usb bootloader wolves this by advertising where you can put the user image and where you can put all other user data23:11
cr1901_modernwhat is a golden boot image?23:11
mithrotinyfpga: We need to know the SPI address of the user data23:12
tinyfpgacr1901_modern: it’s a feature ECP5 has. It will load the golden image of the default image fails CRC checks23:12
cr1901_modernmithro: You can _get_ the SPI address of the user data23:12
cr1901_moderntinyprog will return that info for you in json format23:12
tinyfpgamithro: you can use the -m option and tinyprog will output the JSON metadata from the FPGA board23:12
cr1901_modernof course, calling out to tinyprog is kinda ugly23:13
cr1901_modernBut for BX the user data is at 0x5000023:13
mithrotinyfpga: We build images on CI without any FPGA plugged in...23:13
mithrotinyfpga: It is likely in the near future we will want to create our own multiboot gateware23:13
* cr1901_modern leaves you two to battle this out :D23:13
tinyfpgamithro: for any given FPGA board the address should stay the same23:13
cr1901_modernI'm actually not all that useful for feedback at this point. My recommendation is to relax the requirement that the gateware + bios + payload need to be concatenated together23:14
mithrocr1901_modern: Well, the bios + payload need to be concatenated together?23:15
*** futarisIRCcloud has joined #timvideos23:15
cr1901_modernmithro: Nothing stops be from assigning a flash_boot_address different from "just after the bios"23:16
cr1901_modernwe can arbitrarily declare "for tinyfpga, the payload goes at 0x60000"23:16
cr1901_modernthat gives plenty of room for the BIOS23:16
cr1901_modernand we use tinyprog to program "two sections of user data": One at 0x50000 for the BIOS, one at 0x60000 for the payload23:17
mithrotinyfpga: FYI - It's a *huge* pain to provide users with two files :-)23:17
mithrotinyfpga: Because they update one and then forget to update the second one23:17
cr1901_modernmithro: Errr, that problem is going to exist once the XMODEM stuff gets loaded anyway23:18
cr1901_moderngets merged*23:18
mithrotinyfpga: Maybe we could just have an "image file format" ?23:18
cr1901_modernmithro: Could you possibly give tinyfpga a walkthrough of "how are images flashed in litex-buildenv" at present? B/c I forget :P. Normally bios is part of bitstream, so you concat bitstream + payload. mimasv2 is special.23:20
cr1901_modernAnd Idk how the build system knows that mimasv2 is special23:20
tpbTitle: Images · timvideos/litex-buildenv Wiki · GitHub (at
cr1901_modern>We still leave the space for the BIOS in the image, even though it isn't used.23:22
cr1901_modernOh right, I forgot about this23:22
mithroSomething I prepared earlier :-P23:22
cr1901_modern>FIXME: The firmware image header makes execute in place harder?23:23
cr1901_modernYes, this. I have managed to crash tinyfpga b/c I didn't begin executing on a cache line boundary on the reset vector. I haven't tried yet, but I'm concerned the header will also duplicate this crash.23:23
tinyfpgamithro: I can change the safety check, or add a --force option23:24
mithrotinyfpga: Maybe just add an "--image" option?23:25
tinyfpgamithro: I think it’s better if I just change the check...I can make it allow both the user bitstream and user data areas to be ok to program whether you are using the -p or -u options23:26
mithrotinyfpga: Well, I think from a "know WTF the user is doing" have -p, -u and -i options would be better -- "-i" signals the intent that I want to flash both bitstream and userdata together23:27
mithrotinyfpga: While the other options signify that "this should be a bitstream only" or "this should be user data only"23:27
cr1901_modernI like this compromise23:27
mithrotinyfpga: Then you can provide helpful error messages like "this bitstream doesn't look like a bitstream, did you mean -u" or "this user data kind of looks like a bitstream, did you mean -p"23:28
cr1901_modern"-i" option disables the checks except for the bootloader region23:28
cr1901_modernAnd also provide a helpful "Do not use this option unless you know what you're doing" blurb :P23:29
cr1901_modernb/c we- well, some of us- know what we're doing23:29
mithrotinyfpga: The more helpful the error messages, the less you'll get support requests  :-P23:30
tinyfpgamithro: ok, I like that option23:31
mithrotinyfpga: FYI -
tpbTitle: HDMI2USB-mode-switch/ at master · timvideos/HDMI2USB-mode-switch · GitHub (at
mithrotinyfpga: I wrote that after23:32
mithro (a) flashing a HTML file to my FPGA multiple times and wondering why it didn't work23:32
mithro (b) Always flashing / loading the wrong one of the .bit and .bin files23:33
mithroNow my tool says "You silly human, your doing the wrong thing again" :-P23:33
tinyfpgamithro: nice23:36
mithrotinyfpga: I recommend doing something like that for the -b option23:41
cr1901_modern? The -b option just boots the FPGA23:41
mithrotinyfpga: As the "I download this image and got redirected to a HTML page which I then flashed to my device" is an *actual thing* I have done as an experienced user :-P23:42
mithrocr1901_modern: Opps -p23:42
tinyfpgamithro: yeah, I think there’s an easy way to check the iCE40 bitstream23:50
cr1901_modernAnd the best part is, tinyprog is open source, so if you want to disable all the pesky safety checks, you are free to modify and install your own version :)23:51

Generated by 2.13.1 by Marius Gedminas - find it at!