| *** tpb has joined #tomu | 00:00 | |
| *** rohitksingh has joined #tomu | 00:05 | |
| *** xantoz has joined #tomu | 00:29 | |
| *** rohitksingh has quit IRC | 01:00 | |
| *** cedric has quit IRC | 01:14 | |
| *** cedric has joined #tomu | 01:16 | |
| *** cedric has joined #tomu | 01:16 | |
| *** rohitksingh has joined #tomu | 01:21 | |
| mithro | xobs: ping? | 01:55 |
|---|---|---|
| xobs | mithro: afternoon | 01:55 |
| mithro | xobs: https://github.com/im-tomu/fomu-reference-manual/issues/1 - you are thinking like a hardware person - i you are not taking advantage of the configurability of it being an FPGA, you are much better off using an ARM ASIC. | 01:56 |
| tpb | Title: Having addresses is bad style · Issue #1 · im-tomu/fomu-reference-manual · GitHub (at github.com) | 01:56 |
| mithro | The solution is to ship the gateware with the firmware together rather than trying to ship them separately. | 01:56 |
| mithro | IE Ship the gateware which matches the svd file | 01:57 |
| xobs | That makes it so much less flexible, though, because then you won't be able to load any code onto it. | 01:58 |
| xobs | I'm thinking like a hardware person because Fomu is a hardware product. | 01:59 |
| mithro | xobs: How full is your design currently? | 01:59 |
| xobs | 96% full | 01:59 |
| mithro | So, to add anything more you have to remove something | 02:00 |
| xobs | Correct, at which point they're building their own bitstreams and generating their own reference manuals. | 02:00 |
| mithro | Yes, but all the code they have written will stop working | 02:01 |
| mithro | Because it is using hard coded addresses | 02:01 |
| xobs | Right, but at that point they're using a different SoC, so the documentation no longer applies. | 02:02 |
| xobs | The reference manual is for "Fomu Bootloader" | 02:02 |
| mithro | xobs: we want it to be easy to move up and down the stack | 02:05 |
| xobs | mithro: I agree. And if we don't guarantee things like memory offsets, then we can't do things like ship a micropython binary. Or Rust crates. | 02:06 |
| mithro | xobs: So taking the Fomu bootloader and customizing it (and thus having your address change) without having everything break it a good idea | 02:06 |
| mithro | xobs: Sure we can, we just need to ship the gateware with the binary or rust crate | 02:07 |
| mithro | xobs: Can have the bootloader even just check that the gateware matches and not update it | 02:08 |
| mithro | IE The gateware should provide header files and other data that includes where things are found | 02:10 |
| xobs | I don't think it's a good idea that addresses can randomly change. It's why I've pinned them in Foboot. It's caused a lot of headache in the past, even with real hardware such as the i.MX6Q/DL which had different io pin mappings. | 02:11 |
| mithro | xobs: It causes more headaches the less you do it | 02:12 |
| mithro | xobs: It also makes you put in checks like "check that gateware you are running on matches the gateware you expected" | 02:13 |
| xobs | mithro: I don't see why having addresses move around is a good thing, and I see many reasons why it's bad. It seems like a misfeature. | 02:17 |
| xobs | And if you remove a block, then the documentation is invalid anyway. | 02:18 |
| xobs | By making it easy to generate documentation, people can understand how to use the thing they've created. | 02:18 |
| mithro | xobs: Does a person care about the address? Or do they care about what functionality is available? | 02:19 |
| xobs | Documenting the SoC in its entirety, especially by giving memory addresses, helps to explain how the system is set up and how the thing they've created behaves. | 02:19 |
| xobs | Both, usually. | 02:19 |
| mithro | xobs: Why do you care about the address? | 02:19 |
| xobs | The first thing I do when I get access to a new system is find the addresses for everything and implement peek/poke so I can understand how it works. | 02:19 |
| xobs | The address is super important because it gives you a direct handle to operate functionality at a very low level. | 02:20 |
| xobs | Once you have that you can build up drivers and such. But at a fundamental level you need to know the address and register mappings to be able to understand a thing. | 02:21 |
| mithro | xobs: Your still thinking of peripherals and hardware as separate from the software -- When I start using a new C library, I don't start by looking at where the linker puts the library in memory and the calling convention of my architecture | 02:24 |
| xobs | It's why people have done things such as wrapping `wishbone-tool` to write raw addresses from Ruby: https://leap.tardate.com/fpga/fomu/buildnotifier/ | 02:24 |
| tpb | Title: LEAP#494 (at leap.tardate.com) | 02:24 |
| xobs | mithro: peripherals and hardware /are/ separate from software. At least when you use Fomu as a SoC. | 02:25 |
| mithro | xobs: wishbone-tool would be much nicer if you could just use the CSR_RGB_DAT_ADDR names directly | 02:26 |
| mithro | xobs: That is what we should be promoting | 02:29 |
| mithro | xobs: FYI - I'm all for the auto-building of a nice manual | 02:35 |
| *** ademski has quit IRC | 02:36 | |
| *** andi- has quit IRC | 02:46 | |
| mithro | xobs: I think we should be promoting using dynamic names | 02:47 |
| xobs | mithro: Again, if we do that we can't ship things like micropython anymore. Or if we do, we need to bundle it with a bitstream of its own, which will more than double the amount of time it takes to load. And I don't see the upside to that complexity or increased wait time. | 02:49 |
| *** andi- has joined #tomu | 02:56 | |
| xobs | mithro: Having said that, https://github.com/xobs/wishbone-utils/commit/0eebc06430c14d648a9d09873f01a26d729c2c8e | 03:52 |
| tpb | Title: csr-csv: support passing a csv file to use named variables · xobs/wishbone-utils@0eebc06 · GitHub (at github.com) | 03:52 |
| *** CarlFK has joined #tomu | 04:05 | |
| *** rohitksingh has quit IRC | 04:11 | |
| *** im-tomu has left #tomu | 06:30 | |
| *** im-tomu has joined #tomu | 06:30 | |
| *** im-tomu has left #tomu | 06:36 | |
| *** im-tomu has joined #tomu | 06:36 | |
| *** im-tomu has quit IRC | 06:46 | |
| *** im-tomu has joined #tomu | 06:47 | |
| *** im-tomu has left #tomu | 06:57 | |
| *** im-tomu has joined #tomu | 06:57 | |
| *** CarlFK has quit IRC | 06:57 | |
| *** CarlFK has joined #tomu | 06:57 | |
| *** cedric has quit IRC | 07:58 | |
| *** cedric has joined #tomu | 07:58 | |
| *** cedric has joined #tomu | 07:58 | |
| *** im-tomu has left #tomu | 08:18 | |
| *** im-tomu has joined #tomu | 08:18 | |
| *** im-tomu has left #tomu | 08:23 | |
| *** im-tomu has joined #tomu | 08:23 | |
| *** cedric has quit IRC | 10:16 | |
| *** cedric has joined #tomu | 10:16 | |
| *** cedric has joined #tomu | 10:16 | |
| *** ademski has joined #tomu | 12:43 | |
| *** emeb has joined #tomu | 13:45 | |
| *** CarlFK has quit IRC | 15:46 | |
| *** rohitksingh has joined #tomu | 16:10 | |
| *** rohitksingh has quit IRC | 16:35 | |
| *** rohitksingh has joined #tomu | 16:41 | |
| *** rohitksingh has quit IRC | 17:22 | |
| *** CarlFK has joined #tomu | 17:37 | |
| *** rohitksingh has joined #tomu | 17:45 | |
| *** rohitksingh has quit IRC | 17:54 | |
| *** rohitksingh has joined #tomu | 18:22 | |
| *** rohitksingh has quit IRC | 18:51 | |
| *** rohitksingh has joined #tomu | 19:04 | |
| *** alexhw has quit IRC | 19:35 | |
| *** alexhw has joined #tomu | 19:36 | |
| *** alexhw has quit IRC | 19:38 | |
| synaption[m] | random question. what fab was used for the fomu? I'm looking into laser-drilled microvias. | 20:33 |
| *** rohitksingh has quit IRC | 21:07 | |
| *** ademski has quit IRC | 21:11 | |
| *** ademski has joined #tomu | 21:13 | |
| *** ademski has quit IRC | 21:14 | |
| *** rohitksingh has joined #tomu | 21:14 | |
| *** alexhw has joined #tomu | 22:04 | |
| *** rohitksingh has quit IRC | 22:30 | |
| *** ademski has joined #tomu | 22:43 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!