headers
a.pochard | 5 Jun 2013 14:42
Picon
Favicon

Fw: dmx and midi consol

Hi
 
no solutions?
 
 
From: a.pochard
Sent: Sunday, June 02, 2013 3:57 PM
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
<div>
<div dir="ltr">
<div>
<div>Hi </div>
<div>&nbsp;</div>
<div><span lang="en" class="short_text"><span class="hps">no 
solutions</span><span>?</span></span></div>
<div>
<span lang="en" class="short_text"><span></span></span>&nbsp;</div>
<div>
<div>
<div>&nbsp;</div>
<div>
<div>From: <a title="a.pochard@..." href="mailto:a.pochard@...">a.pochard</a> </div>
<div>Sent: Sunday, June 02, 2013 3:57 PM</div>
<div>To: <a title="devel@..." href="mailto:devel@...">devel@...</a> </div>
<div>Subject: dmx and midi consol</div>
</div>
</div>
<div>&nbsp;</div>
</div>
<div>
<div dir="ltr">
<div>
<div>&nbsp;</div>
<div>
<div>
<div>&nbsp;</div>
<div></div>
<div>
<div>Hi,</div>
</div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div>&nbsp;</div>
<div><span lang="en"><span class="hps">I 
connected</span> <span class="hps">a MIDI</span> <span class="hps">console to 
the</span> <span class="hps">M1</span> <span class="hps">and a</span> <span class="hps">projector</span> <span class="hps">DMX</span><span>.</span><br><br><span class="hps">DMX</span> <span class="hps">projector works 
well</span><span>.</span><br><br><span class="hps">I made the</span> <span class="hps">following patch</span><span>:</span></span></div>
<div><span lang="en"><span></span><br>&nbsp;</span></div>
<div>midi "nanoKontrol" {</div>
<div>fader1=fader(1, 0);</div>
<div>fader2=fader(1, 1);</div>
<div>fader3=fader(1, 2);</div>
<div>}</div>
<div>dmx1=1.0; //DIMMER</div>
<div>per_frame: </div>
<div>dmx2=range(fader1); //RED</div>
<div>&nbsp;</div>
<div>dmx3=range(fader2); //GREEN</div>
<div>&nbsp;</div>
<div>dmx4=range(fader3); //BLUE</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><span lang="en"><span class="hps">When</span> <span class="hps">I act</span> <span class="hps">on the 
faders</span> <span class="hps">I have no</span> <span class="hps">reaction.</span></span></div>
<div>
<span lang="en"><span class="hps"></span></span>&nbsp;</div>
<div><span lang="en"><span lang="en"><span class="hps">do you have a</span> <span class="hps">solution</span><span>?</span></span></span></div>
<div>
<br><br><span class="hps">Regards</span>
</div>
<div>&nbsp;</div>
<div>Alain aka 
Alarm</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
Permalink | Reply | 0 comments |
headers
Sébastien Bourdeauducq | 5 Jun 2013 12:55
Gravatar

[Devel] test

migration probably worked if you got this message.
Permalink | Reply | 0 comments |
headers
Sébastien Bourdeauducq | 4 Jun 2013 14:26
Gravatar

mailing list downtime

Hi,

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

Sebastien
Permalink | Reply | 0 comments |
headers
a.pochard | 2 Jun 2013 15:57
Picon
Favicon

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
<div>
<div dir="ltr">
<div>
<div>&nbsp;</div>
<div>
<div>
<div>&nbsp;</div>
<div></div>
<div>
<div>Hi,</div>
</div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div>&nbsp;</div>
<div><span lang="en"><span class="hps">I 
connected</span> <span class="hps">a MIDI</span> <span class="hps">console to 
the</span> <span class="hps">M1</span> <span class="hps">and a</span> <span class="hps">projector</span> <span class="hps">DMX</span><span>.</span><br><br><span class="hps">DMX</span> <span class="hps">projector works 
well</span><span>.</span><br><br><span class="hps">I made the</span> <span class="hps">following patch</span><span>:</span></span></div>
<div><span lang="en"><span></span><br>&nbsp;</span></div>
<div>midi "nanoKontrol" {</div>
<div>fader1=fader(1, 0);</div>
<div>fader2=fader(1, 1);</div>
<div>fader3=fader(1, 2);</div>
<div>}</div>
<div>dmx1=1.0; //DIMMER</div>
<div>per_frame: </div>
<div>dmx2=range(fader1); //RED</div>
<div>&nbsp;</div>
<div>dmx3=range(fader2); //GREEN</div>
<div>&nbsp;</div>
<div>dmx4=range(fader3); //BLUE</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><span lang="en"><span class="hps">When</span> <span class="hps">I act</span> <span class="hps">on the 
faders</span> <span class="hps">I have no</span> <span class="hps">reaction.</span></span></div>
<div>
<span lang="en"><span class="hps"></span></span>&nbsp;</div>
<div><span lang="en"><span lang="en"><span class="hps">do you have a</span> <span class="hps">solution</span><span>?</span></span></span></div>
<div>
<br><br><span class="hps">Regards</span>
</div>
<div>&nbsp;</div>
<div>Alain aka 
Alarm</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
Permalink | Reply | 0 comments |
headers
Sébastien Bourdeauducq | 31 May 2013 17:48
Gravatar

