Re: NetBSD port to Milkymist
Le 18/05/13 00:08, Radoslaw Kujawa a écrit :
> 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:
> 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.
>> 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.
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
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
>> 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).
>> 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 :).