| --- Log opened Tue Sep 08 00:00:34 2015 | ||
| olofk_ | andrzejr: It's a miracle that the ethmac works at all. The CDC in there is completely broken. I've been meaning to fix that since I started co-maintaining it like four years ago | 07:11 |
|---|---|---|
| andrzejr | olofk_, it works because all clocks are synchronous and periods are 1:N so STA takes care of it. That will not be the case at 66MHz. | 07:16 |
| andrzejr | Adding CDC would be the best option but that could affect API (e.g. an extra bit for latching configuration etc) so my first choice was to work it around | 07:17 |
| olofk_ | andrzejr: I think it could be solved by replacing the synchronous FIFO with an async one, and some extra logic | 07:35 |
| olofk_ | Maybe that was what you meant as well? | 07:35 |
| -!- olofk_ is now known as olofk | 07:35 | |
| andrzejr | yes, async fifo would be needed for the data path. The point is, adding CDC to the datapath and all the config registers is a fairly major rework and I don't have a test setup to verify the changes. | 07:38 |
| andrzejr | especially that I still have to add mii to rmii bridge | 07:38 |
| olofk | True | 07:40 |
| olofk | The ethmac testbench is horrible, so that won't help much either | 07:40 |
| olofk | Actually, I've been considering spending some effort on adding WB support to the 10/100/1000 core at opencores instead | 07:40 |
| andrzejr | another question: do we have any SPI interface that (1) supports multi-byte transfers (does not deassert select signal between them), (2) can work with quad SPI flash ROMs? I guess I will have to write it myself, just want to pick the best starting point. | 07:41 |
| olofk | Which is also a bigger change than what you are looking for .) | 07:41 |
| andrzejr | which core? | 07:41 |
| andrzejr | (eth) | 07:41 |
| olofk | I think this one http://opencores.org/project,ethernet_tri_mode | 07:41 |
| olofk | I believe it's fairly well used, but I haven't looked at it in detail | 07:42 |
| olofk | Regarding SPI I don't think we have any quad SPI cores (but that would be great to have) | 07:42 |
| olofk | There are however a few SD cores available and some of them might support 4-bit if that helps | 07:43 |
| olofk | simple_spi doesn't deassert cs IIRC | 07:43 |
| olofk | You set the cs pin manually with a register | 07:43 |
| andrzejr | good, I'll use simple_spi then | 07:44 |
| olofk | simple_spi is also the one with a upstream Linux driver. Right stekern, _franck_ ? | 07:45 |
| andrzejr | do all peripherals of e.g. de0_nano have drivers upstream? | 07:48 |
| olofk | Not sure actually | 07:48 |
| olofk | I can take a look at the dts | 07:48 |
| olofk | Looks like at least spi, i2c and gpio are in the dts, and I'm pretty sure I'm using an unmodified kernel | 07:50 |
| olofk | well, unmodified as in fetched from github/openrisc | 07:51 |
| andrzejr | hmm, I may have to go back to the original 8b gpio | 07:53 |
| andrzejr | what core do we use for sdcard i/f? | 07:54 |
| andrzejr | I remember seeing some discussions about booting from SD card here before | 07:57 |
| olofk | Google wrote one that I haven't tried out for ProjectVault https://github.com/ProjectVault/orp | 08:32 |
| olofk | There's also one that was used on the ORSoC ordb2a boards, but I'm not sure where the code is. They did a code dump in a Virtual Machine that was never fed back upstream | 08:35 |
| olofk | Other people have used pure SPI controllers | 08:35 |
| olofk | IIRC the one in orpsoc-cores is roughly the same as the one on the ordb2a boards | 08:36 |
| --- Log closed Wed Sep 09 00:00:36 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!