want to see the M1-based video mixer prototype in Berlin?

http://www.kunsthalle.com/berlin/program/think-tank-sessions
Permalink | Reply | 0 comments |
headers
Yann Sionneau | 26 May 2013 17:48
Picon

Add LatticeMico32 ELF support

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:

MacBook-Pro-de-Yann-Sionneau:~ fallen$ ~/dev/NetBSD/obj/tooldir.Darwin-10.8.0-i386/bin/lm32--netbsd-readelf -a test.o | grep Machine
  Machine:                           Lattice Mico32

hexdump of the test.o file:

MacBook-Pro-de-Yann-Sionneau:~ fallen$ hexdump -C test.o | head -n2
00000000  7f 45 4c 46 01 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  00 01 00 8a 00 00 00 01  00 00 00 00 00 00 00 00  |................|

Thank you very much :)

PS: please add me in CC when replying to this e-mail as I'm not subscribed to the file mailing-list.

Best regards,

--
Yann Sionneau
<div>
    Hello file people, <br><br>
    Could you add the following line in magic/Magdir/elf please?<br><br>
    &gt;&gt;18&nbsp;&nbsp;&nbsp; beshort&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 138&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LatticeMico32, <br><br>
    before adding this line:<br><br>
    test.o: ELF 32-bit MSB relocatable, version 1 MathCoPro/FPU/MAU
    Required (SYSV), not stripped<br><br>
    after adding this line:<br><br>
    test.o: ELF 32-bit MSB relocatable, LatticeMico32, version 1
    MathCoPro/FPU/MAU Required (SYSV), not stripped<br><br>
    A quote from binutils (readelf) source code:<br><br>
    MacBook-Pro-de-Yann-Sionneau:dist fallen$ grep -R "EM_LATTICEMICO32"
    *<br>
    bfd/elf32-lm32.c:&nbsp; elf_elfheader (abfd)-&gt;e_machine =
    EM_LATTICEMICO32;<br>
    bfd/elf32-lm32.c:#define ELF_MACHINE_CODE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EM_LATTICEMICO32<br>
    binutils/readelf.c:&nbsp;&nbsp;&nbsp; case EM_LATTICEMICO32:<br>
    binutils/readelf.c:&nbsp;&nbsp;&nbsp;&nbsp; case EM_LATTICEMICO32:<br>
    binutils/readelf.c:&nbsp;&nbsp;&nbsp; case EM_LATTICEMICO32:&nbsp;&nbsp; return "Lattice
    Mico32";<br>
    binutils/readelf.c:&nbsp;&nbsp;&nbsp; case EM_LATTICEMICO32:<br>
    include/elf/common.h:#define EM_LATTICEMICO32 138&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* RISC
    processor for Lattice FPGA architecture */<br><br>
    Output of readelf command on the same object file:<br><br>
    MacBook-Pro-de-Yann-Sionneau:~ fallen$
    ~/dev/NetBSD/obj/tooldir.Darwin-10.8.0-i386/bin/lm32--netbsd-readelf
    -a test.o | grep Machine<br>
    &nbsp; Machine:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lattice Mico32<br><br>
    hexdump of the test.o file:<br><br>
    MacBook-Pro-de-Yann-Sionneau:~ fallen$ hexdump -C test.o | head -n2<br>
    00000000&nbsp; 7f 45 4c 46 01 02 01 00&nbsp; 00 00 00 00 00 00 00 00&nbsp;
    |.ELF............|<br>
    00000010&nbsp; 00 01 00 8a 00 00 00
    01&nbsp; 00 00 00 00 00 00 00 00&nbsp; |................|<br><br>
    Thank you very much :)<br><br>
    PS: please add me in CC when replying to this e-mail as I'm not
    subscribed to the file mailing-list.<br><br>
    Best regards, <br><br>
    -- <br>
    Yann Sionneau<br>
