| *** tpb has joined #tomu | 00:00 | |
| *** deltab has joined #tomu | 00:01 | |
| *** dwg has quit IRC | 01:26 | |
| *** dwg has joined #tomu | 01:27 | |
| *** rohitksingh has quit IRC | 01:33 | |
| *** CarlFK has quit IRC | 01:59 | |
| *** rohitksingh has joined #tomu | 02:10 | |
| *** rohitksingh has quit IRC | 04:06 | |
| *** rohitksingh has joined #tomu | 04:28 | |
| *** CarlFK has joined #tomu | 05:28 | |
| *** kamil_r has joined #tomu | 05:54 | |
| xobs | The UP5K is a challenging chip to work with. "Info: Max frequency for clock 'clk12_$glb_clk': 11.62 MHz (FAIL at 12.00 MHz)" | 08:56 |
|---|---|---|
| MadHacker | It's weirdly touchy about exactly what's in it, though. My 6502 was running at the full 48MHz. | 09:39 |
| MadHacker | "My" - arlet's. | 09:39 |
| MadHacker | Just got to keep an eye on the combinatorial path lengths, I guess. | 09:39 |
| xobs | Yeah. This is me trying to cram an MMU in there. It's the adder, plus the dcache, plus the icache, plus that finnicky MMU. | 09:40 |
| xobs | Not that it's easy to see what the critical path /is/ after it's been through `abc`. | 09:40 |
| MadHacker | Absolutely. | 09:42 |
| MadHacker | And an MMU is basically hell for these things, since it's always at least in the address bus path. :/ | 09:42 |
| xobs | Yeah. But think of the cool things we could do with it! And I'm only ~400 kHz short. | 09:43 |
| xobs | Time to poke at yosys options some more. | 09:43 |
| MadHacker | Is the cache virtually or physically mapped? | 09:43 |
| MadHacker | If it's a virtual mapping you might be able to take a one-cycle hit on access to real RAM through the MMU without slowing up the cache. | 09:44 |
| xobs | I'm not sure. It's just something that's part of Vex. | 09:44 |
| xobs | And it's only the icache. I never got the dcache working with this short pipeline. | 09:44 |
| MadHacker | Aye, fair enough. I've not looked at the RISC-V stuff beyond the first blinkenlights; I don't doubt it works, but I wanted a CPU I understood end-to-end myself. | 09:45 |
| MadHacker | (plus a lot of slack space in the FPGA!) | 09:45 |
| xobs | 6502 satisfies that nicely. | 09:45 |
| MadHacker | As you say. | 09:45 |
| xobs | By the way, is there a decent C compiler for 6502? Or is asm still the preferred method? | 09:46 |
| MadHacker | cc65 produces something valid enough. I don't think I'd call it "decent", exactly, but for the sort of code you'd want to run on the 6502, it's OK. | 09:46 |
| MadHacker | I was using the assembler bit of it in my first non-USB-y blinkenlights project for the fomu to assemble my test ROM. | 09:47 |
| MadHacker | https://cc65.github.io/ <-- this thing. | 09:47 |
| tpb | Title: cc65 - a freeware C compiler for 6502 based systems (at cc65.github.io) | 09:47 |
| MadHacker | The list of supported platforms is basically a red herring. You can just add a linker script to suit whatever layout you like without much fuss. | 09:47 |
| xobs | `ERROR: Max frequency for clock 'clk12_$glb_clk': 11.88 MHz (FAIL at 12.00 MHz)` Getting closer. Just 100 kHz away. | 09:49 |
| MadHacker | When I first looked at migen/litex and friends, I was sort of hoping to just drop the 6502 core and cc65 into litex, and make it build for the 6502 instead of RISC-V. | 09:49 |
| MadHacker | There's quite a high bar in terms of assumptions about address bus width, space, etc. though. | 09:49 |
| xobs | That should be possible. So long as you can hook the 6502 up to Wishbone. | 09:50 |
| MadHacker | Not saying it's not possible, but I don't feel it's a good fit unfortunately. Shame, I'd have liked a 6502 litex. | 09:50 |
| xobs | I'd love to see what it would take to adapt litex to work with a 16-bit bus. | 09:50 |
| xobs | I think that would make the ICE40 happier. | 09:50 |
| MadHacker | Well, I've got that, but it's a non-transparent bus bridge, so you can't sensibly take the existing C driver code etc. and use it. | 09:50 |
| xobs | And suss out lots of bugs. | 09:50 |
| xobs | How do you mean? | 09:51 |
| MadHacker | Basically four byte-wide registers to write an address, and then you read/write from another group of four to trigger a wishbone read/write. The first byte on a read, and the last byte on a write, triggers the wishbone transaction. | 09:51 |
| *** rohitksingh has quit IRC | 09:51 | |
| MadHacker | So the wishbone bus is basically not in the 6502's address space; just eight registers to talk to it are. | 09:51 |
| MadHacker | I could do a slightly fancier mapping where, say, 256 byte of 6502 address space are mapped across instead, I guess. | 09:52 |
| xobs | You could adapt it to a 16-bit bus. Or even an 8-bit bus. Wishbone is designed to be variable-width. Though I think that litex in particular assumes a 32-bit bus. | 09:52 |
| MadHacker | Wishbone itself is perfectly OK with it. | 09:52 |
| MadHacker | (slow as hell compared to the 6502 native bus, but unproblematic) | 09:52 |
| MadHacker | Litex isn't. | 09:52 |
| xobs | However, litex makes heavy use of the CSR bus which is just another wishbone peripheral, and the CSR bus even on Fomu is 8-bits. | 09:53 |
| MadHacker | Think the latest in git has some extra parameters to let you specify the CSR spacing, but as standard it puts device CSRs something like 0x800 separation apart. | 09:53 |
| MadHacker | That eats into your 16-bit space fast. | 09:53 |
| MadHacker | Since I can't use the litex C-side stuff at all either (non-transparent bridge) it didn't seem worth the effort; my stuff is migen-y but not litex-y. | 09:54 |
| xobs | Well -- and others might be interested in this too -- I've been on a big documentation kick lately, so I can get a better idea of how things are all laid out. | 09:54 |
| MadHacker | If we can get a 6502 into litex, I'd be delighted, not least because that then opens up a bunch of options for using litex peripherals in real 6502 systems too. | 09:55 |
| MadHacker | But also just for general understandability. | 09:55 |
| xobs | Here's the work-in-progress for register-level documentation for the new version of Foboot I'm working on: https://doctest.xobs.io/ | 09:55 |
| tpb | Title: Documentation for LiteX SoC Project LiteX SoC Project documentation (at doctest.xobs.io) | 09:56 |
| MadHacker | Thanks. | 09:56 |
| xobs | I need to figure out why my server is so protective about files -- the register maps might not have loaded, so if you don't see any register diagrams reload the page. | 09:57 |
| MadHacker | Neat. Are you forcing the CSR base addresses, or just relying on the default litex AutoCSR behaviour? | 09:57 |
| MadHacker | I have some diagrams, yep. | 09:57 |
| MadHacker | 'tis tidy. | 09:57 |
| xobs | For Fomu, I'm fixing the CSR bank offsets, so even if I remove CSRs the addresses won't change. | 09:58 |
| MadHacker | Is the USB stuff for your trififo thing? | 09:58 |
| xobs | Since this is the new Foboot SoC, yes. That's trififo. | 09:58 |
| MadHacker | Nice. That's a tidy interface. | 09:58 |
| xobs | I don't yet have module-level documentation, that'll come later. | 09:59 |
| MadHacker | Hm, why does the USB_SETUP_CTRL need a bit for ADVANCE? | 09:59 |
| xobs | But register-level documentation (down to the bit level) is super exciting to me. | 10:00 |
| MadHacker | Can't the read transaction advance the FIFO on its own? | 10:00 |
| xobs | MadHacker: CSRStatus registers have no `read` flag we can look for. | 10:00 |
| MadHacker | (Wishbone transaction) | 10:00 |
| MadHacker | Huh. That's sad. :/ | 10:00 |
| MadHacker | Guess we want a CSRFIFO really for that. | 10:00 |
| xobs | Yeah. It might be a thing to add. | 10:00 |
| xobs | I wonder how difficult it would be to plumb that in. | 10:02 |
| MadHacker | Strikes me it's likely one of those simple, but hard to get right in 100% of circumstances, ones. Depends a bit if the CSR space handles bursts etc. | 10:03 |
| xobs | But you can see how all registers are 8-bits. The CSR bus ought to map nicely onto the 6502, provided we change the spacing. | 10:04 |
| MadHacker | Sure, the actual register width is fine. | 10:08 |
| MadHacker | 6502 RAM bus is somewhat non-wishbone-compatible would be the other issue, in terms of timing. | 10:09 |
| MadHacker | Every cycle is prodcutively used on the 6502, excepting only for the middle cycle in a three-cycle read-modify-write. | 10:09 |
| MadHacker | Making every transaction wait a cycle kind of destroys the performance of an already slow CPU. :/ | 10:10 |
| MadHacker | Arlet's 6502 runs one cycle ahead, so you can get away with it linked directly to block RAM, but you can't have anything latched in between. | 10:10 |
| MadHacker | It's somewhat OK for IO, but I wouldn't want that for main RAM. | 10:12 |
| xobs | Designate half of memory as mmio. I think most csr accesses assume single cycle. | 10:29 |
| MadHacker | That's a quick route to no space for software. Using the BBC micro as an example - a 6502 machine with a *LOT* of IO - three pages of 256 bytes is the whole MMIO space. | 10:30 |
| MadHacker | But nevertheless, yes, slower MMIO space is perfectly sane. | 10:31 |
| MadHacker | (and that specific computer did the same, in fact - 2MHz RAM/ROM, but 1MHz MMIO mostly) | 10:31 |
| MadHacker | Clock-stretching magic. | 10:32 |
| MadHacker | Heh. Meanwhile, I have to explain to marketing here why a 27MB JPEG is not OK for the front page of a site. :D | 10:37 |
| MadHacker | Should make 'em build pages on a machine with 4M or RAM or something. :) | 10:38 |
| ovf | MadHacker: that'll also allow them to see the full page at once, no stupid landscape 16:9 crap. https://3894a8e173f5f8870a41-c88208a08312eda3cf96a15131ffd631.ssl.cf1.rackcdn.com/radius-ad1487116026657.jpg | 11:07 |
| MadHacker | Right? | 11:08 |
| MadHacker | (I actually use two 16:9 monitors in portrait at home, albeit either size of a 21:9 monster landscape one) | 11:08 |
| xobs | `Info: Max frequency for clock 'clk12_$glb_clk': 12.09 MHz (PASS at 12.00 MHz) ` You know what? I'll take it. | 12:03 |
| MadHacker | Heh! | 12:10 |
| MadHacker | Cutting it fine. | 12:10 |
| *** ademski has joined #tomu | 12:26 | |
| xobs | Sure takes forever to route. | 13:41 |
| *** CarlFK has quit IRC | 13:42 | |
| *** greni has joined #tomu | 13:44 | |
| greni | hi, who to compile yosys for Fomu? | 13:45 |
| xobs | I built `fomu-toolchain`, which includes yosys. | 13:46 |
| greni | I'm cheking this: https://github.com/im-tomu/fomu-workshop when I use yosys from the fomu toolchain in work | 13:46 |
| tpb | Title: GitHub - im-tomu/fomu-workshop: Support files for participating in a Fomu workshop (at github.com) | 13:46 |
| greni | yes, but I have now upstream yosys, yosys from fomu toolchain, yosys from apio, yosys from litex-buildenv, yosys from symbiflow | 13:47 |
| greni | that's thy I'm to not use the fomu toolchain and use yosys that I have already installed on my system | 13:49 |
| greni | when I run "python3 workshop.py --board hacker" the build is fine, but the board is not booting | 13:50 |
| greni | so how can I compile the upstream yosys for fomu? what is needed? a spacial patch or should it work out of the box? | 13:52 |
| xobs | What model Fomu do you have? | 13:52 |
| greni | hacker | 13:53 |
| xobs | Upstream Yosys should work out of the box. I don't know about the others -- I know the version from apio was missing things like dsp support, for example. | 13:53 |
| greni | after executing "dfu-util -D build/gateware/top.dfu" USB device is getting disconnected and nothing happens | 13:54 |
| greni | no new USB device | 13:54 |
| greni | but everything works fine when I use the fomu toolchain | 13:54 |
| greni | yosys from fomu reports " (Fomu build) " so I thought that it's a special version, patched for fomu | 13:56 |
| xobs | No, the build just defines YOSYS_VER. The build script (based on the Apio one) is at https://github.com/xobs/toolchain-icestorm/blob/master/scripts/compile_yosys.sh | 13:59 |
| tpb | Title: toolchain-icestorm/compile_yosys.sh at master · xobs/toolchain-icestorm · GitHub (at github.com) | 13:59 |
| greni | ok, I will pull all recent changes yosys, nextpnr, migen, litex and check it again, I did it a few days ago | 14:00 |
| xobs | That should be fine, too. Though some people on mac are reporting a regression in nextpnr speed. | 14:01 |
| xobs | Note also that we build with the heap placer, which I don't remember if that's enabled by default. | 14:01 |
| greni | ok thanks, thanks also for fomu-workshop it's very useful, wishbone-tool does not work for me but I will compile it also and check all once more | 14:06 |
| xobs | That's interesting that it didn't work with your version of yosys. | 14:06 |
| xobs | wishbone-tool doesn't work? | 14:07 |
| *** emeb has joined #tomu | 14:11 | |
| greni | yes, sometimes it works, but in 60-70% i'm getting USB error | 14:15 |
| xobs | What version of foboot is it running? | 14:17 |
| greni | "Fomu DFU Bootloader v1.7.2-3-g9013054" | 14:17 |
| xobs | That's a relatively old version, which had some timing issues with USB. Those should all be fixed as of v1.8.7, and SET_ADDRESS issues were fixed with 1.9.1. | 14:22 |
| xobs | There's a lightly-tested updater at https://github.com/im-tomu/foboot/blob/master/releases/v1.9.1/hacker-top-installable.dfu if you're feeling adventurous. It does lots of checks before installing itself, and I've run it on my boards. | 14:23 |
| tpb | Title: foboot/hacker-top-installable.dfu at master · im-tomu/foboot · GitHub (at github.com) | 14:23 |
| greni | thanks, I will check, how can I update, dfu-util -D ...? :D or I need a special JIG? | 14:29 |
| xobs | Yes, dfu-util -D. It takes a few seconds to check, then it goes all rainbowey while it updates. | 14:29 |
| greni | hmm have just tried it, dfu-util -D hacker-top-installable.dfu went fine, but after a power cycle I still have the old version | 14:31 |
| xobs | That could mean that the image was corrupted. Though I thought it was supposed to blink "red" when that happened. | 14:33 |
| greni | tried on two boards, same result, I will check on another PC, I think it was working better on USB 2.0 here I have 3.0 only | 14:35 |
| xobs | What is the result? | 14:35 |
| xobs | The update takes about 30 seconds. So after you upload, it takes about 10 seconds to check, then it starts the update. | 14:36 |
| greni | updates takes someting about 30s, the led blinks red during the update | 14:36 |
| greni | after 30 the led is turned off | 14:36 |
| greni | dfu-util -l shows nothis | 14:36 |
| greni | power cycle | 14:36 |
| greni | dfu-util shows "Fomu DFU Bootloader v1.7.2-3-g9013054" | 14:37 |
| xobs | That definitely sounds like a failure to upload. | 14:37 |
| xobs | What do you get when you run "file hacker-top-installable.dfu"? | 14:37 |
| * ssb ponders updating his pvt v1.8.7 | 14:38 | |
| greni | hacker-top-installable.dfu: data | 14:39 |
| greni | 72706032af312534272cefbadb2441e6 hacker-top-installable.dfu | 14:39 |
| ssb | [373484.257738] usb 1-2: Product: Fomu PVT running DFU Bootloader v1.9.1 | 14:40 |
| greni | pwd : /tmp/foboot/releases/v1.9.1 | 14:40 |
| xobs | ssb: Hooray! | 14:40 |
| ssb | xobs, and thanks again for the awesome stuff. ) | 14:41 |
| xobs | greni: That's supremely odd. I'm going to guess it's getting corrupted somewhere during the upload. | 14:41 |
| xobs | ssb: And thanks for testing it :) | 14:41 |
| greni | xobs: ok thanks, I will check on another PC, maybe after the update it will work also on this one | 14:42 |
| greni | maybe I have no problem with yosys, but with the old bootloader version | 14:43 |
| xobs | That's my suspicion. | 14:43 |
| ssb | btw, is it "empty" now? What happens if I run "dfu-util -e" now? | 14:43 |
| ssb | okay, nothing interesting: it apparently rebooted itself and re-enumerated ) | 14:44 |
| xobs | ssb: Effectively, yes: https://github.com/im-tomu/foboot/blob/master/booster/src/main.c#L107 | 14:45 |
| tpb | Title: foboot/main.c at master · im-tomu/foboot · GitHub (at github.com) | 14:45 |
| xobs | The actual updater software lives at offset 0x5a000, which gets erased after the update. | 14:45 |
| ssb | ah, cool | 14:45 |
| xobs | So if you run `dfu-util -e` it will actually reboot to the bitstream at offset 0x40000, which just so happens to be identical to the image at address 0. | 14:45 |
| *** greni has quit IRC | 14:46 | |
| *** greni has joined #tomu | 15:02 | |
| greni | xobs: I've just tried to do the update using different PC with USB2.0/3.0 and it didn't work, still old version:/, I think I will have to build the update JIG | 15:17 |
| xobs | greni: What if you load hacker-top.bin? Does that work temporarily? | 15:28 |
| greni | dfu-util -D hacker-top-installable.bin ? | 15:31 |
| greni | sorry, dfu-util -D hacker-top.bin, same result | 15:35 |
| xobs | greni: I'd say that's actually a good sign. It means that it's consistent. For whatever reason the upload process isn't reliable on your version. Updating it in a test jig would definitely fix that. | 15:36 |
| greni | xobs: thanks, I will to build it | 15:40 |
| greni | I will try.... should be doable | 15:40 |
| *** CarlFK has joined #tomu | 16:20 | |
| greni | xobs: I've just built the jig and updated my board to "Fomu Hacker running DFU Bootloader v1.9.1", built the litex example using the latest upstream yosys | 17:30 |
| greni | and wishbone-tool works fine now | 17:30 |
| greni | thanks | 17:30 |
| *** rohitksingh has joined #tomu | 18:28 | |
| *** asante has quit IRC | 18:28 | |
| *** alexhw has quit IRC | 18:28 | |
| *** asante has joined #tomu | 18:29 | |
| *** asante has joined #tomu | 18:29 | |
| *** alexhw has joined #tomu | 18:29 | |
| *** rohitksingh has quit IRC | 19:16 | |
| *** rohitksingh has joined #tomu | 20:12 | |
| *** rohitksingh has quit IRC | 20:23 | |
| *** rohitksingh has joined #tomu | 20:24 | |
| *** greni has quit IRC | 20:40 | |
| *** rohitksingh has quit IRC | 20:41 | |
| *** ademski has quit IRC | 20:49 | |
| *** rohitksingh has joined #tomu | 21:38 | |
| *** rohitksingh has quit IRC | 21:53 | |
| *** rohitksingh has joined #tomu | 21:55 | |
| *** emeb has quit IRC | 23:23 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
