| --- Log opened Mon Jan 01 00:00:25 2018 | ||
| oetwi | Hi. I've put an instance of mor1kx (v4.1) on an FPGA (SmartFusion2). I then proceeded to compile the kernel (after creating a matching .dts) and trying to boot that. In my first tries, i didn't get anything on the serial connection but found that the systems endlessly loops in a 'putc' function, but without generating requests to actually access the UART peripheral. Guessing that this might be due to | 14:53 |
|---|---|---|
| oetwi | caching of the corresponding addresses. So i uncommented the parts of the kernel activating the caches and indeed got a running Linux system. | 14:53 |
| oetwi | Now, running linux on a softcore in an FPGA is cool. Running it with its caches enabled however, woule be even better. Does anyone have some pointers as to where i can find out how to disable caching for the UART peripheral? | 14:54 |
| _franck_ | oetwi: maybe not related but when caches are enabled, the CPU core generates memory burst access. So your memory controller might have a problem with bursts and looping in putc might be a random symptom. | 15:45 |
| oetwi | Thanks for the input! But i assume that burst accesses as such work - for instance, i ran dhrystone with caches enabled and got the expected results. My guess is that Linux does not mark the UARTs memory area as uncacheable. That would result in the putc-loop always reading the UART as busy and never actually sending a character. If that is the case, i would need to know how to correct that behaviour. It | 15:58 |
| oetwi | is also possible I'm completely wrong with my assumptions. So if any of you have ideas, I would appreciate hearing them. | 15:59 |
| nooga | does the openrisc linux kernel come with kgdb enabled? I'm looking at menuconfig and see that Kernel hacking -> Kernel debugging is -*- and I cannot enter there at all | 16:04 |
| nooga | i tried passing kgdbwait kernel option but it didn't stop and continued to crash | 16:05 |
| shorne_ | nooga: I think you need to enable it | 17:11 |
| shorne_ | it looks like it depends on HAVE_ARCH_KGDB, which openrisc doesnt have implemented | 17:13 |
| shorne_ | patches accepted | 17:13 |
| shorne_ | oetwi: which kernel version? which uart driver, I never saw isues with caching there | 17:15 |
| shorne_ | you could try a newer mor1kx? | 17:16 |
| -!- mafm4 is now known as mafm | 17:46 | |
| mafm | shorne_: btw, I think that it was you in a talk in Japan recently that mentioned that or1k had 64-bit mode... I thought that it was 32-bit only | 18:19 |
| mafm | is that like a special extension, possible but inefficient, or is just perfectly possible to have it working in 64-bits ? | 18:20 |
| stekern | oetwi_: or1k can only dynamically control addresses to be cacheable/noncacheable when the mmu is enabled. | 22:39 |
| stekern | mor1kx have an option to work around this, you can hardwire the upper address space to be noncacheable by adjusting OPTION_DCACHE_LIMIT_WIDTH | 22:40 |
| stekern | (we should fix the linux kernel to setup some mmu mapping that marks the uart as non-cacheable before the first early prints) | 22:42 |
| --- Log closed Tue Jan 02 00:00:26 2018 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!