gmane.comp.multimedia.milkymist.devel

Re: [Milkymist port] virtual memory management

Yann Sionneau — 2013-06-05T19:40:43

Le 04/06/13 00:23, David Holland a écrit :
I would like to stay in conventional scheme as much as possible, with 
the less modifications possible to the original lm32 core (the one 
without MMU).
So I guess that I will end up doing the usual 1GB/3GB ( is that what is 
done in NetBSD? ) virtual memory layout.
I can easily add a CSR (Control and Status Register) to the LM32 core to 
hold the
physical address of the page table.
This register would not be used at all by the hardware but would only be 
there as a storage register for the software to store and load page 
table phys address.
Writing a new value to the register could even trigger a TLB flush.
I would need at least 2 or 3 instructions to load a TLB entry, which is 
kind of slow but I will try to avoid at least doing bit mask and shifts.
Well, I admit that I jumped into the code to get my hands dirty a little 
bit too early I suppose.
I sent an e-mail to the mailing list when I realized that indeed a lot 
of things were not clear to me regarding the

Re: [Milkymist port] virtual memory management

Yann Sionneau — 2013-06-05T19:35:16

Le 04/06/13 09:39, Martin Husemann a écrit :
Hi,

Indeed the MMU does not have support for Address Space ID (yet ?). I 
will therefore be forced to flush TLB at context switch :/
Support for ASID would be a nice improvement for performances that I 
save for later.
It is not necessary for things to work, and can easily be added later on 
without breaking any software compatibility if I add a bit in a 
configuration register that can be checked at run-time to test if lm32 
MMU supports ASID or not.

Moreover, adding new instructions is not that simple and I would prefer 
using the less possible resources for the MMU and save the very small 
amount of unused opcodes for other projects.

But I will definitely think about adding ASID as a first improvement to 
the MMU when everything will be working with the current design :)

Thanks!

Regards,

Fw: dmx and midi consol

a.pochard — 2013-06-05T12:42:46

Hi 

no solutions?

From: a.pochard 
Sent: Sunday, June 02, 2013 3:57 PM
To: devel-+hD5IHI5XsduxSiqAtu3UkB+6BGkLq7r< at >public.gmane.org 
Subject: dmx and midi consol

Hi,

I connected a MIDI console to the M1 and a projector DMX.

DMX projector works well.

I made the following patch:

midi "nanoKontrol" {
fader1=fader(1, 0);
fader2=fader(1, 1);
fader3=fader(1, 2);
}
dmx1=1.0; //DIMMER
per_frame: 
dmx2=range(fader1); //RED

dmx3=range(fader2); //GREEN

dmx4=range(fader3); //BLUE

When I act on the faders I have no reaction.

do you have a solution?

Regards

Alain aka Alarm

[Devel] test

Sébastien Bourdeauducq — 2013-06-05T10:55:02

migration probably worked if you got this message.

mailing list downtime

Sébastien Bourdeauducq — 2013-06-04T12:26:23

Hi,

due to moving to a different server, the mailing list will be down for a 
while until the migration is completed.

Sebastien

Re: [Milkymist port] virtual memory management

David Holland — 2013-06-03T22:23:18

 >> There are essentially three ways to do this.  Which one you chose depends
 >> on the hardware.

There's also a second issue you're overlooking, which is that you need
a way to access the user address space from the kernel.

 > >1) Turn off the MMU on exception
 >
 > That sounds like the better thing to do from my point of view, I
 > don't see any big downside apart from having to duplicate a few
 > pointers in a few structures to have both virtual and physical
 > addresses of some data structures like PCB, trapframes, page
 > tables.
 > 
 > Is there any big downside I don't see there?
 > If not, I would pick this solution to implement the virtual memory
 > subsystem.

There are two different architectures here: one is to run the entire
kernel with the MMU disabled; the other is to disable the MMU only for
the TLB refill handler. (And maybe for the entry points of other
exceptions too, or maybe not, but that's relatively unimportant.)

 > >2) Keep parts of the address space untranslated
 >
 > I could modi

Re: [Milkymist port] virtual memory management

Eduardo Horvath — 2013-06-03T20:34:37


No prob.
 

Donno.  Depends on your hardware.  I'm aware of some hardware designs 
where caches where you need to have the MMU enabled to use the caches.  If 
your hardware doesn't have any weird quirks like that then turning off the 
MMU may well be a good solution.


Yeah.  Well.  Thing is, some architectures, like MIPS, implicitly assume 
this sort of thing, so thier ports implement things like 
copyin()/copyout() using that feature.


So your MMU doesn't support multiple address space IDs?  That sux.  That 
means you need to blow away the entire MMU each time you switch processes.

If you do have ASIDs, I like to reserve one for the kernel.  That way you 
don't need to share the address space with userland.  