</div>
Permalink | Reply | 0 comments |
headers
Yann Sionneau | 20 May 2013 18:03
Picon

Milkymist SoC on Nexys3 board

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 SRAM).
And then next step is to write the PSRAM controller :)

Happy hacking with your Nexys3 boards!

Cheers,

[0] -- https://github.com/fallen/nexys3-milkymist-ng
[1] -- http://www.digilentinc.com/Products/Detail.cfm?Prod=NEXYS3

--

-- 
Yann Sionneau
Permalink | Reply | 1 comment |
headers
Florent Kermarrec | 20 May 2013 00:33
Picon

Mibuild : Support for Xilinx Vivado toolchain

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
<div>
<div>Hi,</div>
<div><br></div>
<div>in case someone want to test VIVADO with mibuild, here is the vivado support for mibuild :&nbsp;<a href="http://git.io/jaBQVg">http://git.io/jaBQVg</a>
</div>
<div><br></div>
<div>design flow is tested with milkymist-ng port on the KC705 but I'm still trying to understand the results I have:</div>

<div><br></div>
<div>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...</div>
<div><br></div>
<div>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...</div>

<div><br></div>
<div>Regards,</div>
<div><br></div>
<div>Florent</div>
</div>
Permalink | Reply | 3 comments |
headers
Yann Sionneau | 18 May 2013 16:07
Picon

Re: NetBSD port to Milkymist

Hi!

