*** tpb has joined #upy-fpga | 00:00 | |
*** Guest4564 has joined #upy-fpga | 01:55 | |
*** Guest4564 has quit IRC | 02:05 | |
*** Guest4566 has joined #upy-fpga | 04:00 | |
*** Guest4566 has quit IRC | 04:06 | |
*** jimmo has joined #upy-fpga | 05:46 | |
jimmo | hello! | 05:58 |
---|---|---|
jimmo | so apparently learning PIC development is a useful life skill | 05:59 |
jimmo | but programming LM32 firmware at 19200 baud is really awful | 05:59 |
jimmo | https://github.com/jimmo/numato-mimasv2-pic-firmware | 05:59 |
tpb | Title: GitHub - jimmo/numato-mimasv2-pic-firmware (at github.com) | 05:59 |
jimmo | also, the mode selector switch isn't great | 06:00 |
jimmo | if you have a Mimas v2, then follow the instructions to make the FPGA UART run at 115200 baud, and show up as two serial ports - first one for the SPI flash, second one for the FPGA/LM32 UART | 06:01 |
mithro | jimmo: \o/ | 06:02 |
jimmo | you'll have to edit target/mimasv2/Makefile to set the port for firmware to /dev/ttyACM1, and target/mimasv2/base.py to change the baud rate | 06:06 |
mithro | jimmo: I'll fix up the FPGA side shortly | 06:07 |
mithro | s/FPGA/gateware repo | 06:08 |
jimmo | you know how the saying goes... friends don't let friends use <microcontrollers without gcc/llvm support> | 06:10 |
mithro | Find me a IC to replace the FX2 :-P | 06:11 |
shenki | what's the latest and greatest repo for gateware? | 07:19 |
shenki | ive just flashed jimmo's shiny new firmware on my mimasv2 | 07:19 |
jimmo | i'm using [email protected]:mithro/HDMI2USB-litex-firmware.git | 07:22 |
shenki | ok, me to | 07:23 |
shenki | too | 07:23 |
shenki | File "/home/joel/dev/timvideos/mimasv2/build/conda/bin/opsis-mode-switch", line 11, in <module> | 07:25 |
shenki | load_entry_point('hdmi2usb.modeswitch==0.0.0.post145', 'console_scripts', 'opsis-mode-switch')() | 07:25 |
shenki | File "/home/joel/dev/timvideos/mimasv2/build/conda/lib/python3.5/site-packages/hdmi2usb/modeswitch/cli.py", line 204, in main | 07:25 |
shenki | assert len(found_boards) == 1, found_boards | 07:25 |
shenki | AssertionError: [] | 07:25 |
shenki | targets/opsis/Makefile.mk:6: recipe for target 'gateware-load-opsis' failed | 07:25 |
shenki | boom | 07:25 |
jimmo | mimasv2 | 07:25 |
shenki | oh | 07:25 |
shenki | yes | 07:26 |
shenki | thankyou | 07:27 |
shenki | jimmo: does it ignore the state of SW7 now? | 07:28 |
jimmo | yep | 07:28 |
jimmo | suggestions welcome! | 07:28 |
shenki | makes sense to me | 07:28 |
jimmo | maybe enable/disable xmodem mode for spi flash? | 07:28 |
shenki | that's a good idea. use it for backwards incompatible stuff | 07:29 |
mithro | I need to take another look at the schematic | 07:30 |
mithro | jimmo: We should add some of the functionality from the TOFE board, like allowing to read the analog pins via the serial and stuff | 07:32 |
jimmo | so the current protocol already allows that in some ways | 07:33 |
jimmo | but could be extended to support analog | 07:33 |
mithro | The SPI flash lines because GPIO after the FPGA boots, so we could actually have one UART for serial console and a second UART for the wishbone bridge and stuff | 07:33 |
shenki | how do i flash now that i have gateware? | 07:34 |
jimmo | make gateware-load | 07:34 |
shenki | $ make image-flash-mimasv2 PORT=/dev/ttyACM1 | 07:36 |
shenki | but it's looking for flash.bin, and i don't have one of those | 07:36 |
jimmo | i ran: | 07:36 |
jimmo | make gateware | 07:36 |
jimmo | make gateware-load | 07:36 |
shenki | $ make gateware-load | 07:37 |
shenki | MimasV2 doesn't support loading, use the flash target instead. | 07:37 |
shenki | make gateware-flash-mimasv2 | 07:37 |
shenki | $ git describe | 07:37 |
shenki | v0.0.0-1289-ga44c2be5a91a | 07:37 |
mithro | make image | 07:37 |
shenki | that fixed it | 07:37 |
shenki | programming | 07:37 |
mithro | gateware-flash-mimasv2 | 07:37 |
mithro | That just flashes the gateware | 07:38 |
mithro | image-flash-mimasv2 | 07:38 |
mithro | That flashes the gateware+bios+firmware | 07:38 |
jimmo | mithro: has that changed since january? | 07:38 |
mithro | Guess image-flash-mimasv2 should deps on image | 07:38 |
mithro | jimmo: Yes, possibly | 07:39 |
shenki | it's hung | 07:40 |
shenki | ...Set value of IOs that are needed for configuration process | 07:40 |
shenki | Send a command to Mimas V2: b'~\t\x01\x02\x01' | 07:40 |
shenki | ...Set value of IOs that are needed for configuration process | 07:40 |
shenki | Send a command to Mimas V2: b'~\t\x01\x02\x00' | 07:40 |
shenki | ...Send a command to Mimas V2: b'~\x07\x01\x02' | 07:40 |
shenki | .. | 07:40 |
mithro | brb - just in the middle of drilling into my desk | 07:40 |
shenki | Micron M25P16 SPI Flash detected | 07:46 |
shenki | Loading file build/mimasv2_base_lm32//flash.bin... | 07:46 |
shenki | Erasing flash sectors... | 07:46 |
shenki | Writing to flash 13% complete... | 07:46 |
shenki | stuck there (i went back to the stock flashing python file) | 07:46 |
jimmo | what changed? :) | 07:46 |
shenki | dunno.... some crazy PIC hacker rocked up and i flashed his binary from the internet. what could possibly go wrong? | 07:47 |
jimmo | haha | 07:47 |
jimmo | i don't understand what you mean by stock flashing python file | 07:47 |
shenki | Oh. I'd hacked up MimasV2Config.py | 07:48 |
shenki | from back in jan, to debug something | 07:48 |
shenki | power cycled. appears to be getting further now | 07:49 |
shenki | it worked! | 07:52 |
shenki | $ flterm --port=/dev/ttyACM2 --speed=115200 --kernel=$HOME/dev/micropython/lm32/build/firmware.bin | 07:53 |
shenki | [FLTERM] Starting... | 07:53 |
shenki | ������������������ | 07:53 |
shenki | that looks less worky | 07:53 |
mithro | shenki: Did you build the gateware with a different UART baud rate? | 07:53 |
shenki | i didn't change anything | 07:53 |
jimmo | targets/mimasv2/base.py s/19200/115200 | 07:54 |
shenki | ok | 07:54 |
*** ewen has joined #upy-fpga | 07:59 | |
ewen | mithro: Thanks for advice via email/GitHub on getting MicroPython to run on Mimas v2. | 08:00 |
mithro | Hi ewen! | 08:00 |
mithro | ewen: It's cool to have you working on this too | 08:00 |
ewen | I've managed to make option 2 (actually flashing micropython) work. | 08:00 |
ewen | But no luck with 1 or 3. | 08:00 |
ewen | I'm beginning to suspect my flterm doesn't actually work correctly... | 08:00 |
shenki | jimmo: it hung at 22% this time. appears to be a bit flaky? | 08:00 |
mithro | shenki has just been trying to replicate jimmo's replacement PIC firmware to make flashing/reloading faster | 08:01 |
mithro | ewen: are you remembering to change the switch after flashing? Are you seeing anything on the flterm console? | 08:01 |
ewen | With approach one (flash in the default firmware), yes I do see H2U> prompt, and help/reboot/etc are accepted. | 08:02 |
ewen | But nothing after that. | 08:02 |
ewen | (Even after disconnecting flterm and reconnecting with screen) | 08:02 |
shenki | jimmo: i power cycled. it got 40%, then hung | 08:03 |
ewen | flterm only every reports "Starting...". But it seems like there should be more when it's doing a kernel upload. | 08:03 |
ewen | (at least from looking at flterm.py) | 08:03 |
mithro | ewen: flterm is a terminal emulator program which also includes the ability to upload firmware | 08:03 |
mithro | ewen: So you should be connected with flterm and then type reboot | 08:04 |
ewen | Yes, that's what I did. | 08:04 |
ewen | No further output. | 08:04 |
ewen | Is it the micropython firmware.bin that I upload? Or one of the others? .fbi? .elf? | 08:04 |
shenki | 41%, then died. bbl | 08:04 |
mithro | ewen: When you type reboot, what happens? You should see the bios come up | 08:05 |
ewen | Nope. No further output. | 08:05 |
mithro | oh.... | 08:07 |
mithro | I bet reboot is jumping to address 0 | 08:08 |
mithro | which isn't the correct address on the MimasV2 | 08:08 |
mithro | ewen: can you try hitting the push buttons while flterm is connected | 08:08 |
* ewen goes tries that | 08:09 | |
ewen | Nothing obvious happens when pressing buttons on Mimas V2. Ie SW1 to SW6 | 08:10 |
ewen | Ie, nothing in flterm; nothing in the way of LED status changes. | 08:10 |
mithro | ewen: Let me check which button we connected the reset too | 08:12 |
ewen | Sure. | 08:12 |
mithro | Oh... | 08:13 |
mithro | I think I broke that :-P | 08:14 |
mithro | ewen: I think the reboot is actually connected to SW6 at the moment | 08:14 |
ewen | Okay. I'll go try sw6 again. | 08:15 |
mithro | sorry | 08:15 |
mithro | the little DIP switches | 08:15 |
mithro | the things labeled SW6 are actually "push buttons" | 08:15 |
ewen | Ah. That'd explain the confusion. I was using the push buttons, which are labelled SWN. | 08:16 |
ewen | Not DIP switch 6. | 08:17 |
ewen | But DIP switch 3 seems to have started something looking like a kernel upload. | 08:17 |
ewen | Uploaded, MicroPython banner. | 08:19 |
mithro | I was sure that katharos and myself fixed the order of the switches but maybe we only did the buttons and leds | 08:19 |
ewen | It no longer responds, but I guess that the flterm/MicroPython dislike; will reconnect with screen. | 08:19 |
jimmo | shenki: you're probably right that it's flakey but in about 15 attempts over the past few hours i haven't had a single issue so not sure how to debug :D | 08:20 |
ewen | mithro: Yes, reconnecting with screen gives working MicroPython. | 08:20 |
mithro | jimmo: Did you accidently give shenki one with your accelerated buffered thing | 08:20 |
mithro | ewen: Yay! | 08:20 |
ewen | So toggling dip switch 3 seems to be the other thing I was missing. | 08:20 |
mithro | ewen: Does look like the dip switches are around the wrong way | 08:21 |
jimmo | mithro: that required modifications to the python, so it wouldn't get this far | 08:22 |
ewen | mithro: No worries. At least I now know how to do it. | 08:23 |
ewen | Will turn these notes into a blog post. | 08:23 |
mithro | ewen: I'm fixing that now | 08:23 |
ewen | Yes, I'm going to add a note that it's *supposed* to be dip switch 6... | 08:27 |
mithro | ewen: Well, its actually *supposed* to be SW6 | 08:27 |
ewen | Ah. That'd be a lot more convenient :-) | 08:27 |
ewen | mithro: BTW, it'd be handy if upy-fpga.github.io somehow linked to this channel. | 08:29 |
ewen | The "Chat Channel" link there is empty. | 08:29 |
mithro | ewen: Looks like you are right - Want to fix that up? | 08:31 |
ewen | I'm not sure how one links to FreeNode. But yes, I can submit a pull request if I know what to put in it. | 08:32 |
mithro | I would say "irc://irc.freenode.net/#upy-fpga [WebChat](https://webchat.freenode.net/?channels=#upy-fpga)" - maybe? | 08:33 |
tpb | Title: freenode Web IRC (qwebirc) (at webchat.freenode.net) | 08:33 |
mithro | ewen: Actually - it looks like I put a lot more info in the wiki -> https://github.com/upy-fpga/issues-wiki/wiki | 08:34 |
tpb | Title: Home · upy-fpga/issues-wiki Wiki · GitHub (at github.com) | 08:34 |
mithro | ewen: Maybe the upy-fpga website should just be a redirect to that wiki page.... | 08:35 |
*** upy-fpga-bot has joined #upy-fpga | 08:36 | |
upy-fpga-bot | [upy-fpga-litex-gateware] mithro deleted adv_debug_sys at 7760d79: https://git.io/vyKGo | 08:36 |
*** upy-fpga-bot has left #upy-fpga | 08:36 | |
mithro | jimmo: That reminds me - you got a copy of that stuff we ended up doing for that other FPGA board? | 08:36 |
jimmo | yesssssss...on my other computer | 08:36 |
jimmo | i'll take a look after dinner, just cooking at the moment | 08:37 |
*** upy-fpga-bot has joined #upy-fpga | 08:38 | |
upy-fpga-bot | [upy-fpga-litex-gateware] mithro deleted minispartan6 at 112044b: https://git.io/vyKG6 | 08:38 |
*** upy-fpga-bot has left #upy-fpga | 08:38 | |
mithro | ewen: Okay, I've fixed that up now | 08:39 |
ewen | The website? Or the button issue? | 08:39 |
mithro | ewen: The button issue | 08:40 |
ewen | mithro: Cool. Am working on update for web page. | 08:40 |
*** upy-fpga-bot has joined #upy-fpga | 08:40 | |
upy-fpga-bot | [upy-fpga-litex-gateware] mithro pushed 909 new commits to nextgen: https://git.io/vyKGM | 08:40 |
upy-fpga-bot | upy-fpga-litex-gateware/nextgen 951ab9c Florent Kermarrec: init repo | 08:40 |
upy-fpga-bot | upy-fpga-litex-gateware/nextgen 3b3881b Florent Kermarrec: import platform from Matt O'Gorman's work | 08:40 |
upy-fpga-bot | upy-fpga-litex-gateware/nextgen cc70df9 Florent Kermarrec: platform: do not mix spaces and tabs | 08:40 |
*** upy-fpga-bot has left #upy-fpga | 08:40 | |
mithro | ewen: Can you give that a go? | 08:41 |
ewen | mithro: where is the fix? (I've got about half an hour left tonight.) | 08:41 |
mithro | https://github.com/upy-fpga/upy-fpga-litex-gateware | 08:43 |
tpb | Title: GitHub - upy-fpga/upy-fpga-litex-gateware: SoC based on LiteX for running MicroPython on FPGAs (based on the HDMI2USB SoC) (at github.com) | 08:43 |
ewen | Do I need to do a make clean/make full rebuild? Or will dependencies work? | 08:44 |
mithro | ewen: You'll need to rebuild gateware | 08:46 |
mithro | ewen: But everything else should work with dependencies | 08:47 |
ewen | Okay, I'll give it a try. | 08:47 |
ewen | mithro: 390 files changed (!) | 08:48 |
ewen | I suspect a bunch got merged since I did my first checkout earlier today... | 08:49 |
mithro | ewen: Yeah, I've been working on merging the timvideos/HDMI2USB-misoc-firmware and mithro/HDMI2USB-litex-firmware together | 08:49 |
mithro | (and importing the enjoy-digital/netv2-soc) | 08:49 |
mithro | ewen: Merged your wiki update | 08:50 |
ewen | Thanks. | 08:51 |
mithro | ewen: These notes I wrote for katharos might be interesting to you -> https://github.com/upy-fpga/upy-fpga-litex-gateware/blob/nextgen/doc/notes.md | 08:53 |
tpb | Title: upy-fpga-litex-gateware/notes.md at nextgen · upy-fpga/upy-fpga-litex-gateware · GitHub (at github.com) | 08:53 |
ewen | mithro: Yes, that would haev been very useful a few hours ago :-) | 08:56 |
mithro | ewen: There is also https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/nextgen/getting-started.md | 08:56 |
tpb | Title: HDMI2USB-misoc-firmware/getting-started.md at nextgen · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 08:57 |
ewen | which I notice has been merged into the upy-fpga-litex-gateware repository as of today. | 08:57 |
*** upy-fpga-bot has joined #upy-fpga | 08:57 | |
upy-fpga-bot | [upy-fpga-litex-gateware] mithro pushed 1 new commit to nextgen: https://git.io/vyKZQ | 08:57 |
upy-fpga-bot | upy-fpga-litex-gateware/nextgen 3bee9b7 Tim 'mithro' Ansell: Makefile: Cleanup the targets a little.... | 08:57 |
*** upy-fpga-bot has left #upy-fpga | 08:57 | |
mithro | ewen: Yeah, you are on the cutting edge :-P | 08:58 |
mithro | How does the weekend disappear so quickly :-( | 09:01 |
mithro | ewen: You were at LCA, right? | 09:02 |
ewen | mithro: :-) | 09:02 |
ewen | Yes. | 09:03 |
ewen | mithro: rebuilt, uploaded. SW6 now appears to prompt reset, which then causes firmware upload. | 09:03 |
mithro | ewen: I've also confirmed that reboot is failing because it's jumping to the wrong address :-P | 09:03 |
ewen | Well at least we know the root cause... | 09:04 |
mithro | #define REBOOT __asm__("call r0") | 09:04 |
mithro | r0 == the constant zero | 09:05 |
mithro | Interesting, the reset location doesn't appear to be available to the firmware at the moment | 09:06 |
jimmo | mithro: how do i run firmware-load-mimasv2 ? | 09:11 |
mithro | jimmo: "make firmware-load" ? | 09:12 |
jimmo | i.e. how do i put the LM32 bios into upload mode? | 09:12 |
jimmo | i ran reboot from the prompt but it hung | 09:12 |
mithro | jimmo: hit the reset button, or flash an empty firmware and the bios will complain | 09:13 |
mithro | jimmo: Yeah see above comments | 09:13 |
mithro | https://github.com/enjoy-digital/litex/pull/22 | 09:13 |
jimmo | what's an empty firmware? | 09:13 |
tpb | Title: soc_core: Add CPU_RESET_ADDR as a constant. by mithro · Pull Request #22 · enjoy-digital/litex · GitHub (at github.com) | 09:13 |
jimmo | you mean empty gateware? i.e. gateware-flash ? | 09:13 |
jimmo | also what's the reset button? | 09:14 |
mithro | jimmo: Depends if you have updated in the last 30 minutes or not? | 09:14 |
jimmo | ah pressed buttons until i got it | 09:14 |
mithro | jimmo: should be SW6 | 09:15 |
jimmo | it's faster! | 09:15 |
ewen | mithro: Blog post: http://ewen.mcneill.gen.nz/blog/entry/2017-03-12-micropython-on-numato-mimas-v2/ | 09:24 |
tpb | Title: MicroPython on the Numato Mimas v2 (at ewen.mcneill.gen.nz) | 09:24 |
jimmo | shenki: managed to repro SPI flash programming crash... :( | 09:24 |
mithro | ewen: Awesome! Next job is to get shenki's LED module working | 09:26 |
mithro | ewen: BTW It's perfectly fine to change TARGET/PLATFORM after entering the environment | 09:27 |
ewen | Is there some where that links to these various bits are being kept? | 09:27 |
mithro | ewen: Not really, just kind of people's github repo s | 09:28 |
ewen | Maybe there could be a wiki page with links to WIP? | 09:28 |
ewen | Otherwise it's just rumours that only some people know... | 09:29 |
mithro | ewen: People tend to say stuff on this channel when they do stuff | 09:29 |
mithro | ewen: I'm not sure the current state of the LED flashing stuff, katharos was working on it the other day and I don't know where the micropython side of stuff ended up | 09:30 |
ewen | Okay. It may be a while before I get more time to play. (It took several weeks just to get the Mimas out of the box!) | 09:32 |
mithro | ewen: Thanks for your pull requests and being a guinea pig | 09:32 |
ewen | FTR, I've added breadcrumps to mailing list and ticket pointing at that blog post. In case others are looking. | 09:32 |
ewen | Anyway, now it's time for bed (nearly 22:30 here in NZ) | 09:32 |
mithro | ewen: We are still recovering from LCA :-P | 09:33 |
ewen | :-) | 09:34 |
ewen | Goodnight. Thanks for your help. | 09:34 |
*** ewen has quit IRC | 09:36 | |
mithro | I replied to ewen's email with some extra info | 10:00 |
shenki | jimmo: yay :) at least it's not just me | 10:34 |
jimmo | shenki: it's actually a miracle this thing works at all... the MimasV2Config python script does no error checking | 10:34 |
shenki | i wonder if we've discovered why they were running it at such a low bit rate | 10:38 |
jimmo | shenki: i've pushed an updated firmware & prebuilt | 10:40 |
jimmo | were you able to get it to work at all, or just intermittent? | 10:41 |
shenki | jimmo: i tried about 10 times, and it only got to 100% once | 10:43 |
jimmo | oh well, let me know how you go with the update | 10:45 |
shenki | jimmo: made it to 62% before it hung | 10:48 |
shenki | i wonder what it is about my setup that makes it fail more often | 10:49 |
jimmo | hanging is weird... when you ctrl-c what's the stacktrace? | 10:49 |
jimmo | i guess it'll be the sleep loop | 10:49 |
jimmo | line 492 | 10:51 |
shenki | http://pastebin.com/raw/eh2XAJ1C | 10:52 |
shenki | second go worked. now verifying | 10:53 |
jimmo | it hung before it had finished the erase phase? | 10:53 |
shenki | nope, that was at 62% iirc | 10:54 |
jimmo | your script is different to mine | 10:54 |
jimmo | is yours identical to https://github.com/numato/samplecode/blob/master/FPGA/MimasV2/tools/configuration/python/MimasV2Config.py ? (seems like the line numbers match) | 10:56 |
tpb | Title: samplecode/MimasV2Config.py at master · numato/samplecode · GitHub (at github.com) | 10:56 |
mithro | jimmo: Where did your script come from then?! :-P | 10:57 |
shenki | checking | 10:57 |
shenki | yep, same checksum | 10:57 |
shenki | jimmo wrote his own after looking at the signal traces on his scope | 10:58 |
jimmo | ohh i added some debugging earlier to the top of mine...duhh | 11:01 |
shenki | mithro: how do i get from the hdmi2usb firmware back to the bios? | 11:01 |
jimmo | reset button SW6 | 11:01 |
shenki | SW6 doesn't seem to reset the cpu anymore | 11:02 |
mithro | shenki: When did you last update? | 11:02 |
shenki | mithro: about three hours ago? | 11:02 |
jimmo | shenki: can you get another stack trace if it hangs again plz | 11:02 |
mithro | shenki: Try updating again | 11:02 |
shenki | :/ | 11:02 |
shenki | jimmo: yep will do | 11:02 |
shenki | looks like i will need to reprogram | 11:03 |
shenki | mithro: did the change to not build in the firmware get merged? | 11:06 |
shenki | i just want the bios | 11:06 |
mithro | shenki: Then you need to use mkimage.py with --override-firmware=none | 11:07 |
shenki | jimmo: http://pastebin.com/5TcaY5LU | 11:09 |
tpb | Title: $ make image-flash-mimasv2 PORT=/dev/ttyACM1 python $(which MimasV2Config.py) / - Pastebin.com (at pastebin.com) | 11:09 |
shenki | mithro: thanks | 11:09 |
shenki | jimmo: hung while programming | 11:10 |
jimmo | so in both cases it's hung on the serial write | 11:10 |
mithro | shenki: That looks like it's hung on the Erasing flash sectors? | 11:11 |
shenki | no, the erase completes | 11:11 |
shenki | that was at 19% | 11:11 |
jimmo | mithro: it's confusing because the carriage returns break the output | 11:11 |
jimmo | so this has nothing to do with the programming algorithm, and it looks more like the serial port stopped accepting writes | 11:11 |
jimmo | anything in dmesg? | 11:11 |
shenki | nothing | 11:12 |
shenki | bbl | 11:12 |
jimmo | i defer to my kernel hacker | 11:12 |
mithro | I need a multimeter at my desk | 11:13 |
jimmo | shenki: mithro: i think tim should flash his mimas and see if it's flakey for him | 11:29 |
mithro | Maybe we should dump the existing PIC firmware before doing that? :-P | 11:29 |
jimmo | mithro: i wasn't sure how to do that -- in 5 seconds of looking couldn't see the option on mphidflash | 11:30 |
mithro | jimmo: I wonder if I can do it with the pickit3 | 11:31 |
mithro | I'm going to pop-down to the maker space and solder some headers onto the ICSP and FW up headers | 11:32 |
mithro | brb | 11:32 |
jimmo | mphidflash can verify, so i assume that means it can read, but it'd be a hassle to make it dump out as hex etc | 11:32 |
mithro | headers soldered | 11:40 |
mithro | jimmo: were did you get the mphidflash from? | 11:45 |
jimmo | google code, then compiled it | 11:46 |
mithro | md5sum prebuilt/numato-mimasv2-pic-firmware.production.hex | 11:48 |
mithro | 9a83bc9687683e09db7d396a0fce5015 prebuilt/numato-mimasv2-pic-firmware.production.hex | 11:48 |
mithro | jimmo: Well, I have two serial ports now :-P | 11:50 |
mithro | jimmo: which way around are the PROG/COMM poarts? | 11:52 |
jimmo | SPI is first, UART is second | 11:52 |
mithro | flashing away.... | 12:00 |
mithro | worked okay the first time... | 12:04 |
mithro | Shall I try a few more times? | 12:04 |
mithro | Not having to change the switch is magic! :-P | 12:05 |
mithro | anyone know lm32 asm? :-P | 12:10 |
jimmo | yeah plz try a few times | 12:11 |
jimmo | so it worked for gateware and firmware? | 12:11 |
mithro | "make image-flash" | 12:11 |
mithro | Anyone able to figure out the correct way to do a "goto <address>" in lm32 assemble from https://chromium.googlesource.com/native_client/nacl-binutils/+/master/opcodes/lm32-asm.c ? | 12:13 |
tpb | Title: opcodes/lm32-asm.c - native_client/nacl-binutils - Git at Google (at chromium.googlesource.com) | 12:13 |
mithro | Actually https://chromium.googlesource.com/native_client/nacl-binutils/+/master/opcodes/lm32-desc.c seems more useful | 12:15 |
tpb | Title: opcodes/lm32-desc.c - native_client/nacl-binutils - Git at Google (at chromium.googlesource.com) | 12:15 |
jimmo | "b r0" | 12:15 |
mithro | b r0 is to branch to the value of r0 ? | 12:15 |
mithro | bi <value> | 12:16 |
jimmo | oh <address> is an immediate, yeah, "bi" | 12:17 |
mithro | jimmo: It seems to have worked every time so far | 12:26 |
jimmo | loooooooooooooool i'm pretty sure i figured it out | 12:29 |
jimmo | also fixing this will make spi programming about 2x faster | 12:30 |
mithro | shenki / jimmo: Is there a better way to do this? | 12:31 |
jimmo | do what? | 12:35 |
mithro | http://paste.debian.net/919363/ | 12:35 |
tpb | Title: debian Pastezone (at paste.debian.net) | 12:35 |
jimmo | i thought there was a sprintf-style thing for __asm | 12:40 |
mithro | hrm | 12:40 |
jimmo | maybe like the clobber syntax | 12:41 |
mithro | it's "bi $call" where as other things which take imm seem to be "addi $r1,$r0,$imm" ... | 12:41 |
mithro | (dnop call "call offset" () h-iaddr f-call) | 12:43 |
mithro | (dni bi "branch immediate" () | 12:44 |
mithro | "bi $call" | 12:44 |
mithro | (+ OP_BI call) | 12:44 |
mithro | (set pc (ext SI call)) | 12:44 |
mithro | () | 12:44 |
mithro | ) | 12:44 |
jimmo | maybe you should clarify what your question is? the STRINGIFY macro? | 12:44 |
jimmo | or just whether it will work at all? | 12:44 |
mithro | jimmo: Two different problems, STRINGIFY maco + actually making the ASM work :-P | 12:45 |
jimmo | fyi, the thing i'm thinking of is something like __asm("bi %0" : "=i"(CONFIG_CPU_RESET_ADDR)) maybe | 12:46 |
mithro | I think I might want something like "mvi r0, <value>; b r0" ? | 12:47 |
jimmo | if you want to do the register version (not sure why), then __asm("b %0" : "=r"(CONFIG_CPU_RESET_ADDR)) | 12:48 |
mithro | jimmo: bi seems to take an offset and I have an absolute value | 12:49 |
jimmo | semantics: | 12:50 |
jimmo | (set pc (ext SI call)) | 12:50 |
jimmo | doesn't look like an offset in the docs? | 12:50 |
mithro | Hrm, maybe you are right - it doesn't work however :-P | 12:51 |
jimmo | __asm("bi %[addr]" : : [addr]"i"(CONFIG_CPU_RESET_ADDR)); | 12:58 |
jimmo | when i compile that I get "bi 0" | 12:59 |
jimmo | can be simplieifed to __asm("bi %0" : : "i"(CONFIG_CPU_RESET_ADDR)); | 12:59 |
jimmo | mithro: i declare the MimasV2Config.py script a miracle that it works at all | 13:01 |
shenki | jimmo: oh oh what did you figure out? | 13:01 |
jimmo | shenki: on your next try, please try changing IN_BUFFER_FLUSH_DELAY | 13:01 |
jimmo | or more generally marvel at the incredible hack that that constant represents | 13:02 |
mithro | jimmo: Do you have a thermal gun? | 13:02 |
jimmo | hot air gun? | 13:02 |
jimmo | i.e. reflow | 13:02 |
jimmo | shenki: if i set that to zero, then i flash a lot faster but a lot less reliable. so maybe if you try increasing it | 13:03 |
mithro | jimmo: I mean like a thermal camera type thingy | 13:03 |
jimmo | not a camera, just a point-temperature, yes | 13:03 |
shenki | jimmo: ok | 13:04 |
jimmo | shenki: the problem is that unless you keep reading from the port, the PIC stops being able to TX. and unless it can TX, it doesn't try and read more | 13:04 |
shenki | mithro: re: doing your jump, take a look at this commit: https://github.com/shenki/HDMI2USB-misoc-firmware/commit/bc7f76737b02ff41c3f208eb1c9e390b85cdd5cd | 13:04 |
tpb | Title: firmware: Create simplified firmware · shenki/HDMI2USB-misoc-firmware@bc7f767 · GitHub (at github.com) | 13:04 |
jimmo | shenki: but becaues this code doesn't actually ever look at the replies, it has to rely on Flush to unblock the buffer | 13:04 |
shenki | mithro: the boot_helper macros | 13:05 |
shenki | jimmo: ohh. oops. so it's all the host's fault? | 13:05 |
jimmo | mithro: did that syntax work? | 13:05 |
jimmo | shenki: it's just a crap protocol - one dropped packet and the whole thing fails | 13:06 |
shenki | jimmo: ok | 13:06 |
jimmo | i'll write something better now i know how it works | 13:06 |
shenki | ok | 13:06 |
jimmo | but in hte meantime, i'd be curious to know if messing with that delay improves anything | 13:07 |
shenki | so we have things like openocd on the host. could we implement something that it already knows how to talk to on the pic side? | 13:07 |
mithro | shenki: We can't as the FPGA's jtag lines aren't connected to the PIC | 13:08 |
mithro | shenki: I think we should make the PIC know how to program the SPI flash and then just xmodem the firmware to it | 13:08 |
shenki | ok. but xmodem doesn't have a "reset the FPGA" command | 13:08 |
mithro | I was suggesting we steal xobs' stuff https://github.com/xobs/chibios-netvcr/tree/netvcr/src | 13:09 |
tpb | Title: chibios-netvcr/src at netvcr · xobs/chibios-netvcr · GitHub (at github.com) | 13:09 |
mithro | shenki: I think the PIC could provide a cmd line interface like the TOFE LSIO board does | 13:09 |
shenki | ok. more custom stuff | 13:09 |
shenki | i was suggesting we implement something that the tools already know how to speak | 13:09 |
mithro | once we are happy with it, I'm going to convince numato to put it on a stock one | 13:09 |
mithro | shenki: Well, we could use flterm... | 13:10 |
shenki | that's an argument against it :P | 13:10 |
mithro | shenki: ? | 13:10 |
shenki | flterm is annoying to use with micropython dev as it doesn't implement proper line endings | 13:11 |
shenki | because of that i dislike it | 13:11 |
mithro | shenki: More micropython doesn't accept unix line endings | 13:11 |
shenki | ok. i've not looked into why it doesn't work | 13:12 |
mithro | shenki: I'm pretty sure that is what is going on | 13:13 |
jimmo | surely there are other spi-flash-over-serial programmers out there? | 13:14 |
jimmo | i don't really understand why we can't use openocd? | 13:15 |
shenki | i think we should. what we'd need is a stub that runs on the PIC to take whatever openocd is speaking and do stuff with it | 13:15 |
shenki | jimmo: changing the delay from 0.05 to 0.10 got it to 97% | 13:16 |
mithro | I need to head home | 13:16 |
jimmo | maybe try changing FlushInBuffer to do it twice or something? | 13:16 |
*** upy-fpga-bot has joined #upy-fpga | 13:16 | |
upy-fpga-bot | [upy-fpga-litex-gateware] mithro pushed 1 new commit to nextgen: https://git.io/vyK0f | 13:16 |
upy-fpga-bot | upy-fpga-litex-gateware/nextgen ab27f57 Tim 'mithro' Ansell: Temporary hack for Jimmo's MimasV2 change. | 13:16 |
*** upy-fpga-bot has left #upy-fpga | 13:16 | |
mithro | shenki: Oh - actually that could work if openocd programs the SPI flash directory (rather then using the normal flash_proxy method) | 13:17 |
shenki | jimmo: changing it to 0.01 made it go really fast, but failed at 62% | 13:17 |
mithro | shenki: But I actually think the xmodem method is viable because I plan to make the normal firmware support replacing it self using that too | 13:17 |
shenki | i will look at FlushInBuffer | 13:18 |
mithro | If you set "export JIMMO=1" you should get make targets which work with Jim's stuff | 13:18 |
shenki | haha, hax. nice. | 13:18 |
mithro | horrible horrible hack but I need to run home and put stuff in the drier | 13:18 |
mithro | shenki: Could you make your reboot-helper change just work in the normal firmware without deleting everything? :-P | 13:19 |
mithro | be back in 30 | 13:19 |
mithro | shenki: BTW "export CPU=or1k" :-P | 13:20 |
shenki | i was thinking you could use the macro to put the jump location into a register, so you can use it to jump to whatever function you want | 13:21 |
shenki | it's kinda hacky. i assume the lm32 ABI says which args go in which regs, but it might not gaurntee | 13:21 |
jimmo | mithro: did the inline asm syntax i gave you work? | 13:21 |
shenki | guarantee | 13:21 |
shenki | you should use jimmo's inline asm | 13:21 |
shenki | that's the not-noob way of doing it | 13:22 |
shenki | jimmo: changing my FlushInBuffer to look like this worked with a 0.01 delay: | 13:22 |
shenki | time.sleep(IN_BUFFER_FLUSH_DELAY) | 13:22 |
shenki | self.PortObj.flushInput() | 13:22 |
shenki | time.sleep(IN_BUFFER_FLUSH_DELAY) | 13:22 |
shenki | self.PortObj.flushInput() | 13:22 |
jimmo | woooooooooooo! | 13:22 |
jimmo | worked first time? | 13:22 |
jimmo | so that's both faster and more reliable :D | 13:23 |
shenki | yeah, it worked the one time i tried it | 13:23 |
shenki | shit it! | 13:23 |
shenki | oops | 13:23 |
shenki | ship it! | 13:23 |
shenki | woot, my python still works | 13:24 |
shenki | >>> one = litex.LED(1) | 13:24 |
shenki | >>> one.on() | 13:24 |
shenki | >>> one.off() | 13:24 |
shenki | makes leds flash | 13:24 |
shenki | yay for no bitrott | 13:24 |
mithro | shenki: I believe they might even be the right way around now? | 13:25 |
* mithro is walking home | 13:25 | |
shenki | i'm pretty sure they were the right way around when i last tested? | 13:25 |
shenki | maybe not | 13:25 |
mithro | Yay mobile phones | 13:25 |
shenki | mithro: i have your mimasv2: Fixing the reset button. commit but the reset button still does not work | 13:29 |
mithro | It does for me... | 13:29 |
mithro | You pressing the push button labelled sw6? | 13:30 |
mithro | And how are you testing? | 13:30 |
shenki | yes, i am | 13:31 |
shenki | im looking at the uart and pressing SW6 | 13:31 |
mithro | Do you have any prompt already? | 13:31 |
shenki | yes | 13:31 |
shenki | did you fix the makefile rules so programming generates the programming file? | 13:31 |
shenki | if not, i might have had old gateware | 13:31 |
mithro | Yes | 13:31 |
shenki | ok | 13:32 |
mithro | But gateware building is always manual | 13:32 |
shenki | rebuilding my gateware to be sure | 13:32 |
mithro | Then 'make image-flash' | 13:33 |
mithro | mkimage.py is pretty verbose | 13:34 |
shenki | that's an understatement | 13:34 |
shenki | jimmo: doh, died on 10% | 13:35 |
shenki | worked on second go | 13:37 |
mithro | Reset working? | 13:38 |
shenki | yes | 13:38 |
mithro | shenki: Yay! | 13:43 |
* mithro is at home now | 13:43 | |
shenki | mithro: so you think the sd card would be a good thing to look at next? | 13:48 |
mithro | shenki: Yeah | 13:57 |
mithro | shenki: Did I link you florent's stuff? | 13:58 |
mithro | https://github.com/enjoy-digital/sdcard_test | 13:58 |
tpb | Title: GitHub - enjoy-digital/sdcard_test: SDCard core test with LiteX (at github.com) | 13:58 |
mithro | First step would be reading bytes of an sdcard :-) | 13:58 |
mithro | sdcard will be useful for both the HDMI2USB stuff and the micropython stuff | 14:00 |
mithro | well, bed time for me | 14:20 |
*** _florent_ has joined #upy-fpga | 20:10 | |
*** tsukasa_au has joined #upy-fpga | 22:31 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!