Eduardo

Re: [Milkymist port] virtual memory management

Yann Sionneau — 2013-06-03T20:11:14

Thank you all for your answers :)

Le 30/05/13 22:45, Eduardo Horvath a écrit :
That sounds like the better thing to do from my point of view, I don't 
see any big downside apart from having to duplicate a few pointers in a 
few structures to have both virtual and physical addresses of some data 
structures like PCB, trapframes, page tables.

Is there any big downside I don't see there?
If not, I would pick this solution to implement the virtual memory 
subsystem.
I could modify the MMU to do that, but I would prefer keeping the entire 
4 GB address space for user space :)
That's pretty easy to do for locking exception vectors in ITLB since 
vectors are contiguous in memory.
Locating every data I need to access to from exception vectors in the 
same couple of pages is not so easy I guess.
Moreover, locking a few TLB entries would mean that those virtual 
addresses ( a few pages ) would not be mappable for user space use since 
I could not eject those entries from the TLB.
I would prefer not locking any TLB

dmx and midi consol

a.pochard — 2013-06-02T13:57:30


Hi,

I connected a MIDI console to the M1 and a projector DMX.

DMX projector works well.

I made the following patch:

 
midi "nanoKontrol" {
fader1=fader(1, 0);
fader2=fader(1, 1);
fader3=fader(1, 2);
}
dmx1=1.0; //DIMMER
per_frame: 
dmx2=range(fader1); //RED

dmx3=range(fader2); //GREEN

dmx4=range(fader3); //BLUE


When I act on the faders I have no reaction.

do you have a solution?


Regards

Alain aka Alarm

want to see the M1-based video mixer prototype inBerlin?

Sébastien Bourdeauducq — 2013-05-31T15:48:30

http://www.kunsthalle.com/berlin/program/think-tank-sessions

Add LatticeMico32 ELF support

Yann Sionneau — 2013-05-26T15:48:12

Hello file people,

Could you add the following line in magic/Magdir/elf please?

 >>18    beshort         138             LatticeMico32,

before adding this line:

test.o: ELF 32-bit MSB relocatable, version 1 MathCoPro/FPU/MAU Required 
(SYSV), not stripped

after adding this line:

test.o: ELF 32-bit MSB relocatable, LatticeMico32, version 1 
MathCoPro/FPU/MAU Required (SYSV), not stripped

A quote from binutils (readelf) source code:

MacBook-Pro-de-Yann-Sionneau:dist fallen$ grep -R "EM_LATTICEMICO32" *
bfd/elf32-lm32.c:  elf_elfheader (abfd)->e_machine = EM_LATTICEMICO32;
bfd/elf32-lm32.c:#define ELF_MACHINE_CODE        EM_LATTICEMICO32
binutils/readelf.c:    case EM_LATTICEMICO32:
binutils/readelf.c:     case EM_LATTICEMICO32:
binutils/readelf.c:    case EM_LATTICEMICO32:   return "Lattice Mico32";
binutils/readelf.c:    case EM_LATTICEMICO32:
include/elf/common.h:#define EM_LATTICEMICO32 138       /* RISC 
processor for Lattice FPGA architecture */

Output of readelf command on the same object file:

Re: Mibuild : Support for Xilinx Vivado toolchain

Sébastien Bourdeauducq — 2013-05-20T16:23:49

Could not test, I don't have a 7 series board around yet.

Re: Mibuild : Support for Xilinx Vivado toolchain

Werner Almesberger — 2013-05-20T16:23:19

Did the output actually work ?

- Werner
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist< at >Freenode

Re: Milkymist SoC on Nexys3 board

Sébastien Bourdeauducq — 2013-05-20T16:02:43

Be careful that the BIOS uses that SRAM for the stack and some variables 
already.

Milkymist SoC on Nexys3 board

Yann Sionneau — 2013-05-20T16:03:04

Hello,

A minimalistic version of Milkymist-ng SoC [0] can be run on the Nexys3 
FPGA board [1].
The SoC runs at 100 MHz (on-board oscillator).
The SoC is a very basic cut-down:

- LM32
- Timer
- Uart
- On-chip ROM (32 KB) and SRAM (16 kB) (to hold the BIOS code and allow 
it to run)

The on-board PSRAM (Pseudo Static DRAM, basically DRAM you can use like 
SRAM) and "flash" PCM are not used.
It seems there is no way to program the PCM "flash" under Linux, so the 
basic idea of this mini SoC is to run the BIOS from the on-chip ROM and 
then serialboot the real application (NetBSD kernel for instance) using 
flterm on the PC side.

Of course, in order to even think about running NetBSD kernel on such a 
device, a PSRAM controller is needed to access the 16 MB (which should 
be enough according to Radoslaw Kujawa) of on-board PSRAM.

