gmane.comp.multimedia.milkymist.devel

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 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

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 correspond to a process, or a thread of a process which runs in the kernel. For nonthreaded programs, there is exactly one LWP corresponding to the process, for threaded there can be more of them."

You could say that PCB is an MD part of LWP structure.


Single userland process consists of one or more LWPs. 


Yep, as I said there will be one PCB per LWP.


This function is used to get the addess of uarea for given LWP.

UAREA_PCB_OFFSET is an offset of PCB structure in the uarea (usually this offset equals 0, since PCB is first in uarea).


Uarea is a space where information about process data important for the kernel are stored (like PCB). 

Where uarea is exactly located depends on:
src/sys/arch/arm/include/*/param.h

Hope that helps :).

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 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 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...
OK, good!
Understood! It's fine with me!
Done :)

See ya!

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 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!

Qemu + MMU

Yann Sionneau — 2013-05-18T12:56:23

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 :)

Fwd: Re: NetBSD port to Milkymist

Yann Sionneau — 2013-05-18T12:27:21

FYI the discussion about a possible Nexys 3 port of Milkymist SoC.

Does anyone have a Nexys 3 board that he could lend me for a few months?

I can pay for both way shipping costs via bank transfer payment :)

Cheers !

-------- Message original --------
Sujet: Re: NetBSD port to Milkymist
Date : Sat, 18 May 2013 00:08:54 +0200
De : Radoslaw Kujawa <radoslaw.kujawa-9hU5SXCXPvqsTnJN9+BGXg< at >public.gmane.org>
Pour : Yann Sionneau <yann.sionneau-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

Hi!

On 17 May, 2013, at 20:48 , Yann Sionneau <yann.sionneau-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

I've googled a bit and found a lot of documentation related to LM32 and Milkymist. It's much better than I expected.

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.

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.

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.

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

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.

Having working CPU, RAM, timers and UART would be a good start.

PSRAM can be driven just like any common SRAM. But changing data path to 16 bits sounds problematic.

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

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.

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? ;)

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.

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).

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.

Please do :).

Fwd: NetBSD port to Milkymist

Yann Sionneau — 2013-05-18T12:25:12

FYI


-------- Message original --------
Sujet: NetBSD port to Milkymist
Date : Fri, 17 May 2013 14:20:05 +0200
De : Radoslaw Kujawa <radoslaw.kujawa-9hU5SXCXPvqsTnJN9+BGXg< at >public.gmane.org>
Pour : yann.sionneau-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org



Hello.

Great job with porting NetBSD to the Milkymist and LM32!

I know next to nothing about Milkymist and LM32, but as NetBSD developer I can help you integrating the port into our source tree (once the port is ready). To ease the integration process, please use the latest development version of NetBSD (HEAD branch) instead of 6.x for your development work.

Also, I wonder how difficult it would be to run LM32 core on my Digilent Nexys 3 board? Having some hardware that can actually run it would make testing much easier for me ;).

Re: A new NetBSD port is coming (WIP)!

Yann Sionneau — 2013-05-17T18:32:11

Le 17/05/13 13:09, Greg Troxel a écrit :
Hey, thanks :)

I forgot to mention my nickname on IRC is 'Fallenou' sometimes with an 
'_' at the end.
You can talk to me on #NetBSD or on #milkymist which is the official IRC 
channel of the Milkymist project.

Regards,

Yann Sionneau
aka Fallenou

A new NetBSD port is coming (WIP)!

Yann Sionneau — 2013-05-17T09:54:27

Hello NetBSD guys,

First, sorry for cross-list posting, I didn't really know where this 
e-mail belong to.

Here is a small notice to let you know that I am in the process of 
adding support for the LatticeMico32 CPU [0] and the Milkymist SoC [1] 
to NetBSD 6 kernel.

LatticeMico32 (LM32) is an Open Source softcore (CPU which runs as 
gateware inside a FPGA) developed by Lattice Semiconductor.
LM32 can be used on several FPGA models from several FPGA vendors 
(Xilinx (Virtex 4, Spartan 3, Spartan 6 etc) Lattice, Altera (DE0 board) 
and maybe more).
Originally this CPU did not have any kind of MMU. Last year I developed 
an MMU for LM32 with the help of the Milkymist community (and a lot of 
help from Michael Walle in particular).

The LM32 softcore CPU is used in the Open Source Hardware Milkymist SoC 
which is the main component of the Milkymist One board [2].

For now, the Milkymist SoC/board runs an embedded OS (RTEMS) and is able 
to run ucLinux (no-mmu) as well.

The first goal of my work is to make NetBSD kernel (and userland) run on 
the Milkymist One board (thus on the Milkymist SoC with the modified 
MMU-enabled LM32 cpu).

The second goal - which explains why I am contacting you instead of 
working off-the-record on my own - is to integrate my port (when 
finished and fully working) upstream in the NetBSD source tree :)

So I guess I need to say hello and open my code to comments and reviews 
in order to do things in a proper and clean way that will allow the 
integration upstream in the future.

For now I just wanted to break the silence and to at least make you 
aware of my ongoing work :)

See you around, I may ask a few questions from time to time when I feel 
lost about some NetBSD internal stuff if you don't mind ;)
Don't hesitate to ask me about what I'm doing/how I'm going it and what 
the hardware is capable of.

FYI:

- LM32 (with MMU) source code: https://github.com/milkymist/lm32/
- Milkymist SoC source code: https://github.com/milkymist/milkymist/
- My NetBSD 6 port work (in progress): https://github.com/fallen/NetBSD/

Cheers !

[0] -- http://en.wikipedia.org/wiki/LatticeMico32
[1] -- http://en.wikipedia.org/wiki/Milkymist#Milkymist_SoC
[2] -- http://milkymist.org/3/mmone.html

Re: Patch to fix a simple stale test bench

Sébastien Bourdeauducq — 2013-05-15T10:52:45

Cool, thanks for proposing. Will think of that!


Resizing with bilinear filtering is definitely possible on a Slowtan-6 
FPGA (the legacy SoC TMU already does that). Full pixel shader with 
arbitrary bilinear sampling I'll have to think of it.

Good performance is difficult, especially as you are supposed to output 
more than one pixel per system clock cycle if you want a decent 
resolution. Remember that each output pixel requires accessing 8 input 
pixels just for mixing 2 sources with bilinear filtering, so the memory 
system becomes very challenging especially with the ludicrous routing 
delays of my favorite FPGA.


The current code handles that already. It's even tested (60/72/75 -> 
60Hz) and works :)

Sebastien

Re: Patch to fix a simple stale test bench

2013-05-15T10:45:27


I've wanted dynamic generation of EDID for a while. Failed to find any code outside of proprietary applications. Coding it myself from the VESA spec document has always been put-off with other things more important.

If you have / find / want to code the dynamic generation of EDIDs, thats something I could concretely collaborate around.


Which was part of my question: is the M1 hardware capable and/or could the pixel shader approach be implemented now in limited form as a base for future such goodness as billinear filtering etc.

Note: differing frame rates are also going to require temporal sampling or other such sophistication.

Re: Patch to fix a simple stale test bench

Sébastien Bourdeauducq — 2013-05-15T10:27:57

Yes, using EDID first to force some resolution at the inputs. The FPGA 
can control the hotplug detect pins of the input ports. So it would work 
as follows:
1) the Mixxeo inputs ports appear completely disconnected to the two sources
2) the Mixxeo output is connected, the M1 reads the EDID and sets a 
screen resolution
3) the Mixxeo rewrites the EDID of the inputs to make the two sources 
have the same resolution as the output
4) the Mixxeo enables the hotplug detect of the inputs and the sources 
detect the new connections, read the EDID, and start generating video

It is much simpler than good resizing with bilinear filtering, which 
could come later with a firmware upgrade.

M3 platform is also for later. Mixxeo is still based on the M1 design.

Sebastien

Re: Patch to fix a simple stale test bench

2013-05-15T10:08:22


Hmmm.

The arbitrary sampling is there for 
- basics: resizing inputs, handling mismatched aspect ratios
- advanced: display wall controller, soft edge blending, warping for projection mapping
- crazy: art, ie. as d-fuse we do a lot of 2D cut-up and manipulation of sources live with a load of openGL patches I've written.

And I'll be upfront that my interest is in what could be done with the M^3 platform and a software definable pipeline between multiple inputs and outputs.

Which leads to the questions - is the present M1 implementation limited to 1:1 pixel mapping between inputs and output, and is there an alternative route you were intending to implement that doesn't have the pixel shader with sampler approach?

Re: Patch to fix a simple stale test bench

Sébastien Bourdeauducq — 2013-05-14T22:24:45

Hmm, that might work with a pipeline like this:

"PFPU" generating addresses -> memory controller -> "PFPU" processing 
the data -> video DAC

plus a compiler that splits the code into address generation and 
processing parts. Memory addresses that depend on memory content cannot 
work with an architecture like that, but it should not be a problem for 
many graphics processing algos :)

(Of course, "memory controller" is an oversimplification, we'll need 
multi-ported prefetch caches and what not in order to obtain halfway 
decent performance from the Slowtan-6. This paper describes an 
interesting solution: 
https://graphics.stanford.edu/papers/texture_prefetch/)

Sebastien

Re: Patch to fix a simple stale test bench

2013-05-14T19:34:30

The ideal is an bare bones equivalent of an OpenGL pixel shader, ie.

- A function is executed for every output pixel.
- This function has a sampler available to bring in arbitrary pixels from sources
- This function can do some basic RGB maths

(and, props for getting this far!)

Toby

tbz::spk // mobile mail

On 14 May 2013, at 17:47, Sébastien Bourdeauducq <sebastien.bourdeauducq< at >lekernel.net> wrote:

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