| --- Log opened Fri Aug 22 00:00:18 2014 | ||
| stekern | the spinlock saga continues, one sw bug hunted down. I held a lock without disabling interrupts in a function that can be re-entered from an interrupt... | 03:33 |
|---|---|---|
| stekern | now I get a triple lock on run-queues though... | 03:34 |
| dalias | :) | 03:37 |
| sb0 | stekern, do you see any reason why mor1kx would fail to execute code starting at 0x60000, but succeed when it's starting at 0x160000? | 06:51 |
| sb0 | (it's a bootloader) | 06:51 |
| stekern | sb0: no, can't say I see why that would happen | 06:54 |
| sb0 | well, it's probably the spi flash acting up then | 06:54 |
| maxpaln | Just doing some background reading on the orpsocv3 page on opencores.org - I can see the section that lists support for various tools (simulators, synthesis etc.) I guess the 'No' against support for, say, Synplify is because the tools haven't yet got built-in support for that tool rather than it has been found to not work. | 10:14 |
| maxpaln | My initial plan is to generate the RTL using the fusesoc tool and import it into our tool suite to generate the RTL. I will also aim to run some simulations through the Aldec simulator, Riviera - I am expecting both of these to be manual jobs that will, ultimately, work (after some coersion) - does anyone have any experience that I should be aware of here? | 10:16 |
| maxpaln | hmmm, meant to say "import it into our tool suite to generate the bitstream". | 10:19 |
| maxpaln | Ultimately my aim would be to repeat this process but for one of our evaluation boards and then publish the updates along with support for Synplify, Riviera and our tool flow. This is probably something that will take me deep into autumn I think. | 10:20 |
| stekern | maxpaln: yes, it's rather 'no-one has tried' than 'someone tried and failed' | 11:00 |
| stekern | but I think you're about to step into a possible deficiency in the fusesoc flow, I'm not sure if the 'generate RTL step' is decoupled enough that you can do that seperately from the backend. | 11:01 |
| stekern | olofk? | 11:01 |
| maxpaln | well, that leads onto my next question - while digging around the existing board 'systems' I can see a selection of RTL. I wondered how much of this is created by the fusesoc utility and how much needs to be generated by me. Or put another way, what should I be creating and what should I let the tools 'manage'? | 12:28 |
| stekern | basically, you need to create 'orpsoc_top.v' and 'clkgen.v' | 12:30 |
| maxpaln | ok - that makes sense | 12:31 |
| maxpaln | I'm sure I'll have plenty of questions along the way - I presume there isn't a document describing how to add a new board... | 12:34 |
| stekern | not really, but since you already have an orpsocv2 board port, it should be pretty straightforward to port it | 12:35 |
| maxpaln | yeah, that is what I figure. I'm aiming to keep everything as fusesoc-friendly as possible so when it comes to shifting to the 'to be published' system based on our eval board I can reuse as much as possible. | 12:36 |
| maxpaln | Getting something working won't be too difficult - getting the format in-keeping with the expectations of the fusesoc system might be more challenging :-) | 12:37 |
| stekern | =P | 12:45 |
| stekern | It'll be nice to have some lattice representation in the board port department | 12:46 |
| maxpaln | agreed - | 12:46 |
| stekern | do lattice have any 'cheap-dev-board' partners, like terasic for altera and digilent for xilinx? | 12:47 |
| stekern | (and do you have some published info about the eval board you're speaking about?) | 12:48 |
| maxpaln | Well, we aim generally aim to produce a low-cost eval board in-house - for our ECP3 family (the predecessor to the ECP5 and the device that I started working on around a year ago!!!) we have our Versa board - it is here: | 12:48 |
| maxpaln | http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/LatticeECP3VersaDevelopmentKit.aspx | 12:48 |
| maxpaln | We have a range of 3rd party partners that also provide boards - but we tend to be less organised than Xilinx and Altera on this sort of thing (we are a much smaller company in terms of $ sales so getting resources for that sort of activity is very difficult) | 12:50 |
| maxpaln | The first board I'll be targetting will be this one: | 12:51 |
| maxpaln | http://www.latticesemi.com/Products/DevelopmentBoardsAndKits/ECP5PCIExpressDevKit.aspx | 12:51 |
| maxpaln | (mainly because its the only one available for the ECP5!) | 12:51 |
| stekern | I understand | 12:51 |
| maxpaln | At $199 its pretty low cost - I won't be using the PCIe but there are some other useful things on there. | 12:52 |
| stekern | which is $199? the ECP5 or ECP3 board? | 12:52 |
| ysionneau | the ECP5 is $199 | 12:53 |
| maxpaln | Yes | 12:53 |
| maxpaln | Just checking the Versa board - it's not far off the same price I think | 12:53 |
| stekern | that's not bad at all | 12:53 |
| maxpaln | Ah, The ECP3 versa board is $262.50 from our online store - who comes up with these prices! | 12:54 |
| maxpaln | Yeah, I think the ECP5 board is good - we are getting much better at producing the low cost boards, it's become Lattice's ethos recently, low cost, low power, low footprint. :-) | 12:55 |
| maxpaln | Maybe I'll be tempted to write a PCIe peripheral for the ORPSOC :-) | 12:55 |
| stekern | that'd be cool ;) | 12:56 |
| stekern | now I got tempted to order one of those boards... | 12:56 |
| maxpaln | :-) | 12:56 |
| stekern | I got the devil on one of my shoulders telling me to, and the wife (well not literally) screaming on the other one =P | 12:57 |
| maxpaln | lol! Now there is an image!! | 12:58 |
| poke53281 | dalias: I tried to compile the newest directfb. There is only one musl-related error: | 16:27 |
| poke53281 | http://git.directfb.org/?p=core/DirectFB.git;a=blob;f=lib/direct/os/linux/glibc/mutex.h | 16:27 |
| poke53281 | PTHREAD_MUTEX_INITIALIZER and PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP cannot be found | 16:28 |
| poke53281 | is this Ok? Is there a quick workaround? | 16:28 |
| poke53281 | Sorry, only the last one cannot be found | 16:35 |
| poke53281 | I am tempted to use just "0" here. | 16:36 |
| poke53281 | stekern: The newest directfb version seems to be vararg-problem free. Maybe someone has read my email :) | 16:40 |
| dalias | poke53281, there's no easy workaround | 16:54 |
| dalias | musl intentionally does not expose the layout of the mutex structure with the intent that it be allowed to change if needed | 16:55 |
| dalias | so there's no way to make a preinitialized recursive mutex that wouldn't be subject to the risk of changes | 16:55 |
| dalias | the correct way to initialize a recursive mutex is with pthread_once | 16:55 |
| dalias | before calling pthread_mutex_lock on it, call pthread_once with a once-init-function that does the pthread_mutex_init to make a recursive mutex | 16:56 |
| poke53281 | Thanks. | 17:30 |
| dalias | i asked on #musl if anyone has dealt with this yet and has a patch already | 17:32 |
| dalias | nobody's around right now tho | 17:32 |
| poke53281 | read it. | 17:33 |
| dalias | ah you're there too :) | 17:33 |
| dalias | didn't notice | 17:33 |
| poke53281 | If the guy who programmed sabotage compiles the newest directfb he will notice it too. | 17:33 |
| dalias | i remember at least a couple other packages having a similar issue, and i think we had no trouble getting the pthread_once fix upstream | 17:33 |
| poke53281 | Unfortunately I cannot take the old version. | 17:33 |
| dalias | *nod* | 17:34 |
| poke53281 | Is the guy of sabotage linux also in the chat? | 17:37 |
| dalias | yes. sh4rm4. | 17:38 |
| --- Log closed Sat Aug 23 00:00:19 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!