| *** tpb has joined #tomu | 00:00 | |
| *** GNUtoo has joined #tomu | 00:03 | |
| *** andi- has quit IRC | 00:20 | |
| *** andi- has joined #tomu | 00:25 | |
| *** st-gourichon-fid has quit IRC | 00:58 | |
| *** emeb has quit IRC | 01:20 | |
| *** st-gourichon-fid has joined #tomu | 01:29 | |
| mithro | esden: I think you have made it! -> https://www.aliexpress.com/item/4000260409783.html | 02:21 |
|---|---|---|
| tpb | Title: iCEBreaker 1.0e FPGA Development Board RISC V Development Board Core Board on AliExpress (at www.aliexpress.com) | 02:21 |
| esden | yeah someone told me about it at the congress... trying not to think about it to be honest. | 02:23 |
| esden | Especially I hate the fact that they just copied all the assets from CrowdSupply :( | 02:24 |
| esden | how lazy can you be... | 02:24 |
| mithro | esden: It means that the icebreaker is successful enough for that to happen | 02:45 |
| esden | Yeah I hear people say that... :D | 02:46 |
| daurnimator | you really... broke the ice | 02:55 |
| *** rohitksingh has joined #tomu | 03:00 | |
| *** im-tomu has left #tomu | 03:17 | |
| *** im-tomu has joined #tomu | 03:17 | |
| *** rohitksingh has quit IRC | 04:10 | |
| mithro | esden: have you looked at the Fomu workshop recently? | 04:17 |
| esden | I went through it about a week ago until my Fomu broke. I will play more soon. Fortunately I have more than one Fomu :) | 04:18 |
| mithro | It has a lot of the stuff you where talking about on your Twitter thread | 04:24 |
| mithro | esden: I think it would be pretty easy to do a version for the icebreaker | 04:24 |
| mithro | esden: the new UART support xobs did in wishbone tool means you could have the power of it via the UART and still have a terminal | 04:26 |
| esden | yeah xobs | 04:29 |
| esden | he told me that he added UART support | 04:29 |
| esden | I was planning to start with your fomu stuff anyways... :) | 04:30 |
| esden | The poll was mainly because of my twitch streams. This inspired me to ask and see what people are most interested in regarding toolkit/programming environment/language... | 04:30 |
| esden | And that too, I will definitely want to "port" the fomu workshop to the icebreaker when we have all the underlying things working on it. | 04:31 |
| xobs | daurnimator: okay for me to merge zig support? | 05:40 |
| daurnimator | xobs: sure. | 05:42 |
| daurnimator | xobs: did you manage to replicate it for yourself? | 05:42 |
| daurnimator | xobs: there is the open comment there asking if I need clobbers..... I don't know | 05:43 |
| xobs | I'm not sure if you need clobbers. I mean, it does clobber $a0 and $a1, but those are the argument registers, and it's a pure asm function. | 05:44 |
| daurnimator | documentation for clobbers for riscv is a TODO in llvm docs >.< | 05:44 |
| kevans91 | pure asm inlined into C, or pure non-inline asm? | 05:53 |
| daurnimator | kevans91: non-volatile inline asm into zig | 05:54 |
| kevans91 | I guess the latter probablt doesn't do clobbees | 05:54 |
| daurnimator | kevans91: https://github.com/im-tomu/fomu-workshop/pull/140/files#r371276643 | 05:54 |
| tpb | Title: Add zig example by daurnimator · Pull Request #140 · im-tomu/fomu-workshop · GitHub (at github.com) | 05:54 |
| kevans91 | the real question is whether there's a chance the compiler will try to do some shady optimization around it, but I would think the answer's a no given the context | 05:56 |
| xobs | daurnimator: I checked in an attempted fix for the stairstep pattern you see in messible output. | 07:16 |
| *** rohitksingh has joined #tomu | 12:38 | |
| *** futarisIRCcloud has quit IRC | 13:29 | |
| *** futarisIRCcloud has joined #tomu | 13:29 | |
| *** spacekookie_ is now known as spacekookie | 13:51 | |
| st-gourichon-fid | Hi. Just to notify xobs and others: upgrading bootloader from 1.7.3 to 2.0.3 fixed the wishbone tool not working. | 14:02 |
| st-gourichon-fid | On FOMU. | 14:02 |
| xobs | Oh good. Yay! | 14:03 |
| st-gourichon-fid | It's a FOMU hacker, experimenting with default CPU. It looks like running code (added to riscv-blink) is slow. | 14:06 |
| st-gourichon-fid | Could it be slow because code runs from flash without any cache? Would it run much faster from RAM? | 14:07 |
| st-gourichon-fid | To run it from RAM, I'm considering adjusting the linker scripts, and maybe I have to adjust the crt0, too. | 14:08 |
| st-gourichon-fid | Could it be slow because code runs from flash without any cache? Would it run much faster from RAM? | 14:08 |
| xobs | It definitely would. You can place code in ram by adding `__attribute__((section(".ramtext")))` to functions. | 14:08 |
| st-gourichon-fid | Great! Much simpler than I expected! | 14:08 |
| st-gourichon-fid | And more flexible, too. | 14:09 |
| st-gourichon-fid | Thanks xobs! | 14:09 |
| xobs | For example: https://github.com/im-tomu/foboot/blob/57f7a8bb95eec058efe2a748f46d3fd44983b3d0/booster/src/usb-dev.c#L73 | 14:10 |
| tpb | Title: foboot/usb-dev.c at 57f7a8bb95eec058efe2a748f46d3fd44983b3d0 · im-tomu/foboot · GitHub (at github.com) | 14:10 |
| st-gourichon-fid | Thanks a lot! | 14:11 |
| st-gourichon-fid | But... it means the crt0 has to support it. | 14:11 |
| xobs | The linker script puts .ramtext in the .data section, so it'll get copied along with the rest of .data. | 14:12 |
| st-gourichon-fid | I found what you're explaining in linker.ld, yet am not faimilar with this syntax. Anyway it compiles. Let's run now. | 14:14 |
| st-gourichon-fid | Hm, have to fix other things first. | 14:26 |
| st-gourichon-fid | A question was asked last week: wish to be able to send different code on FOMU without physically unplugging/replugging it on the USB. | 14:27 |
| xobs | Write `0xac` to `0xe0006000` | 14:27 |
| st-gourichon-fid | Yes, but "wishbone-tool 0xe0006000 0xac" retries forever, which is not good for a script. | 14:28 |
| st-gourichon-fid | I can add scripting magick to kill it, but | 14:28 |
| st-gourichon-fid | is there an option to have it not retry? Could not find in args. | 14:28 |
| st-gourichon-fid | I use this now: wishbone-tool 0xe0006000 0xac & sleep 1 ; kill $! | 14:30 |
| xobs | I fixed that last week. Wtih v0.6.5 I think? Give a newer version a try. | 14:31 |
| st-gourichon-fid | Ah | 14:32 |
| st-gourichon-fid | will look, thanks. | 14:32 |
| st-gourichon-fid | I used wishbone-tool 0.6.0 . Trying to find a newer one, https://github.com/im-tomu/fomu-toolchain/releases/download/v1.5.3/fomu-toolchain-linux_x86_64-v1.5.3.tar.gz provides 0.4.7 . | 14:59 |
| daurnimator | st-gourichon-fid: what distro are you on? | 14:59 |
| st-gourichon-fid | Xubuntu 19.10. | 14:59 |
| st-gourichon-fid | I prefer to compile software rather than get binaries, maybe I compiled it. | 15:00 |
| daurnimator | st-gourichon-fid: you can download from https://github.com/litex-hub/wishbone-utils/releases | 15:00 |
| tpb | Title: Releases · litex-hub/wishbone-utils · GitHub (at github.com) | 15:00 |
| st-gourichon-fid | Ah I got it there: <get -S https://github.com/litex-hub/wishbone-utils/releases/download/v0.6.1/wishbone-tool-v0.6.1-x86_64-unknown-linux-gnu.tar.gz | 15:00 |
| st-gourichon-fid | Ah I got it there: wget -S https://github.com/litex-hub/wishbone-utils/releases/download/v0.6.1/wishbone-tool-v0.6.1-x86_64-unknown-linux-gnu.tar.gz | 15:00 |
| st-gourichon-fid | Just compiled from master on https://github.com/litex-hub/wishbone-utils/ it's 0.6.0 . | 15:03 |
| tpb | Title: GitHub - litex-hub/wishbone-utils: Utilities for working with a Wishbone bus in an embedded device (at github.com) | 15:03 |
| st-gourichon-fid | Oh sorry forgot git merge --ff-only. Now 0.6.7 . | 15:04 |
| st-gourichon-fid | It's not better "wishbone-tool 0xe0006000 0xac" still loops forever. | 15:06 |
| st-gourichon-fid | I use this now: wishbone-tool 0xe0006000 0xac & sleep 1 ; kill $! | 15:08 |
| xobs | What does `wishbone-tool --version` show? | 15:09 |
| st-gourichon-fid | Wishbone Tool 0.6.7 | 15:09 |
| xobs | Strange that it's doing that on your system. | 15:09 |
| st-gourichon-fid | Not important for me. It works, just does not quit. Script-based workaround is inelegant but I can move on. | 15:10 |
| st-gourichon-fid | Willing to send you logs or test another one later as you wish. | 15:10 |
| xobs | What do you get when you run `RUST_LOG=debug wishbone-tool 0xe0006000 0xac`? | 15:16 |
| xobs | Among other things, I get the message "USB device disconnected, forcing early return" | 15:19 |
| xobs | Or maybe you get a different "Poke failed, trying again" message. | 15:20 |
| st-gourichon-fid | https://gist.github.com/fidergo-stephane-gourichon/049156c7856477f44ddfe58fc97d7def | 15:21 |
| tpb | Title: Wishbone Tool 0.6.7 FOMU reset log. · GitHub (at gist.github.com) | 15:21 |
| st-gourichon-fid | The FOMU is reset as expected. | 15:21 |
| st-gourichon-fid | The problem is just wishbone-tool not returing. | 15:22 |
| st-gourichon-fid | Not existing. | 15:22 |
| st-gourichon-fid | Not *exiting*. ;-) | 15:25 |
| st-gourichon-fid | I'm trying to measure code execution time. Looking in riscv-blink I look at timer.c then csr.h https://github.com/im-tomu/fomu-workshop/blob/master/riscv-blink/include/generated/csr.h#L192 | 15:28 |
| tpb | Title: fomu-workshop/csr.h at master · im-tomu/fomu-workshop · GitHub (at github.com) | 15:28 |
| st-gourichon-fid | Where can I find documentation for the timer used. In theory I should start with getting the source code for this gateware. | 15:29 |
| st-gourichon-fid | ? | 15:29 |
| xobs | https://rm.fomu.im/timer0.html | 15:30 |
| tpb | Title: TIMER0 Fomu Bootloader documentation (at rm.fomu.im) | 15:30 |
| * st-gourichon-fid is looking, thanks xobs . | 15:30 | |
| xobs | Ah, Linux gives a different error than Windows. | 15:30 |
| xobs | I'll fix that tomorrow, then! | 15:35 |
| *** futarisIRCcloud has quit IRC | 15:39 | |
| st-gourichon-fid | Happy to help. You helped me more I feel. | 15:40 |
| kevans91 | yeah, I think FreeBSD returns a different error as well, but I suspect that should be fixed on the FreeBSD side if it's feasible | 15:54 |
| *** daveshah has quit IRC | 16:08 | |
| *** daveshah has joined #tomu | 16:08 | |
| *** feklee has quit IRC | 16:12 | |
| *** feklee has joined #tomu | 16:12 | |
| *** vesim has quit IRC | 16:23 | |
| *** vesim has joined #tomu | 16:24 | |
| *** rohitksingh has quit IRC | 16:25 | |
| *** GrOoVe has joined #tomu | 16:26 | |
| GrOoVe | can w e pay less than a 30 buck for a or two tomu????? | 16:26 |
| *** GrOoVe has left #tomu | 16:30 | |
| *** LWK has quit IRC | 16:50 | |
| *** LWK has joined #tomu | 16:50 | |
| st-gourichon-fid | xobs, I gain a speedup of a factor 7 by just adding the attribute __attribute__((section(".ramtext"))) to a computation-heavy function. | 16:52 |
| st-gourichon-fid | This is good. But I feel it can be faster. | 16:52 |
| st-gourichon-fid | Function does multiplications. The generated ASM calls "call__mulsi3". | 16:53 |
| st-gourichon-fid | I'm not sure how to make sure the intrinsics __mulsi3 is in RAM, too. It's out of my source code. | 16:54 |
| st-gourichon-fid | I tried gcc --save-temps and also have added a rule to Makefile to write out generated ASM. All this refers to __mulsi3 but does not show its implementation. | 16:58 |
| *** im-tomu has left #tomu | 17:00 | |
| st-gourichon-fid | Ok used objdump to disassemble generated elf. It shows __mulsi3 is in 0x20040f40 which is in flash. | 17:00 |
| *** im-tomu has joined #tomu | 17:00 | |
| *** rohitksingh has joined #tomu | 17:00 | |
| st-gourichon-fid | How to get intrinsics like __mulsi3 to be written to RAM instead of flash? | 17:01 |
| *** CarlFK has joined #tomu | 17:03 | |
| *** ukembedded has quit IRC | 17:03 | |
| *** ukembedded has joined #tomu | 17:04 | |
| * st-gourichon-fid reads linker script documentation | 17:11 | |
| * st-gourichon-fid reads linker script documentation https://sourceware.org/binutils/docs/ld/Scripts.html | 17:11 | |
| st-gourichon-fid | I'll try to put all sections to sram and see how it goes. :-) | 17:15 |
| *** rohitksingh has quit IRC | 17:22 | |
| *** rohitksingh has joined #tomu | 17:31 | |
| *** AnimaInvicta has joined #tomu | 17:43 | |
| st-gourichon-fid | Bricked? | 17:43 |
| st-gourichon-fid | Hmm strange. The toolchain generated an elf 268MBytes in size, which dfu-tool tried to send to flash and ... it looks like the FOMU hacker is bricked. | 17:43 |
| st-gourichon-fid | No light at all when plugging it in. | 17:44 |
| st-gourichon-fid | The change that produced it was to change "> rom" into "> sram" in ld/linker.ld in the .rodata stanza. | 17:45 |
| st-gourichon-fid | Aren't there sanity checks in the flash process? | 17:53 |
| st-gourichon-fid | My coworker is trying to low-level reflash the bootloader by soldering wires to the flash. | 17:59 |
| mithro | st-gourichon-fid: Please log a bug | 18:07 |
| mithro | st-gourichon-fid: I don't know if anyone thought to check about wrapping around the end of flash? | 18:07 |
| st-gourichon-fid | mithro, thanks for the suggestion. | 18:08 |
| mithro | st-gourichon-fid: Seems like something that is easy to forget :-) | 18:08 |
| st-gourichon-fid | There are several strange things. (1) making a huge output binary (2) flashing that binary bricks the FOMU. | 18:08 |
| st-gourichon-fid | A good bug report is reproducible. I don't want to generate too much work to my coworker who is soldering wires to revive the FOMU right now. | 18:11 |
| st-gourichon-fid | I'll try to make a simplest repro case. | 18:11 |
| *** rohitksingh has quit IRC | 18:20 | |
| st-gourichon-fid | Thanks my coworker acathla who just revived the FOMU by low-level flashing. | 18:21 |
| st-gourichon-fid | Should the bug report go on https://github.com/im-tomu/fomu-workshop/issues ? | 18:23 |
| tpb | Title: Issues · im-tomu/fomu-workshop · GitHub (at github.com) | 18:23 |
| *** rohitksingh has joined #tomu | 18:32 | |
| st-gourichon-fid | I pushed the offending situation in https://github.com/fidergo-stephane-gourichon/fomu-workshop/tree/all_code_in_ram_huge_dfu_bricks_fomu | 18:53 |
| tpb | Title: GitHub - fidergo-stephane-gourichon/fomu-workshop at all_code_in_ram_huge_dfu_bricks_fomu (at github.com) | 18:53 |
| st-gourichon-fid | Only one line changed in linker script https://github.com/im-tomu/fomu-workshop/compare/master...fidergo-stephane-gourichon:all_code_in_ram_huge_dfu_bricks_fomu | 18:54 |
| tpb | Title: Comparing im-tomu:master...fidergo-stephane-gourichon:all_code_in_ram_huge_dfu_bricks_fomu · im-tomu/fomu-workshop · GitHub (at github.com) | 18:54 |
| *** im-tomu has left #tomu | 18:54 | |
| *** im-tomu has joined #tomu | 18:54 | |
| st-gourichon-fid | objdump output seems reasonable, elf is okay but bin and dfu are huge. | 18:54 |
| *** rohitksingh has quit IRC | 18:57 | |
| st-gourichon-fid | Is there an option of objcopy that can show why the generated binary is so huge? | 19:00 |
| st-gourichon-fid | 268698356 bytes or 0x100402F4 bytes. | 19:00 |
| *** rohitksingh has joined #tomu | 19:01 | |
| daveshah | readelf or something might help | 19:02 |
| daveshah | It's usually because you have far apart sections with "progbits" set | 19:02 |
| st-gourichon-fid | daveshah, makes sense. | 19:04 |
| st-gourichon-fid | Okay, so I guess just asking the linker to put all .text to RAM is breaking some basic logic of the linker script. https://github.com/im-tomu/fomu-workshop/compare/master...fidergo-stephane-gourichon:all_code_in_ram_huge_dfu_bricks_fomu | 19:05 |
| tpb | Title: Comparing im-tomu:master...fidergo-stephane-gourichon:all_code_in_ram_huge_dfu_bricks_fomu · im-tomu/fomu-workshop · GitHub (at github.com) | 19:05 |
| *** im-tomu has left #tomu | 19:05 | |
| *** im-tomu has joined #tomu | 19:06 | |
| daveshah | Yeah, you'll probably end up with something that tries to make a flat binary that covers the address space of both ROM and RAM | 19:06 |
| st-gourichon-fid | daveshah, yes. | 19:07 |
| st-gourichon-fid | size 0x1004xxxx = 0x2004xxxx (adresse inside flash) - 0x10000000 (address of ram) | 19:08 |
| *** rohitksingh has quit IRC | 19:48 | |
| st-gourichon-fid | Still could not figure out. How to ensure that symbol __mulsi3 is stored in RAM by the linker? | 19:48 |
| *** benno has quit IRC | 19:54 | |
| *** benno has joined #tomu | 19:54 | |
| *** rohitksingh has joined #tomu | 20:30 | |
| *** TheJJ has quit IRC | 21:00 | |
| *** TheJJ has joined #tomu | 21:01 | |
| *** rohitksingh has quit IRC | 21:36 | |
| *** rohitksingh has joined #tomu | 21:39 | |
| *** futarisIRCcloud has joined #tomu | 21:49 | |
| futarisIRCcloud | mithro: Was it you, or someone else who got python running on icebreaker? https://github.com/timvideos/litex-buildenv/wiki/HowTo-FuPy-on-iCE40-Boards | 21:50 |
| tpb | Title: HowTo FuPy on iCE40 Boards · timvideos/litex-buildenv Wiki · GitHub (at github.com) | 21:50 |
| mithro | futarisIRCcloud: I'm pretty sure multiple people have got it working | 21:51 |
| futarisIRCcloud | edbordin said something about it on the #icebreaker discord | 21:51 |
| daveshah | Miodrag (mmicko) has done micropython on iCE40 too | 21:54 |
| *** rohitksingh has quit IRC | 22:36 | |
| *** rohitksingh has joined #tomu | 22:37 | |
| *** rohitksingh has quit IRC | 22:45 | |
| gurke_ | mithro: I think I'm done from my side for https://github.com/im-tomu/fomu-workshop/pull/124 and https://github.com/im-tomu/fomu-workshop/pull/141 | 22:45 |
| tpb | Title: Fix Verilog examples by mainini · Pull Request #124 · im-tomu/fomu-workshop · GitHub (at github.com) | 22:45 |
| gurke_ | mithro: would be happy if they could get merged - or if you could point out if there's something blocking from my side | 22:45 |
| mithro | gurke_: I think it's block on me having enough time to look at the tab where I have that pull request open | 22:46 |
| gurke_ | ok :-) | 22:46 |
| gurke_ | I'm also currently cleaning up tabs... | 22:46 |
| *** rohitksingh has joined #tomu | 22:54 | |
| *** ppisati has quit IRC | 23:15 | |
| *** ppisati has joined #tomu | 23:16 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!