| openpowerbot | [slack] <mithro> @Benjamin Herrenschmidt LiteX has been adding AXI support recently but I don't know the current state | 00:09 |
|---|---|---|
| openpowerbot | [slack] <mithro> @Benjamin Herrenschmidt Also, Antmicro was working on Wishbone pipelining --> https://antmicro.com/blog/2022/05/faster-soc-interconnects-with-test-driven-fpga-development-and-cocotb/ | 00:10 |
| openpowerbot | [slack] <mithro> @Benjamin Herrenschmidt We generally connect the video system directly to the DMA / LiteDRAM port | 00:11 |
| openpowerbot | [slack] <mithro> @Benjamin Herrenschmidt https://github.com/timvideos/litex-buildenv/blob/master/targets/atlys/video.py | 00:13 |
| openpowerbot | [slack] <mithro> @Benjamin Herrenschmidt https://github.com/timvideos/litex-buildenv/blob/master/targets/atlys/video.py | 00:13 |
| openpowerbot | [slack] <mithro> @Benjamin Herrenschmidt Using `ycbcr422` pixel mode rather than `rgb` halves the memory bandwidth requirements | 00:14 |
| openpowerbot | [slack] <mithro> https://github.com/timvideos/litex-buildenv/blob/master/targets/opsis/video.py | 00:15 |
| openpowerbot | [slack] <mithro> https://github.com/timvideos/litex-buildenv/blob/master/targets/opsis/video.py | 00:15 |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has joined #microwatt | 00:24 | |
| openpowerbot | [slack] <Ganesan Narayanasamy> https://www.linkedin.com/feed/update/urn:li:activity:6974625255097061376/?commentUrn=urn%3Ali%3Acomment%3A(ugcPost%3A6974625254065274880%2C6974682600388911104)&dashCommentUrn=urn%3Ali%3Afsd_comment%3A(6974682600388911104%2Curn%3Ali%3AugcPost%3A6974625254065274880) | 02:27 |
| openpowerbot | [slack] <Jeremy Kerr> @cdrx I tried to send you a PR for your qemu repo, but the qemu upstream github actions auto-closed it. I have sent as an email instead, apologies for the noise! | 03:39 |
| openpowerbot | [slack] <Matt Johnston> anyone got thoughts on how a system reset should be triggered from software in microwatt? | 04:14 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> @mithro WB pipelining in LiteX would be a good start to improve things like litesdcard perf. As for video, while ycbcr is nice it's not super suitable for running a console or X11. I'd rather use 5:6:5 rgb in that case. As for using a separate litedram port, while that makes sense in a LiteX based video centric application it doesn't really here , or rather, it would make things messy having t | 05:22 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> Basically think of having one handshakes command channel with the addresses, write data and an originator tag, and one handshaked response channel with read data. I'm also thinking having all writes posted, so no write responses. This would be only slightly more resources hungry than wb (mostly extra wires for response handshaking and originator id) and response arbitration/ routing | 05:24 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> And for CPUs like microwatt would perform as well as AXI with much reduced resources footprint | 05:25 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> Isn't there something in Syscon ? | 05:26 |
| openpowerbot | [slack] <mithro> @Benjamin Herrenschmidt Well, LiteX already supports multiple buses for interconnect (axi & wishbone) - it would be great to add something which is better than both that everyone could use | 05:55 |
| openpowerbot | [slack] <Matt Johnston> aah, yep. thanks | 05:59 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> @mithro yup. I'll POC this in microwatt first, then we can look at hooking it up into LiteX. | 06:22 |
| openpowerbot | [slack] <cdrx> @Jeremy Kerr np. I will merge the patch. we should upstream this patchset. | 07:13 |
| openpowerbot | [slack] <cdrx> you deleted https://github.com/CodeConstruct/qemu/tree/pr/irqburgler. | 07:15 |
| openpowerbot | [slack] <joel> I started reworking the microwatt model for submission but got caught up on the images for the test case | 07:16 |
| openpowerbot | [slack] <joel> ...a week later I'd built and booted every microwatt commit. Oops. | 07:16 |
| openpowerbot | [slack] <cdrx> which boot method are you using ? I have a flash image but it requires the sdram_init.bin file. May be there is a better way with uboot now ? -kernel works fine. | 07:42 |
| openpowerbot | [slack] <Jeremy Kerr> yeah, 'cos it got autoclosed by github. | 07:43 |
| openpowerbot | [slack] <joel> This was on hardware. But I was testing qemu using u-boot as the -kernel option | 07:43 |
| openpowerbot | [slack] <cdrx> I could have pulled the branch in. Anyway, it is merged ! | 07:45 |
| openpowerbot | [slack] <cdrx> could we put some images in a GH repo ? | 07:46 |
| openpowerbot | [slack] <Jeremy Kerr> you may be able to delete the autocloser in `.github/workflows/lockdown.yam` , if PRs are easier for you. | 07:46 |
| openpowerbot | [slack] <Jeremy Kerr> or I can push branches up and manually point you to them | 07:47 |
| openpowerbot | [slack] <joel> Yeah. I was just trying to build something from upstream buildroot first. It's a bit hard due to the kernel regressing during the v5.17 release, and it being EoL now so no chance to put the fix in a stable tree. Buildroot uses v5.17 in their latest release | 07:48 |
| openpowerbot | [slack] <joel> They just made a new release though, so I'll rebase on that, build an image, test it and we can upload that somehwere | 07:49 |
| openpowerbot | [slack] <cdrx> I removed the repo locking. So both should work. | 07:52 |
| openpowerbot | [slack] <Jeremy Kerr> in my `dccsm` branch is a litesd model. still need to do a bit of verification (eg card detect), but should be almost ready | 07:53 |
| openpowerbot | [slack] <cdrx> ah you want a complete microwatt_defconfig with rootfs, kernel and uboot. Nice ! but that might be complex indeed. I use a kernel from upstream, the rest are old images from you. | 07:54 |
| openpowerbot | [slack] <cdrx> cool ! | 07:54 |
| openpowerbot | [slack] <Jeremy Kerr> in my `dcscm` branch is a litesd model. still need to do a bit of verification (eg card detect), but should be almost ready | 07:58 |
| openpowerbot | [slack] <Jeremy Kerr> (but if you have any comments in the meantime, please let me know!) | 07:59 |
| openpowerbot | [slack] <cdrx> I should remove the sdhci | 08:02 |
| openpowerbot | [slack] <cdrx> I will add some comments inline if I can | 08:02 |
| openpowerbot | [slack] <Jeremy Kerr> yeah, this patch just replaces the sdhci | 08:05 |
| openpowerbot | [slack] <Jeremy Kerr> (hence the rename, 'cos it's no longer the HCI interface) | 08:06 |
| openpowerbot | [slack] <joel> wow, buildroot made a new release last week and their kernel is v5.17 (!). EoL'd in June. Boo. | 08:15 |
| openpowerbot | [slack] <cdrx> did some comments. mostly cosmetic a part from the DMA. It is nice to add a constraint on the region on which DMAs can be done using a sub address space | 08:16 |
| openpowerbot | [slack] <Jeremy Kerr> yeah, I saw that in one of your other models and just cheated a bit here. Will fix 🙂 | 08:17 |
| openpowerbot | [slack] <Jeremy Kerr> I have replied to the trace comment; is there something generic I can use for the iomem read/write ops? | 08:17 |
| openpowerbot | [slack] <cdrx> yeah. I just rebuild all PPC and Aspeed images | 08:20 |
| openpowerbot | [slack] <cdrx> yeah. it's always the same pattern. May be : | 08:22 |
| openpowerbot | [slack] <cdrx> ```hw/ppc/trace-events:pnv_sbe_xscom_ctrl_read(uint64_t addr, uint64_t val) "addr 0x%" PRIx64 " val 0x%" PRIx64 | 08:22 |
| openpowerbot | [slack] <cdrx> hw/ppc/trace-events:pnv_sbe_xscom_mbox_read(uint64_t addr, uint64_t val) "addr 0x%" PRIx64 " val 0x%" PRIx64``` | 08:22 |
| openpowerbot | [slack] <cdrx> hmm, it is good to have the r/w data also | 08:23 |
| openpowerbot | [slack] <cdrx> you deleted https://github.com/CodeConstruct/qemu/tree/pr/irqburgler. | 08:24 |
| openpowerbot | [slack] <Jeremy Kerr> but there are no "upper-layer" trace events that I should be using instead of reimplementing these in each of the iomem ops? | 08:24 |
| openpowerbot | [slack] <cdrx> bah this should be fine. Add an ID prefix if you need one. | 08:24 |
| openpowerbot | [slack] <cdrx> no | 08:24 |
| openpowerbot | [slack] <Jeremy Kerr> ok | 08:24 |
| openpowerbot | [slack] <cdrx> what is nice to have is unimplemented device region to catch all "buggy" accesses | 08:25 |
| openpowerbot | [slack] <cdrx> I don't know if I did that. | 08:25 |
| openpowerbot | [slack] <cdrx> I did but it is general to the SoC | 08:26 |
| openpowerbot | [slack] <Jeremy Kerr> ok, sounds good | 08:26 |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 09:05 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #microwatt | 09:05 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC | 09:06 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 09:10 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #microwatt | 09:10 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #microwatt | 09:11 | |
| *** pietrushnic <pietrushnic!~pietrushn@2001:470:69fc:105::1:69c> has quit IRC | 09:19 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC | 09:19 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #microwatt | 09:25 | |
| openpowerbot | [slack] <cdrx> well, usually controllers do not need to know when RAM is mapped (internally). so you could mask the top bits of the address when doing the DMA | 09:36 |
| *** pietrushnic <pietrushnic!~pietrushn@2001:470:69fc:105::1:69c> has joined #microwatt | 09:36 | |
| openpowerbot | [slack] <cdrx> or use another property to pass the information. | 09:38 |
| openpowerbot | [slack] <cdrx> what's in LITESD_READER_BASE0 and LITESD_READER_BASE1 ? Simply the phys address ? | 09:38 |
| openpowerbot | [slack] <cdrx> well, usually controllers do not need to know where RAM is mapped (internally). so you could mask the top bits of the address when doing the DMA | 09:38 |
| openpowerbot | [slack] <Jeremy Kerr> Yeah, direct physical address | 09:38 |
| openpowerbot | [slack] <Jeremy Kerr> Maybe we'll get an iommu one day? 😆 | 09:39 |
| openpowerbot | [slack] <cdrx> hey | 09:46 |
| openpowerbot | [slack] <cdrx> mask `0x3ffffffc` should be fine. I think | 09:46 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> Why do you need sdram_init ? You don't have it in BRAM ? | 10:08 |
| openpowerbot | [slack] <cdrx> I forgot, I did that more than a year ago and It might be outdated now. https://github.com/legoater/qemu/commit/56fba4fab7fbcfdfacde6a92f10311bb5779fcff | 10:16 |
| openpowerbot | [slack] <joel> @cdrx emulated the entire boot flow, including running sdram_init. It's nice because you test the elf loader sdram_init, but you could argue that it's not necessary considering qemu can load an elf directly | 10:26 |
| openpowerbot | [slack] <cdrx> It was not difficult to implement either. The closer to the HW the better but having some shortcuts like -kernel is nice for debug. | 10:29 |
| openpowerbot | [slack] <Jeremy Kerr> hm, I think it's more a matter of me not setting up the AddressSpace properly | 11:40 |
| openpowerbot | [slack] <Jeremy Kerr> (I should be able to DMA to the `mw-ram-alias` alias, right? | 11:41 |
| openpowerbot | [slack] <Jeremy Kerr> (I should be able to DMA to the `mw-ram-alias` alias, right?) | 11:41 |
| openpowerbot | [slack] <Jeremy Kerr> nope, it's me not setting up the sdcard backing image properly - code all works fine 😄 | 11:48 |
| openpowerbot | [slack] <cdrx> cool. Could you add a first patch removing all the sdhci stuff since it is unused, so that we can fold it in the patch introducing the SoC. Then a second patch adding the litesd model. And the whole should be then ready to send upstream. | 12:28 |
| openpowerbot | [slack] <Jeremy Kerr> yeah, sure thing. | 12:28 |
| openpowerbot | [slack] <Jeremy Kerr> do you want the interrupt etc definitions removed too? or just the `realize` bits? | 12:29 |
| openpowerbot | [slack] <cdrx> looking | 12:29 |
| openpowerbot | [slack] <Jeremy Kerr> things like these: | 12:30 |
| openpowerbot | [slack] <cdrx> #define LITESD_IRQ_IRQ_CARD_DETECT (1<<0) | 12:30 |
| openpowerbot | [slack] <cdrx> #define LITESD_IRQ_IRQ_SD_TO_MEM_DONE (1<<1) #define LITESD_IRQ_IRQ_MEM_TO_SD_DONE (1<<2) | 12:30 |
| openpowerbot | [slack] <cdrx> #define LITESD_IRQ_IRQ_CMD_DONE (1<<3) | 12:30 |
| openpowerbot | [slack] <Jeremy Kerr> ``` [MW_DEV_SD] = MW_SOC_EXT_IO_BASE + 0x40000,``` | 12:30 |
| openpowerbot | [slack] <cdrx> ah | 12:30 |
| openpowerbot | [slack] <cdrx> I thought you were talking about the IRQ bits | 12:30 |
| openpowerbot | [slack] <Jeremy Kerr> naw, just the sdcard-related definitons in `mw_soc_memmap` and `mw_soc_irqmap` | 12:31 |
| openpowerbot | [slack] <cdrx> I think it is ok to add the device model and its integration in the SoC at once. It is relatively small and no other SoC (yet) is using the model | 12:32 |
| openpowerbot | [slack] <cdrx> and add `Cc: Philippe Mathieu-Daudé <mailto:f4bug@amsat.org` in the header 🙂 | 12:33 |
| openpowerbot | [slack] <cdrx> he is the sd maintainer ! | 12:33 |
| openpowerbot | [slack] <Jeremy Kerr> ok | 12:34 |
| openpowerbot | [slack] <cdrx> Let Joel send 🙂 | 12:34 |
| openpowerbot | [slack] <cdrx> Let @joel send 🙂 | 12:34 |
| openpowerbot | [slack] <cdrx> I think it is ok to add the device model and its integration in the SoC at all once. It is relatively small and no other SoC (yet) is using the model | 12:34 |
| openpowerbot | [slack] <joel> The types confuse me a bit. Did you take a look at that @cdrx? | 12:38 |
| openpowerbot | [slack] <joel> Is there some magic we can do so that IF_SD still works with the controller? | 12:39 |
| openpowerbot | [slack] <joel> Is there some magic we can do so that IF_SD still works with the controller model? | 12:39 |
| openpowerbot | [slack] <Jeremy Kerr> which types? | 12:39 |
| openpowerbot | [slack] <cdrx> SysBusDevice looks fine. | 12:40 |
| openpowerbot | [slack] <joel> The LITESD_BUS, subclassing SD_BUS | 12:41 |
| openpowerbot | [slack] <Jeremy Kerr> the sd-card is on a bus | 12:44 |
| openpowerbot | [slack] <Jeremy Kerr> the host driver just interacts with the bus; the sdbus core handles forwarding commands to bus children | 12:44 |
| openpowerbot | [slack] <Jeremy Kerr> so that means we can "add" a card with `-device sd-card,drive=...` | 12:45 |
| openpowerbot | [slack] <Jeremy Kerr> (I have no idea whether mutliple cards on the one bus is possible; the spec looks like it intended for that, but is pretty sparse on details) | 12:46 |
| openpowerbot | [slack] <joel> Ok, thanks for the explanation. I will take a closer look tomorrow, my first impression was that it looked quite different to the other qemu sdhci models | 12:54 |
| openpowerbot | [slack] <Jeremy Kerr> yeah, they're mostly frontends for the (standard) SDHCI interface; since litesd doesn't expose SDHCI, we're a bit different | 12:55 |
| openpowerbot | [slack] <Jeremy Kerr> ```(qemu) device_add sd-card,drive=sdcard0 | 12:56 |
| openpowerbot | [slack] <Jeremy Kerr> Error: Bus 'sd-bus' does not support hotplugging``` | 12:56 |
| openpowerbot | [slack] <Jeremy Kerr> boo | 12:56 |
| openpowerbot | [slack] <Jeremy Kerr> ok, branch updated | 13:38 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!