Le 18/05/13 00:08, Radoslaw Kujawa a écrit :
> Hi!
>
> On 17 May, 2013, at 20:48 , Yann Sionneau <yann.sionneau@...> wrote:
>
>> Le 17/05/13 14:20, Radoslaw Kujawa a écrit :
>>> I know next to nothing about Milkymist and LM32
>> The beauty of open source hardware is that you can easily read documentation and source code :-)
> I've googled a bit and found a lot of documentation related to LM32 and Milkymist. It's much better than I expected.
>
>>> , but as NetBSD developer I can help you integrating the port into our source tree (once the port is ready).
>> Thank you very much, I appreciate a lot your offer to help me, I must say that porting NetBSD is fun but is a
very time consuming task.
> Indeed, I know something about this too. I have to admit that I never did any NetBSD port from scratch, but I
wrote various low level components and drivers. You can check the list on my wiki page:
> http://wiki.netbsd.org/users/rkujawa/
>
> Now I am working on integrating NetBSD port to Marvell's Armada XP SoCs into our source tree.
Wow, those seem like real power beasts :) I didn't know ARMv7 could have 
64 bits data path to DRAM, nice!
>
>> Most of the time I end up having a look at all other ports to see how they handle such or such
feature/case/API to get ideas and to adapt to the particularities of LM32.
>> A bit of help from someone knowing NetBSD internals (MD and MI parts) can be a tremendous booster for this work!
> I think sending mail to tech-kern <at>  list was the right thing to do. In case of any questions related to NetBSD
internals do the same again! Naturally, some developers are more knowledgeable about some parts of the
kernel than others. So asking by asking the list instead of me directly you will get more complete,
in-depth answers. I'll monitor tech-kern <at>  for any discussions related to Milkymist.
Great! Thank you :)
>
>>> To ease the integration process, please use the latest development version of NetBSD (HEAD branch)
instead of 6.x for your development work.
>> I think I used the "netbsd-6" CVS branch when I first imported NetBSD code in my GitHub repository.
>> I will try to merge the HEAD.
> Please do it, as in the NetBSD project we only import new code to HEAD branch. So any code written now for 6.x
will have to be merged to HEAD in the future anyway.
Ok!
>
>> If I understand correctly the documentation, to checkout the "HEAD" of NetBSD code I need to do this:
>> $
>> cvs checkout -A -P src
>>
>> right ?
> Basically yes. But the whole procedure is a bit more complicated, you need to set up appropriate
environment variables. It is explained in the NetBSD Guide Chapter 30.
>
> http://www.netbsd.org/docs/guide/en/chap-fetch.html
Yes that's where I got it from ;)
>
>> Basically, today, the Milkymist One board port is the one fully supported with the full Milkymist SoC
feature set (CPU, DDR SDRAM memory controller, NAND Flash controller, ADV analog video input, USB host
core, PFPU, TMU for texture mapping and so on)
> Milkymist One is a really cool hardware, but I don't have spare $500 :/.
>
> I bought Nexys 3 few months ago to start learning about digital systems, VHDL etc. And I choose this board
after some research because it contains quite modern FPGA chip and lots of peripherals, while the price
was very affordable (only $120).
>
> I'm still a noob when it comes to FPGAs, so please forgive me if some of my questions are trivial.
No problem at all! Everyone is a noob until he's a guru someday ;)
>
>> However, there are other ports of the Milkymist SoC with usually much less features (usually just the
CPU, a bunch of timers, uart, on-chip SRAM controler or DDR SDRAM controller and no other peripherals).
> Having working CPU, RAM, timers and UART would be a good start.
>
>> To answer your question more precisely, your board features a Spartan-6 which is good news since the
official SoC runs on Spartan-6.
>> However, DRAM memory is needed to run any code using the SoC. The DRAM chips used on your board differs from
what's on the Milkymist One board.
>>
>> Your board uses a 16 MB PSRAM (Pseudo Static DRAM) Micron chip which the Milkymist(-ng or not) SoC does not
support (as of today).
>> Moreover the datapath between the FPGA and the PSRAM is 16 bits length whereas Milkymist One board uses 64
bits datapath to DDR333 DDR SDRAM chips.
> PSRAM can be driven just like any common SRAM. But changing data path to 16 bits sounds problematic.
A bit of buffering should suffice to connect a PSRAM controller directly 
as a wishbone (the internal bus interconnect we use) slave.
>
>> All of this means that it's non trivial to modify the Milkymist-(ng or not) SoC in order to make it run on the
Nexys 3 board because it would need deep changes in the DDR SDRAM memory controller.
>>
>> However, Qemu does support the lm32 CPU and the Milkymist SoC (thanks to Michael Walle work).
>> Qemu should also support the LM32 MMU, I would need to ask Michael about the state of qemu support for the
lm32 mmu :)
> It's great that Milkymist is emulated by qemu - it will help with automated testing. I think that once
Milkymist port is integrated into NetBSD, the next step would be adding support to Anita (which is based on
qemu).  It's an excellent tool that allows continuous integration testing. See
http://www.gson.org/netbsd/anita/ .
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!
>
> With a project as large as NetBSD, it's very difficult for us developers to track which system parts are
broken and on which ports. Anita tries to solve this problem by doing automated installation of the NetBSD
in qemu, then running a set of ATF tests in a fresh system. Tests results are stored on the servers. This way
we can easily see what is broken and since when.
>
>> One thing I could do is I could try to port a simplified version (timer, uart, CPU, basic PSRAM controller,
NAND controller) Milkymist SoC to your Nexys 3 board so that you can debug using it. But I don't have this
FPGA board and it's hard to do any serious FPGA development without the actual hardware to debug…
> Thank you for you offer to port it, but I understand how hard is it to work on some hardware if you don't have
it. I once wrote a driver for a hardware that I didn't have. Another person was testing it for me. I've
managed to complete it somehow, but it was very painful.
>
> I wonder if it would be possible to do it with remote access. I could setup Mini ITX machine with Linux,
install Digilent JTAG tools there and connect the board. If I gave you access to this machine, at least in
theory you would be able to work on this. How insane does that sound? ;)
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 be a nice solution though!

I would basically need a remote access with the ability to program a 
given bitstream to the FPGA of your board, and then I would need to have 
remote access to the serial port of the FPGA board to see if the BIOS 
runs and spits out it's prompt.

I would need to be able to program the parallel non-volatile PCM Flash 
as well in order to put the BIOS in there.

Is all of this possible from SSH command line? I don't know your board 
nor the tools provided by Digilentinc for this one.
So far I've used only one Digilentinc board which needed a Windows-only 
tool to program it.

