| *** tpb has joined #tomu | 00:00 | |
| *** CarlFK has joined #tomu | 00:06 | |
| ovf | xobs: just in case it's of any use, here's a wireshark pcap of flashing circuitpython: http://0x0.st/zIkh.gz and lsusb -t after the fact (foboot was dev 67): http://0x0.st/zIkF.txt | 00:13 |
|---|---|---|
| xobs | ovf: I take it from that output that circuitpython didn't work? :( | 00:45 |
| CarlFK | xobs: what does working look like ? | 00:48 |
| CarlFK | mine is flashing red right now. but no ttyACMx | 00:48 |
| xobs | Red means the program failed to run. | 00:48 |
| CarlFK | doh. | 00:48 |
| ovf | sorry, there was a netsplit around the time we complained, so you probably missed our messages: http://0x0.st/zId8.txt | 00:48 |
| xobs | Ah, yeah, I missed those messages. | 00:50 |
| xobs | That v2.0.1 doesn't persist, in case there's a bug in the USB stack and it isn't as reliable at loading programs. Which does seem to be the case. | 00:50 |
| ovf | i do appreciate the fact that my fomu is still alive and well after a few rounds of this. :-) | 00:53 |
| xobs | It's interesting that it enumerates properly. And that foboot-2.0.1 appears to load reliably, but circuitpython just isn't working. | 00:59 |
| ovf | does the same setup work on your end? | 01:04 |
| xobs | ovf: it does, and I've been testing from three different machines (two Windows machines and a Raspberry Pi). However, I now have a situation where I can reliably load v1.9.1 from my Windows machine on top of itself and it works, but when I load v2.0.1 on and try to load something it fails. | 01:05 |
| xobs | Which seems to be similar to what you're seeing. | 01:06 |
| xobs | Unfortunately it's electrically really weird. Which I thought was just the USB Beagle being funky, but maybe it's something else. | 01:06 |
| * xobs uploaded an image: image.png (116KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/eGZSeilWrrHfNjEHcjDIeRDh > | 01:07 | |
| xobs | The Beagle seems to have missed a NAK packet. Or maybe it never got sent? At any rate, v1.9.1 works just fine even under these circumstances. | 01:07 |
| ovf | :-( i think the only way in which i could possibly help is to give you remote access to a linux machine with a bunch of fomus that reliably (unreliably?) didn't work, but since you could reproduce that it won't be helpful either. | 01:20 |
| xobs | So I think the unreliability I'm seeing here is, in fact, caused by dodgy wiring. | 01:28 |
| * xobs uploaded an image: image.png (55KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/RAxHpHnJqvYuTQzsAncowSoE > | 01:30 | |
| xobs | Because what I see from the device side when I attach a debugger here is that the last packet the device received was 0x41 00 c0 00 ..., and it's waiting for the last 64 byte packet, but the host thinks it's sent all of the data and it's waiting for the device to respond with "ACK". | 01:31 |
| xobs | ovf: does it always fail at the same point, or is it random? | 01:32 |
| ovf | okay, now i got 'error during download' from dfu-util. want a pcap? sorry i don't have a usb beagle | 01:34 |
| xobs | How far along was it? | 01:35 |
| ovf | dfu-utils sent the last data urb, got urb_complete for it and that's the last bit of communication. interestingly dfu-util ui was showing '98%' | 01:37 |
| ovf | (i think it's the last packet because (1) it's 1744 instead of 4096 bytes (2) it appears to end with something like what's near the end of circuitpython.dfu) | 01:38 |
| xobs | ...huh. I wonder if that's the problem. I think I spotted a bug. | 01:38 |
| xobs | Ayep. https://github.com/im-tomu/foboot/commit/c8872c1088ca64affaa589adda6ecb39782e012e | 01:50 |
| xobs | Let me build a new hacker top firmware and see if that fixes it for you. | 01:50 |
| ovf | i'll need pvt | 01:50 |
| pollo | is there a way to flash a new version of foboot using dfu-utils, akin to the tomu? | 01:53 |
| xobs | pollo: there is, I've just been reluctant to release it in case there were breaking bugs. Like the one we just discovered. | 01:53 |
| pollo | ah ok, I do see a booster dir indeed :) | 01:54 |
| xobs | I discovered during testing yesterday that it's probably a good idea to change the booster magic number when an incompatible bitstream is loaded. I was having issues where the v1.9.1 bootloader would sometimes try burning the v2.0.1 firmware, which doesn't work since the SPI interface changed. | 01:55 |
| pollo | if flashing a buggy version (and thus failing) meant I had to reflash the board using an rpi I wouldn't really mind it tbh | 01:56 |
| pollo | as atm the only way I have is to flash the board with an rpi anyway (and it's a pita) | 01:56 |
| xobs | I'm building a v2.0.2 pvt image now. It's even looking like it'll meet timing. | 02:02 |
| ovf | something's funky when running lxbuildenv in foboot: > Fetched in submodule path 'deps/valentyusb', but it did not contain 97ac21d6ea4f9b632773a833476906c1ab95a730. Direct fetching of that commit failed. | 02:03 |
| ovf | > error: Server does not allow request for unadvertised object 97ac21d6ea4f9b632773a833476906c1ab95a730 | 02:03 |
| xobs | ovf: sorry, forgot to push the valentyusb change. | 02:05 |
| xobs | Try again | 02:05 |
| xobs | ovf: Can you grab v2.0.2 from https://github.com/xobs/circuitpython/releases/tag/v0.0.1? I'm building hacker-foboot-v2.0.2.dfu right now. | 02:16 |
| tpb | Title: Release Initial Fomu release · xobs/circuitpython · GitHub (at github.com) | 02:16 |
| ovf | > Adafruit CircuitPython 4.0.0-alpha-3590-ga509234-dirty on 2019-11-28; Fomu with VexRiscv | 02:19 |
| xobs | Awesome! | 02:19 |
| ovf | for future reference, how do you build the top(?) file, pvt-foboot-v2.0.2.dfu? | 02:19 |
| xobs | ovf: I'm using the command `python foboot-bitstream.py --boot-source bios --with-debug usb --revision pvt --seed 2`, then appending a dfu-suffix to build/gateware/top.bin | 02:21 |
| xobs | I'm also putting together a release script. | 02:22 |
| ovf | circuitpython crashes when it runs out of memory. i know i shouldn't complain because our commercial interpreter does the same, but it's just additionally annoying in my setup as i need to reflash starting from foboot2 to go back | 02:25 |
| xobs | There's now a hacker-foboot-v2.0.2.dfu up for hacker users to try out | 02:33 |
| ovf | thanks! it's probably not related to fomu at all but i can't seem to get the usb mass storage thing to work, the files i write just disappear | 02:45 |
| ovf | also it presents a couple of hid devices for some reason? | 02:45 |
| xobs | ovf: as I understand it, you can connect to it via the serial port and just watch it. Then you can create a file called "code.py" or "main.py", and every time you save it it'll be re-executed. | 02:46 |
| xobs | The various HID devices are so you can instantiate HID devices in Python and they just work. | 02:46 |
| xobs | The large number of USB devices is a big reason why this couldn't be done with the old epfifo interface. | 02:46 |
| ovf | > If your code.py has print() statements in it, then you should be able to see the output of those statements getting printed into the serial text box. | 02:51 |
| ovf | no, can't get that to work | 02:51 |
| xobs | Sorry, the `hacker-foboot-v2.0.2.dfu` was broken -- SPI flash wasn't working for some reason. I'm regenerating it. | 02:51 |
| xobs | ovf: are you running the serial console interactively? I.e. does it have the ">>> " prompt? I think that disables re-evaluation. | 02:52 |
| ovf | no, i'm at the 'Press any key to enter the REPL. Use CTRL-D to reload.' prompt | 02:54 |
| xobs | hacker-foboot-v2.0.2.dfu is up now | 03:02 |
| xobs | I'm still rebuilding evt releases of foboot, but I'm reasonably confident in v2.0.2 that I've posted the updaters at https://github.com/im-tomu/foboot/releases/tag/v2.0.2 | 03:04 |
| tpb | Title: Release v2.0.2: sw: dont clear OUT buffer during usb_recv · im-tomu/foboot · GitHub (at github.com) | 03:04 |
| xobs | If you want to permanently move to v2.0.2, load the appropriate `updater` file. | 03:06 |
| ovf | cool! | 03:07 |
| ovf | i think there's definitely some corruption going on somewhere between python and linux vfat driver -- after one mount/umount cycle the 'lib' directory is gone and in its place is a 'mΩ' directory. almost no resistance! | 03:12 |
| xobs | That definitely does sound like corruption. What platform is this on? | 03:15 |
| ovf | linux, and it's standard vfat driver. if i use my trusty mtools (an alternative userspace implementation of ms-dos filesystem) all goes well. | 03:19 |
| ovf | yep, linux vfat seems to put things in a bad state | 03:20 |
| ovf | the documentation here sounds like they at least expect it to work with linux: https://docs.micropython.org/en/latest/pyboard/tutorial/script.html | 03:21 |
| tpb | Title: 2. Running your first script MicroPython 1.11 documentation (at docs.micropython.org) | 03:21 |
| xobs | I'm testing in Linux and it's working. I wonder what the issue is, then. Maybe another process running that's also writing files? | 03:36 |
| xobs | Maybe it's the vim backup files? | 03:36 |
| xobs | Need to get input from tannewt :) | 03:36 |
| ovf | well, it's rather apparent it isn't anything in your code. :-) | 03:46 |
| xobs | ovf: but does it generally work alright? Aside from msc corruption weirdness. As in, it hasn't broken anything permanently? | 03:46 |
| ovf | what are some examples of things it could break permanently? | 03:46 |
| xobs | The only thing I could think of is if you exceed the SPI flash and it wraps around. E.g. writing all zeroes to the disk. But that hasn't happened on mine, so it's unlikely to happen anywhere else. | 03:48 |
| ovf | hm, looking at the (virtual) flash, the contents of my file are there (actually twice), but it isn't present in the fat (directory table) after a reboot | 03:49 |
| ovf | anyway, i should rather address this to the micropython folk (and i'm not in the target audience anyway) | 03:50 |
| xobs | I was seeing that, too. I also just wrote all zeroes to the drive, and for some reason each sector starts out with `bf d0`, which makes me think that might be where the corruption is. | 03:50 |
| xobs | I'll investigate that issue, and once I've solved it I'll make an annoucement on Twitter. | 03:51 |
| ovf | one benefit of having laptop's internal storage on a (rather slow) emmc is that my / is /dev/mmcblk*, so i can't mix it up with /dev/sd* when zeroing out things | 03:53 |
| ovf | after zeroing i'm seeing alternating 0x00 and 0xff sectors | 04:00 |
| xobs | Well that could be the cause of some corruption problems. | 04:00 |
| xobs | On my EVT board I see sectors starting with `bf d0`, but I don't see that on the actual flash itself. Which means that zeroes are actually getting written, but it's most likely the read command that's faulty. | 04:02 |
| ssb | [ 1.154000] usb 1-2: Product: Fomu PVT running DFU Bootloader v2.0.2 | 04:04 |
| ssb | seems to work ) | 04:05 |
| *** xkapastel has joined #tomu | 04:09 | |
| *** nrossi has joined #tomu | 04:21 | |
| xobs | ssb: hooray! | 04:40 |
| xobs | Okay, weird. Looking into it some more, circuitpython doesn't write sector 0, and subtracts 1 from every sector it writes. Kinda makes sense, I guess. Though that was really throwing me off here. | 04:40 |
| CarlFK | xobs: dfu-util -D hacker-foboot-v2.0.2.dfu and then circuitpython.dfu I have red blinking | 06:06 |
| xobs | CarlFK: So you load hacker-foboot-v2.0.2.dfu, and it just stops working entirely? And when you unplug it and plug it back in, what does it show up as? | 06:07 |
| CarlFK | foboot seems ok, loading circuitpython makes it go red | 06:08 |
| CarlFK | what is the command that might power cycle my usb port if it has power control? | 06:09 |
| xobs | So you plug Fomu in, then load `hacker-foboot-v2.0.2.dfu`, then without unplugging it load `circutpython.dfu`. After doing the second load, it blinks red? | 06:10 |
| CarlFK | yes | 06:10 |
| xobs | What does `dfu-util -l` show after you load `hacker-foboot-v2.0.2.dfu`? | 06:11 |
| CarlFK | Found DFU: [1209:5bf0] ver=0101, devnum=25, cfg=1, intf=0, path="3-3", alt=0, name="Fomu Hacker running DFU Bootloader v2.0.2", serial="UNKNOWN" | 06:12 |
| xobs | What's the md5sum of your `hacker-foboot-v2.0.2.dfu`? `9e553539b8ca3dab8120554e54123398 hacker-foboot-v2.0.2.dfu` | 06:13 |
| CarlFK | 9e553539b8ca3dab8120554e54123398 hacker-foboot-v2.0.2.dfu | 06:13 |
| CarlFK | http://paste.ubuntu.com/p/RmSB9cm99z/ all the spew | 06:14 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 06:14 |
| xobs | And it's not showing up when you do `dmesg`? | 06:14 |
| CarlFK | dmesg http://paste.ubuntu.com/p/kD6XyVrgNM/ | 06:17 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 06:17 |
| xobs | `[191766.743339] usb 3-3: new full-speed USB device number 14 using xhci_hcd` <-- that might be it starting to enumerate. Hmm... | 06:20 |
| CarlFK | hmm, v1.9.1 (what I get on power) dfu-util -D micropython-fomu.dfu ... goes red | 06:20 |
| CarlFK | I thought that worked ... a few weeks ago | 06:20 |
| CarlFK | welp... I just tried micropython from fomu-workshop on 5 fomu's - all have 1.9.1, all went red | 06:39 |
| xobs | CarlFK: interestingly, I just had an instance of it refusing to accept an address during enumeration. Though it worked when linux retried with a different address... | 06:39 |
| CarlFK | xobs: is it safe enough to assume that if I can load the 2.0.2 boot loader my dfu-util and local usb stuff is not causing problems ? | 06:49 |
| CarlFK | or is there something else I can do to test that assumption | 06:49 |
| xobs | CarlFK: Can you try loading the v2.0.2 boot loader on top of itself? | 06:50 |
| xobs | Then, unplug Fomu and plug it back in and run `dfu-util -e`. You should still get v2.0.2 that way. | 06:51 |
| xobs | That'll test that it can actually write to SPI flash. | 06:51 |
| CarlFK | xobs: that worked | 06:53 |
| xobs | Hmm... I loaded circuitpython onto my hacker board, and I just discovered that it blinks red slowly when I load circuitpython, because I forgot hacker boards don't really have a blue color. | 06:55 |
| CarlFK | lol | 06:56 |
| * xobs uploaded a video: VectorVideo_2019-11-29_025541.mp4 (722KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/BkPlqpOeusprAjjbkHJuegiq > | 06:56 | |
| * xobs uploaded a video: VectorVideo_2019-11-29_025652.mp4 (1492KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/XOyQtKLJwmDTTnAXxAAqgVle > | 06:57 | |
| xobs | (make one that's slightly longer). Both boards are running circuitpython. | 06:58 |
| CarlFK | that looks like how mine flashes | 06:59 |
| CarlFK | but no ttyACMx in /dev or dmesg | 07:00 |
| xobs | The interesting thing is that the last line of the dmesg you sent shows something connected on usb. | 07:01 |
| CarlFK | oh oh.. that may have been because I un/plugged it | 07:02 |
| xobs | It happend four seconds after the circuitpython upload finished. | 07:03 |
| CarlFK | ok I don't think I did anything that fast | 07:05 |
| CarlFK | im using a usb-3 port, that shouldn't matter, right ? | 07:08 |
| xobs | It shouldn't, but that's a good thought. I'll test on my Linux server to see if I can't reproduce that issue. | 07:10 |
| CarlFK | hmm, I got micropython on fomu on this box about 3 weeks ago, but I can't now. | 07:13 |
| CarlFK | xobs: can I upload foboot 2.0.2 so it persists? | 07:40 |
| xobs | CarlFK: Sure, you can load the `updater` file from https://github.com/im-tomu/foboot/releases/tag/v2.0.2 | 07:41 |
| tpb | Title: Release v2.0.2: sw: dont clear OUT buffer during usb_recv · im-tomu/foboot · GitHub (at github.com) | 07:41 |
| CarlFK | that worked | 07:50 |
| CarlFK | lets try turning off my laptop... | 07:50 |
| *** CarlFK has quit IRC | 07:50 | |
| *** CarlFK has joined #tomu | 07:54 | |
| CarlFK | no help. | 07:59 |
| CarlFK | I'm out of ideas. maybe sleep will help ;) | 07:59 |
| xobs | Alright, I'll poke at it some more. | 07:59 |
| xobs | I'm trying to fix the spi flash layer in circuitpython now. | 07:59 |
| xobs | Goodnight! Thanks for testing. | 08:00 |
| CarlFK | sure thing | 08:03 |
| *** whatnick has joined #tomu | 10:19 | |
| whatnick | Hi all | 10:20 |
| whatnick | Setting up Litex buildenv for ECP5 ( to work with OrangeCrab), mithro do you have profile for this. | 10:21 |
| miek | whatnick: have you seen https://github.com/gregdavill/OrangeCrab/tree/master/gateware/litex_ddr3_test ? | 10:42 |
| tpb | Title: OrangeCrab/gateware/litex_ddr3_test at master · gregdavill/OrangeCrab · GitHub (at github.com) | 10:42 |
| whatnick | miek yep attempting to build it but I don't have migen/litex setup outside litex buildenv | 10:43 |
| xobs | Found the source of the file corruption: https://github.com/hathach/tinyusb/commit/26dcc19b186a85f6ee8d1d94bb672e34865f56e9 | 10:58 |
| xobs | Also, for some reason it's not working on my Intel Linux machine. So that's a repro from CarlFK I think. | 11:08 |
| _florent_ | whatnick: here is how it can be set up without using litex buildenv: https://github.com/enjoy-digital/litex/blob/master/.travis.yml | 11:47 |
| tpb | Title: litex/.travis.yml at master · enjoy-digital/litex · GitHub (at github.com) | 11:47 |
| _florent_ | then you just need to install the toolchain (Diamond or Yosys/Nextpnr) | 11:48 |
| whatnick | _florent_ I have made progress but my diamond is flaky : https://twitter.com/whatnick/status/1200377290120560640/photo/1 | 11:48 |
| whatnick | Or actually I have different version of diamond to what is hardcoded in build_top.sh | 11:49 |
| whatnick | working out where/how to change that | 11:49 |
| whatnick | _florent_ This is where I am now at a segfault : https://twitter.com/whatnick/status/1200384863326466048/photo/1 calling it a night | 12:05 |
| daveshah | This is a known issue with Diamond where /bin/sh isn't bash | 12:05 |
| daveshah | changing the shebang in the scripts in synpbase/bin to /bin/bash should fix that | 12:06 |
| whatnick | Woo getting close | 12:23 |
| whatnick | Cool recreated the symlink possibly breaking WSL , but i don't care :D | 12:26 |
| whatnick | daveshah lots of stuff happened after shell relink and now I have another segfault | 12:31 |
| whatnick | daveshah: seen this before ? BitDatabase.cpp:27: Trellis::ConfigBit Trellis::cbit_from_str(const string&): Assertion `s[idx] == 'F'' failed. | 12:53 |
| whatnick | I remember a conversation a while ago about line ending etc. in bitstream files and interaction in WSL | 12:53 |
| daveshah | Yeah, you probably need to dos2unix the database files | 12:56 |
| whatnick | before or after prjtrellis install ? | 12:58 |
| whatnick | i.e. where are the said files ? | 13:00 |
| daveshah | In prjtrellis/database, then reinstall | 13:08 |
| daveshah | If you git clone inside wsl using Unix git, then it shouldn't be a problem in any case | 13:08 |
| whatnick | I have autocrlf set in my git which causes trouble :D | 13:09 |
| whatnick | Anyway ... | 13:09 |
| whatnick | getting close ran dos2unix and reinstalled | 13:09 |
| whatnick | As I say it is 2019 and we are still tripping over line endings | 13:09 |
| whatnick | Yay nextpnr-ecp5 is built | 13:20 |
| TomKeddie | whatnick: try following the stuff in the supercon badge notes perhaps? https://github.com/Spritetm/hadbadge2019_fpgasoc/blob/master/doc/toolchain-lin.md | 13:29 |
| tpb | Title: hadbadge2019_fpgasoc/toolchain-lin.md at master · Spritetm/hadbadge2019_fpgasoc · GitHub (at github.com) | 13:29 |
| whatnick | Firmware is built for OrangeCrab .. now finally to bed and wil load it tomorrow :D | 13:35 |
| *** whatnick has quit IRC | 13:50 | |
| *** emeb has joined #tomu | 14:36 | |
| xobs | Also, I figured out what was wrong with v2.0.2 on some machines, particularly with CarlFK : https://github.com/im-tomu/valentyusb/commit/b262b994fd9e6568b257b8424fe808cfc403e652 | 14:49 |
| tpb | Title: eptri: use EventSourceProcess to signal usb reset · im-tomu/valentyusb@b262b99 · GitHub (at github.com) | 14:50 |
| xobs | I'll build v2.0.3 for people to try out tomorrow! | 14:50 |
| tannewt | get it all going xobs? | 15:06 |
| xobs | tannewt: just about. It's been a very buggy day. | 15:10 |
| tannewt | what are you trying to hunt down? | 15:13 |
| xobs | most of the day was spent trying to figure out why MSC stuff was corrupted. That was due to a bug in the way multiple OUT packets were handled. Then there was a bug in foboot where we were throwing away data in an OUT buffer. | 15:15 |
| xobs | Now I've just found out that the RESET signal was actually level-triggered and not edge-triggered, which locked up the CPU for the whole duration of a USB reset. | 15:16 |
| xobs | Things are much better now :) | 15:16 |
| tannewt | nice! great to hear you are making progress | 15:19 |
| xobs | Is the heap size fixed based on a macro, or calculated at startup? | 15:23 |
| *** emeb has quit IRC | 15:31 | |
| *** emeb has joined #tomu | 15:32 | |
| xobs | There. New release for people to try! https://github.com/xobs/circuitpython/releases/tag/v0.1.0-fomu | 15:46 |
| tpb | Title: Release v0.1.0-fomu: Beta Release 1 · xobs/circuitpython · GitHub (at github.com) | 15:46 |
| CarlFK | xobs: Adafruit CircuitPython v0.1.0-fomu on 2019-11-29; Fomu with VexRiscv | 16:36 |
| CarlFK | 16:36 | |
| CarlFK | \o/ | 16:36 |
| CarlFK | carl@twist:/media/carl/CIRCUITPY$ cat code.py | 16:39 |
| CarlFK | print("fomu!") | 16:39 |
| CarlFK | >>> import code ... OSError: [Errno 5] Input/output error | 16:39 |
| CarlFK | i'm off to breakfast | 16:42 |
| *** nrossi has quit IRC | 21:04 | |
| *** xkapastel has quit IRC | 21:19 | |
| tannewt | xobs, it is calculated at start up. basically all the space between static data and the stack limit | 22:18 |
| *** CarlFK has quit IRC | 22:29 | |
| *** CarlFK has joined #tomu | 22:30 | |
| CarlFK | xobs: >>> I hit ^d... soft reboot; Auto-reload is on. Simply save files over USB to run them or enter REPL to disable. ; code.py output:OSError: [Errno 5] Input/output error | 22:41 |
| *** im-tomu has left #tomu | 22:41 | |
| *** im-tomu has joined #tomu | 22:41 | |
| CarlFK | hmm, rm code.py; touch code.py.. ^d no error. | 22:58 |
| CarlFK | >>> f=open('code.py'); f.read() | 22:59 |
| CarlFK | '' | 22:59 |
| CarlFK | if code.py is 'x=1' then OSError | 23:00 |
| *** emeb has quit IRC | 23:50 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!