IRC logs for #openrisc Monday, 2018-01-01

--- Log opened Mon Jan 01 00:00:25 2018
oetwiHi. 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 to14:53
oetwicaching of the corresponding addresses. So i uncommented the parts of the kernel activating the caches and indeed got a running Linux system.14:53
oetwiNow, 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
oetwiThanks 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. It15:58
oetwiis also possible I'm completely wrong with my assumptions. So if any of you have ideas, I would appreciate hearing them.15:59
noogadoes 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 all16:04
noogai tried passing kgdbwait kernel option but it didn't stop and continued to crash16:05
shorne_nooga: I think you need to enable it17:11
shorne_it looks like it depends on HAVE_ARCH_KGDB, which openrisc doesnt have implemented17:13
shorne_patches accepted17:13
shorne_oetwi: which kernel version? which uart driver, I never saw isues with caching there17:15
shorne_you could try a newer mor1kx?17:16
-!- mafm4 is now known as mafm17:46
mafmshorne_: 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 only18:19
mafmis that like a special extension, possible but inefficient, or is just perfectly possible to have it working in 64-bits ?18:20
stekernoetwi_: or1k can only dynamically control addresses to be cacheable/noncacheable when the mmu is enabled.22:39
stekernmor1kx have an option to work around this, you can hardwire the upper address space to be noncacheable by adjusting OPTION_DCACHE_LIMIT_WIDTH22: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 2.15.2 by Marius Gedminas - find it at!