So maybe a remote access to a Windows PC is what I need? I know one good 
software to do that: http://www.teamviewer.com/en/
>
> I'd try to do it myself, if only I had some time to take on another project. But now dayjob, NetBSD hacking and
freshly born son take 200% of my time. Before he was born I thought that I have no free time. Now as I have even
less, I think that I just managed it badly.
I think I totally understand what you mean (even if I don't have any 
baby ;)), time is very precious! It's always hard to find time to do 
anything...
>
>> Do you think 16 MB of RAM is enough to boot the latest NetBSD kernel up to a uart shell?
> 16MB is an absolute minimum these days. But it's perfectly possible to run stripped-down kernel and
single user shell on a machine with 16MB RAM (I've tested this on an Amiga 1200 few weeks ago).
OK, good!
>
>> If you want to discuss live we can either discuss on #NetBSD (my nickname is Fallenou) or on #milkymist
(which is the official Milkymist project IRC channel) on Freenode as well :)
> Sometimes I'm visiting #netbsd on freenode under nickname rkujawa. But where possible I prefer e-mail
communication, as I can manage my time better this way.
Understood! It's fine with me!
>
>> PS: Can I forward your e-mail and my answer to the Milkymist development mailing list?
> Please do :).
>
Done :)

See ya!
Permalink | Reply | 0 comments |
headers
Yann Sionneau | 18 May 2013 15:50
Picon

NetBSD kernel stack

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 kernel context, I can keep %sp (stack pointer 
register) and use it for the few calls to service the exception
         - If I was in userland context, I need to modify %sp to point 
to some kernel stack somewhere in order to have a valid stack to do some 
work in the exception handler before going back to user mode.

the "userland" case bothers me, I wonder where usually NetBSD saves its 
kernel stack pointer (and where the kernel stack is).

Is there one kernel stack per userland thread/process?
Is there one big global kernel stack?

Here is a sum up of what I've found so far digging in the source code:

A few ports have a "kernel stack pointer" member in the struct pcb 
(sys/arch/≤arch_name>/include/pcb.h):

hppa:
pcb->pcb_ksp /*  kernel sp for ctxsw */ <== what's ctxsw ? context 
something?

i386:
pcb->pcb_esp /* kernel stack pointer */

mips:
pcb->pcb_context /* kernel context for resume */

ia64:
pcb->psb_special.sp

amd64:
pcb->pcb_rsp

m68k:
pcb->pcb_regs[12];   /* D2-D7, A2-A7 */ (stack pointer being A7 (i.e. 
pcb_regs[11]) IIUC)

powerpc:
pcb->pcb_sp  /* saved SP */

sh3:
pcb->pcb_sf (the switchframe does not seem to contain the stack pointer)
 From the comment in sys/arch/sh3/include/locore.h it seems SH3 arch 
stores the kernel stack pointer in a dedicated register:
/* BANK1 r7 contains bottom address of lwp's kernel stack. */

sparc:
pcb->pcb_sp /*  sp (%o6) when switch() was called */

sparc64:
pcb->pcb_sp /*  sp (%o6) when switch() was called */

vax:
pcb->KSP  /*  Kernel Stack Pointer      */

So it seems the PCB could be the right place to save the kernel stack 
pointer, do you agree with that?
What's the PCB btw? Wikipedia gives me that link 
http://en.wikipedia.org/wiki/Process_control_block but the description 
of wikipedia seems to match with the struct lwp from NetBSD source code.
Struct lwp seems to contain all information about a thread/process 
(correct?)

PCB seems to be pointed to by the lwp->l_addr (  void *l_addr;        /* 
l: PCB address; use lwp_getpcb() */ )

Another question, do you know what is the uvm_lwp_getuarea() ?

vaddr_t
uvm_lwp_getuarea(lwp_t *l)
{

         return (vaddr_t)l->l_addr - UAREA_PCB_OFFSET;
}

it seems to point to a data area containing the PCB ... is it the kernel 
stack of the process? something else?

Sorry for the very (too) long e-mail ^^

Thank you for your help and for your time which I understand is very 
limited :)

See ya!

--

-- 
Yann Sionneau
aka Fallenou on Freenode
Permalink | Reply | 1 comment |
headers
Yann Sionneau | 18 May 2013 14:56
Picon

Qemu + MMU

Hi,

What's the status of Qemu support of the LM32 MMU?
Is it in sync with what's commited in milkymist/lm32 GitHub repository?

Cheers :)

--

-- 
Yann Sionneau
Permalink | Reply | 0 comments |

Gmane