For now it just runs a basic BIOS, you can access the BIOS prompt using 
the UART.
Next step would be to try to serialboot a small application (small 
enough to fit into the 4 kB S

Re: Mibuild : Support for Xilinx Vivado toolchain

Sébastien Bourdeauducq — 2013-05-19T22:47:09

I tried implementing a LED blinker with one of the first Vivado 
versions, and concluded it was unusable bloatware after it took more 
than 10 minutes to compile it.

Strangely enough, I tried synthesis+P&R of LM32 more recently, and it 
completed just under a minute. I don't have my Vivado install anymore so 
I can't quickly test your design, but will do that when I have some 
spare time.

Sebastien

Mibuild : Support for Xilinx Vivado toolchain

Florent Kermarrec — 2013-05-19T22:33:08

Hi,

in case someone want to test VIVADO with mibuild, here is the vivado
support for mibuild : http://git.io/jaBQVg

design flow is tested with milkymist-ng port on the KC705 but I'm still
trying to understand the results I have:

While it supposed to be "up to 4X faster than alternative solution", 2013.1
version takes 80 minutes to generate the bitstream where ISE takes only 10
minutes...

It's maybe something specific with my configuration or some verilog code
that is not correclty implemented with VIVADO, but I don't have too much
time now to understand what is going on and will probably keep using ISE...

Regards,

Florent

Re: preorders for the first Mixxeo prototypeboards

Sébastien Bourdeauducq — 2013-05-18T20:35:58

Due to the design files taking longer than I had thought, this is 
extended until June 5th.

Check out the Swedish VJ Union article posted today:
http://www.vjunion.se/2013/05/the-mixxeo-hdmidvi-mixer-project/

Sebastien

Re: NetBSD kernel stack

Radoslaw Kujawa — 2013-05-18T15:34:55

Hi all.

On 18 May, 2013, at 15:50 , Yann Sionneau <yann.sionneau-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


Since I'm not an expert on context switches and stack pointers, I've consulted another developer. As I've mentioned before, it would be the best if you posted technical questions to tech-kern< at > list. This way you'll get the answer fastest and from most competent people.


Each LWP (lightweight process) has a context associated with it that includes the stack pointer. 


The kernel has many stack pointers (one per LWP), but when doing context switch we save only the current stack pointer.


ctxsw - context switch


Yes, certainly.


PCB is "process control block", but in NetBSD it's more of an lightweight process control block. It means that there will be one PCB per LWP, _not_ per process.

PCB is defined as MD struct in:
src/sys/arch/*/include/pcb.h

That's becuase Wikipedia's description doesn't seem to take LWPs into account. Quoting the kernel documentation:

"LWP or lightweight process corr

Re: NetBSD port to Milkymist

Yann Sionneau — 2013-05-18T14:07:01

Hi!

Le 18/05/13 00:08, Radoslaw Kujawa a écrit :
Wow, those seem like real power beasts :) I didn't know ARMv7 could have 
64 bits data path to DRAM, nice!
Great! Thank you :)
Ok!
Yes that's where I got it from ;)
No problem at all! Everyone is a noob until he's a guru someday ;)
A bit of buffering should suffice to connect a PSRAM controller directly 
as a wishbone (the internal bus interconnect we use) slave.
Seems like a very nice tool!
Ineed I guess this kind of tool is really necessary when you have a lot 
of "versions" (or ports) of a given software and not so much maintainers 
or time to check it builds for all possible configurations!
Well, it does not sound *that* insane since I don't think we can do 
better for now.
I tried to ask around if anyone would have a Nexys 3 for me to borrow 
but it seems no-one has it.
Moreover I asked a few people if they would have extra Milkymist One 
board to lend you: nobody has extra M1. We unfortunately cannot provide 
you with a M1 :/ (I only have 1)
Qemu could

NetBSD kernel stack

Yann Sionneau — 2013-05-18T13:50:17

Hi Radoslaw and Milkymist fellows,

I have been struggling with the kernel stack pointer for a few days now, 
I could keep digging in the source code even more but since you offered 
you help I wanted to ask you if you would know how the NetBSD kernel (at 
least the ports you know) handle the kernel stack pointer.

To be more clear about what I want to understand, when there is an 
exception (say a page fault) here is what I need to do:

0°) LM32 CPU ensures interrupts are masked and MMU is turned OFF, it 
then gives control to the corresponding exception vector
1°) I need to save the registers somewhere
      a°) I use a trick where I use r0 (which should always be 0) to 
address a static memory region (with MMU off), I can then write in a 
trapframe structure all the registers r0 to r31 and then I'm done with 
saving them and I can do whatever I want without fearing to overwrite a 
value needed to restore context.
      b°) I check if I was in kernel context or user space context
         - If I was in