On 02/01/2014 04:40 AM, Salman Sheikh wrote:
> By old soc you mean the one that comes with the latticemico32 fpga version?
No, the Verilog Milkymist SoC
https://github.com/m-labs/milkymist
___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.ser
Hi all,
I have made several changes to the Migen simulation API:
1) Proxy object passed to simulation functions
The parameter passed to simulation functions is no longer the Simulator,
but a special object that gives access to the values of the signals of
the current module using the regular Pyth
Yes of course, you need to adapt the SoC design to your board. The
simple SoC, as it is included in MiSoC, only supports the Papilio Pro
(but only requires minor modifications for other boards). I guess it
works with the Papilio Pro now?
Sébastien
___
D
Original Message
Subject: Re: Yosys / EHSM
Date: Wed, 4 Dec 2013 22:01:05 +0100
From: Clifford Wolf
To: S?bastien Bourdeauducq
Hi again,
On Wed, Dec 04, 2013 at 07:28:58PM +0100, Clifford Wolf wrote:
> > https://github.com/m-labs/lm32/blob/master/rtl/lm32_dcache.v#L308
> >
Hi,
On 11/29/2013 10:32 PM, Victor Lyuboslavsky wrote:
> That seems to be working. Signals seem to be getting mapped to input
> ports. What about output ports -- does the convert method automatically
> figure out what is input and output?
Yes, if you assign to IO signals via comb/sync statements
On 11/29/2013 07:45 AM, Robert Jördens wrote:
>> Do you know how to make the "Python module index" section more useful,
>> or disable it completely?
>
> Yes. patch 3 does that. I am also attaching some more tweaks to the
> docs and a set of docstrings for fhdl.structure. The later one
> probably n
Hi,
On 11/29/2013 09:19 PM, Victor Lyuboslavsky wrote:
> Thank you for the response. I plan to make Migen available for
> simulation on EDA Playground (using Icarus Verilog) on Sunday or Monday.
Great! :)
> print(verilog.convert(top, ios={name for name in dir(top) if name[0] !=
> "_" and
> isins
On 11/29/2013 08:30 PM, Adrian Byszuk wrote:
> Both HDMI and DVI.
Did HDMI DDC fail on all boards (i.e. no mode shown in xrandr)? What is
the configuration of the computer you used to test (graphics card,
driver, operating system)? Have you tried with another computer? Can you
post logic analyzer
Hi,
just a quick note to let you know that Creotech will start testing the
remaining Mixxeo boards this week.
Sebastien
___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel
Hi,
quick update on the Mixxeo boards - tested the DVI (both analog and
digital) output and it works. Ethernet also seems OK. The issues on the
HDMI that I mentioned before were due to gateware problems and confusion
from the weird behaviour of the NVIDIA driver/X-Windows.
The only hardware issue
Hi,
this is slightly old news if you are following IRC, but I've picked up
the first two Mixxeo prototype boards last week from Creotech. There are
8 more that were almost fully assembled (only through-hole components
were missing) and are coming soon.
Here is a picture:
https://pbs.twimg.com/med
Any comments on that?
Originalnachricht
Betreff: NOR FLASH
Datum: 2013-08-23 21:59
Absender: Grzegorz Kasprowicz
Empfänger: Sébastien Bourdeauducq
HI Sebastien
There are troubles with buing of JS28F256J3F105 FLASH
Do you think we can install S29GL256S10TFI010 [1] or
JS28F256
Hi,
On Mon, 22 Apr 2013 10:03:09 -0300, Werner Almesberger wrote:
Ah, thanks ! In top.v, I see that this generates two synchronous
assignments, i.e., a double flip-flop. When I search for MultiReg,
I see things that mention Xilinx-specific shift register magic
(what on earth (?) is "shift regist
Committed, thanks! Also added double-registering of the inputs with
migen.genlib.cdc.MultiReg to prevent metastability - I missed this
problem yesterday.
On Thu, 18 Apr 2013 13:33:25 -0300, Werner Almesberger wrote:
This is a revised version of the counter-based ADC.
http://www.ubercomp.com/jslm32/src/
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
Hi,
On Thu, 18 Apr 2013 03:35:29 -0300, Werner Almesberger wrote:
from milkymist import m1crg, lm32, norflash, uart, s6ddrphy, dfii,
asmicon, \
identifier, timer, minimac3, framebuffer, asmiprobe, dvisampler
+from milkymist.adc import CounterADC
Use the same import style as the line j
On Thu, 18 Apr 2013 13:21:51 -0300, Werner Almesberger wrote:
Also, shouldn't
self._polarity be a 1-bit CSR instead (and remove the [0])?
Interesting that this didn't trip up anything :-)
Operations between signals of different bit widths are valid.
Otherwise, even "x.eq(x + 1)" would be pro
Hi Werner, and thanks for this core!
On Thu, 18 Apr 2013 03:35:28 -0300, Werner Almesberger wrote:
+class CounterADC(Module, AutoCSR):
+ def __init__(self, charge, sense, width = 24):
+ if not hasattr(sense, "__iter__"):
A better way is to use isinstance(sense, collections.
On Wed, 3 Apr 2013 09:26:46 -0300, Werner Almesberger wrote:
sebastien.bourdeaud...@lekernel.net wrote:
this is old news if you follow IRC or Twitter, but it appears
possible to crank up the framebuffer resolution to "full HD"
1920x1080 32bpp on M1 using milkymist-ng:
Even if it's old news, it
Hi,
this is old news if you follow IRC or Twitter, but it appears possible
to crank up the framebuffer resolution to "full HD" 1920x1080 32bpp on
M1 using milkymist-ng:
https://pbs.twimg.com/media/BGhInDvCQAAXfI8.jpg:large
(The software drawing the bars and circles is the Antigrain Geometry
L
FYI, I'm speaking about Migen on Jan 30 10:00am Cape Town time.
Sebastien
-- Forwarded Message --
Subject: Signal Processing Workshop - University of Cape Town
Date: Tuesday, January 22, 2013, 04:06:53 PM
From: SDRG UCT
To: undisclosed-recipients:
Hi everyone,
The start of
Hi,
thanks for the patch!
> -parameter IO_SEL_EXT = 2'd0;
> -parameter IO_SEL_STACK = 2'd1;
> -parameter IO_SEL_SREG= 2'd2;
> +localparam IO_SEL_EXT= 2'd0;
> +localparam IO_SEL_STACK = 2'd1;
> +localparam IO_SEL_SREG = 2'd2;
Applied.
> case(Rd)
>
> -
Any idea...?
[ 46%] Building LM32GenIntrinsics.inc...
0 llvm-tblgen0x083a432e
1 llvm-tblgen0x083a3f88
2 0x4001e400 __kernel_sigreturn + 0
3 libstdc++.so.6 0x4010e074 std::string::length() const + 4
4 llvm-tblgen0x081dd9a4
5 llvm-tblgen0x082e44c9
6 llvm-tblgen
On Sunday, January 06, 2013 06:49:46 AM Troy Benjegerdes wrote:
> I think I got most of this, but I appear to have gone the wrong
> direction with the multiple phases. I thought I could remove the
> 'p1' signals, but this seems broken.
Since you are still multiplying the SDRAM clock for commands b
On Sunday, January 06, 2013 07:16:30 AM Troy Benjegerdes wrote:
> well, what if the board router could move pins
> on the fpga around to minimize distance?
Migen only focuses on technology-independent logic design (and things like UCF
file generation are handled externally), but you can do this s
On Saturday, January 05, 2013 11:06:00 PM Troy Benjegerdes wrote:
> Second problem: I changed milkymist-ng/soc.xst to -p xc6slx25-ftg256-2,
> and 'make' does not seem to know what to cleanup and rebuild. (make
> clean is the workaround, but can't we have the makefile know to do that?)
yes, it's a
The EHSM team proudly present... highlights from the schedule of the
Exceptionally Hard and Soft Meeting! [Berlin Dec 28-30 http://ehsm.eu]
Day#1 10:45 - 13:00
Keynote Speech: Will Jack - "I built myself a nuclear fusion reactor when I
was 16"
Will Jack is a 17 year old high school student from
On Tuesday, November 27, 2012 12:03:49 AM William Heatley wrote:
> reading a signal is meant to affect simulation behavior.
Adding the signal to the automatic (*) sensitivity list is an expected side
effect of the read, and the problem actually originates from "bar" being in the
sensitivity list
Hi,
Consider the following Verilog source:
module event_test();
reg foo, bar;
always @(*) begin
$display("bar=%d", bar);
bar <= 1'b0;
if(foo)
bar <= 1'b1;
end
initial begin
foo <= 1'd1;
#1 $display("End of simulation - bar=%d
On Thursday, October 18, 2012 09:20:55 PM Troy Benjegerdes wrote:
> What would be the downsides to this approach?
This is code for an old FPGA, S6 has I/Os that can drive DVI directly.
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC:
http://milkymist.org/3/migen_fpgaworld.pdf
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
Hi,
On Wednesday, July 25, 2012 12:05:03 AM Florent Kermarrec wrote:
> Can you give me more information of where you want to go with your
> Milkymist-ng and
> on which functionalities you want someone to help you / spend time fist?
As a first step similar to what you have done, I think USB suppor
Hi,
Thank you for your contribution. I had a look at your code and I found several
problems:
The Verilog parsing (both in embedded and vimport) is messy and probably buggy
as well. What about using a proper parser, e.g.
http://code.google.com/p/pyvparser/ ?
I'm afraid you misunderstood the wh
On Wednesday, July 25, 2012 03:49:15 AM Cristian Paul Peñaranda Rojas wrote:
> Could this core be separately generated to be later re-used in other
> wishbone-like buses including our legacy one and in other projects
> perhaps too?
This core is also faster because it supports transaction reorderin
Hi,
On Tuesday, July 24, 2012 10:39:34 PM Florent Kermarrec wrote:
> Just to let you know, I've started a Migen "port" of your Millymist Soc.
Huh that's already one of the things that milkymist-ng is about (plus
having new architecture features, such as a much faster DRAM controller).
I woul
-- Forwarded Message --
Subject: FYI: talk about our KiCad workflow at FISL 13
Date: Friday, July 20, 2012, 04:05:13 AM
From: Werner Almesberger
To: discuss...@lists.en.qi-hardware.com
Next week, I'll be at FISL 13 [1] in Porto Alegre and give a talk
entitled "Making Hardware
On Wednesday, May 09, 2012 06:32:14 AM Jon Phillips wrote:
> Today someone else mentioned something to me...why not take the
> essence of the milkymist and have that as a software app, and iPad
> app, an android app, web app, and so on?
Such accidents highlight the importance of having highly dist
On Sunday, May 06, 2012 06:27:49 PM Jon Phillips wrote:
> Will there be night events with milkymist too?
Maybe.
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
CALL FOR FUNDING AND PARTICIPATION
Exceptionally Hard & Soft Meeting
exploring the frontiers of open source and DIY
Berlin, December 28-30 2012
http://ehsm.eu
@ehsmeeting
Some electronics books from the 50s claimed making triode tubes would be
an imposs
On Thursday, May 03, 2012 08:36:46 PM Paul wrote:
> It might be an Ethernet problem but it still means that the unit will not
> update, is there a list that shows compatible routers, or a workaround to
> help the poor wee beastie see version information rather than freezing?
Does it freeze all the
Hi,
I had a look at the current MMU design. Looks like a good start so far. Some
problems by decreasing importance:
+wire [9:0] dtlb_write_tag;
+wire [9:0] dtlb_read_tag;
===> "Tag" should be renamed "valid" (or something similar), made 1-bit wide
and merged into the "data" memory.
+// CSR Wr
On Thursday, May 03, 2012 09:10:53 AM Paul wrote:
> packets transmitted 9
> received 0
Ah, so it's not an 'update' problem, but an ethernet problem. Are you using
DHCP or did you enter that address manually?
___
http://lists.milkymist.org/listinfo.cgi
On Thursday, May 03, 2012 09:03:36 AM Paul wrote:
> I have tried about 10 times, not sure about reproducible problem
Hmm, weird, haven't seen something like that. Can you ping the M1 from another
computer, or access the FTP?
___
http://lists.milkymist.o
On Thursday, May 03, 2012 08:57:07 AM Paul wrote:
> It is connected to the net, it can see the IP address, Netmask and DNS
Ok. How many times have you tried? Is it a reproducible problem?
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IR
Hi,
What version are you running right now? Is the M1 correctly connected to the
internet? Do you see a correct IP address in the network settings?
S.
On Thursday, May 03, 2012 08:40:47 AM Paul wrote:
> Hi there
>
>
>
> I have turned the M1 on for the first time and tried to do the update as
On Wednesday, May 02, 2012 06:15:44 PM Jon Phillips wrote:
> Oh, I know I'm a record repeating here, but I can't wait to use linux
> on my milkymist! What is the latest on openwrt + milkymist?
Nothing much:
https://github.com/milkymist/openwrt-milkymist
https://github.com/milkymist/linux-milkymist
On Wednesday, May 02, 2012 06:41:23 AM Cristian Paul Peñaranda Rojas wrote:
> For me, and this kind of devices, using a cheap wireless router like 703n
> and OSC seems an interesting option to try.
Yes, that should work. Xiangfu has done a similar thing with TouchOSC:
http://vimeo.com/22401379
Se
Hi,
thanks for your report.
On Mon, 23 Apr 2012 02:22:28 +0200, David Kuehling wrote:
Some issues I stumbled over:
* web upgrade refused to work (previous firmware was 1.1 AFAIR).
although newer firmware 1.2 version was detected, pressing "update
from
web" displayed "error downloading bit
-- Forwarded Message --
Subject: Re: Fwd: [Milkymist-devel] USB good, RTEMS bad (was Re: [RFC PATCH
0/3] increase navre clock to 72 MHz)
Date: Tuesday, April 17, 2012, 03:56:40 AM
From: Sebastian Huber
To: Sebastien Bourdeauducq
Hello,
the general file system layer checks
On Saturday, January 28, 2012 05:37:31 PM Werner Almesberger wrote:
> 1) Rotate in the schematics (and the documentation). Leave the
>layout as it is.
+1
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
On Friday, December 30, 2011 04:12:19 PM Werner Almesberger wrote:
> I cowardly stayed away from anything that would need libm :)
libm works correctly with the current development environment.
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.o
On Friday, December 30, 2011 07:39:52 AM George M. Gallant, Jr. wrote:
> 1. Is there a list of known problems?
No. There are no known problems with Navre, except that a few things from AVR
are not implemented (but this is not a problem for our application).
> 2. Is this the latest?
The latest v
Hi,
On Thursday, December 29, 2011 12:19:43 PM Péteut, Alain (SPACE) wrote:
> I trying to code a VHDL backend for migen, it's still considered broken for
> now. Anyway if you'd like to have a look at it:
> https://github.com/peteut/migen/blob/vhdl/migen/fhdl/vhdl.py
A few comments:
* I would pre
On Thursday, December 29, 2011 02:13:57 PM Werner Almesberger wrote:
> Our parser already allows omitting the per_frame= (provided
> there's one somewhere earlier)
How will this "per-frame" omission be done?
I would prefer to have special statements (that do not appear in MilkDrop),
such as:
[in
On Thursday, December 29, 2011 03:37:59 AM JP Bonn wrote:
> BRD: Running on unknown board (ID=0x), startup aborted.
The system ID register, from which this value is taken, moved from 0xe000103c
to 0xe000107c in commit b9605012ac9554645386e192db5f6cc4b67aefe1 (22
Nov 2011)
Maybe this cha
Hi,
On Thursday, December 29, 2011 02:58:03 PM Péteut, Alain (SPACE) wrote:
> Using variables instead of signals prevent insertion of delta time (which
> might boost simulation quite a lot).
Yes, but you have to be careful. Look at this (contrived) example:
process(s_x)
variable tmp: std_logic;
All applied, thanks! I saw you included Xiangfu's fix...
I have given you commit access to FN and SoC repositories on Github - you're
writing a large number of excellent quality patches, so the previous process
merely generated a lot of list traffic and slowed things down...
Cheers,
Sebastien
O
On Thursday, December 29, 2011 08:19:27 AM Adam Wang wrote:
> a total yield ratio
> 88pcs / 90pcs. (97.8%) is came out
Wow, cool! Congratulations and thanks for your patience!
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymis
On Tue, 27 Dec 2011 10:19:27 +0800, Xiangfu Liu wrote:
I rebase those patches to the last yaffs2 upstream. I have test
yaffs2 after rebase
works fine under Milkymist One. if you think the rebase is ok. I will
do a 'git push -f'
update our git repo.
Don't force-push (if I understand correctly, w
Alain,
On Tue, 27 Dec 2011 02:24:30 +, Péteut wrote:
I'm currently writing a vhdl backend for migen
Note that the Verilog backend itself is still in a rather early stage.
Its most serious problem, which I plan to address soon, is that putting
all combinatorial statements into one always
Hi,
On Sun, 20 Nov 2011 06:07:44 -0300, Werner Almesberger wrote:
So it does indeed seem that the sample clock is running a bit
fast for some reason.
Try sampling 1/4 bit time later?
diff --git a/cores/softusb/rtl/softusb_rx.v
b/cores/softusb/rtl/softusb_rx.v
index 25e1f67..96b6af9 100644
-
On Sat, 19 Nov 2011 15:50:06 -0300, Werner Almesberger wrote:
- marginal bit clock recovery in the SoC
As discussed on IRC, glitches can easily wreck the current clock
recovery system. I'll try adding a deglitching circuit on the input
signal path in the FPGA.
S.
___
On Wed, 12 Oct 2011 15:53:26 -0300, Werner Almesberger wrote:
I'll try next to add a 4.7 kOhm pull-up to FLASH_WE_N/WE# (write
enable) and see if this has any effect on NOR corruption. If it
doesn't, then I'll also add a pull-up to FLASH_CE_N/CE0 (chip
enable).
Nice writeup, and thanks! I'm eag
On Wed, 12 Oct 2011 07:30:21 -0300, Werner Almesberger wrote:
That way, it would be an item one can afford to try "risky" things
on.
FPGA and CPLD algoritms are quite different.
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #mi
On Mon, 10 Oct 2011 17:35:59 -0700, Piotr Esden-Tempski wrote:
Great talk. I was able to at least read the slides yesterday. Today I
get 404 did you move it somewhere else?
Some dreamhost bugs... (dreamhoststatus.com)
They're mirrored on the OHWR page:
http://www.ohwr.org/projects/ohr-meta/wiki
On Fri, 7 Oct 2011 17:10:05 +0800, Jon Phillips wrote:
Could you go through that list and mark through what has been
completed or move it somewhere? I thought for a moment those were new
features then realized the dates are old
All the listed FN 1.1 items are new features, most are missing
On Fri, 7 Oct 2011 12:14:51 +0800, j...@rejon.org wrote:
I'm curious, what are the next features for m1?
See here:
http://www.milkymist.org/wiki/index.php?title=Flickernoise_roadmap
http://www.milkymist.org/wiki/index.php?title=SoC_Roadmap
S.
___
htt
Hi,
We have the occasion to hold a Milkymist workshop at the next edition
of the open source/art festival Piksel (www.piksel.no). I probably won't
attend, and we'd also need to sort out the availability of devices for
use at the workshop. I'm wondering if someone here with some M1
experience
On Thu, 06 Oct 2011 11:00:04 +0200, sebastien.bourdeaud...@lekernel.net
wrote:
I think the FPGA should already have those internally (the same
pull-ups that make the LEDs go dimly lit when the FPGA is
unconfigured). But maybe there are glitches or something?
ug380 seems to say there are:
"FOE_
On Wed, 5 Oct 2011 09:55:14 -0300, Werner Almesberger wrote:
Uwe Bonnes wrote:
In the schematic (page 7 of rc3_schematic.pdf), I don't see a
pull-up on
the JS28F256 CE0 pin and neither on we_n. Shoudn't these pullup help
too?
This sounds like a very good idea to me. Also Xilinx have 4.7 kOhm
Merged, thanks!
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
On Sun, 02 Oct 2011 22:25:09 +0200, sebastien.bourdeaud...@lekernel.net
wrote:
On Sun, 2 Oct 2011 14:50:03 -0300, Werner Almesberger wrote:
The allocations are: 256036 bytes for struct sched_ctx and 2592
bytes for the struct vm_reg array. Does the compiler run in the
"GUI" task, which has about
On Sun, 2 Oct 2011 14:50:03 -0300, Werner Almesberger wrote:
The allocations are: 256036 bytes for struct sched_ctx and 2592
bytes for the struct vm_reg array. Does the compiler run in the
"GUI" task, which has about 1 MB of stack, or somewhere else ?
FN spawns a background compilation task wit
On Tue, 2011-08-30 at 01:05 +0800, Folkert Saathoff wrote:
> seems to work much better now, and also there's a bunch more patches,
> good stuff! :)
Good to hear! If you still have stability issues (e.g. crashes or video
input disappearing), it would help to short L19 and L3 (i.e. make them 0
ohm)
Check out the packing instructions (with pictures) of our upcoming
Milkymist One batch:
http://en.qi-hardware.com/wiki/Milkymist_One_accessories#packing_instructions
Excellent work from Wolfgang and Yi :)
___
http://lists.milkymist.org/listinfo.cgi/deve
On Sun, 2011-08-28 at 04:26 +0800, Folkert Saathoff wrote:
> i cloned the latest urjtag sources from sourceforge
Does that mean git or release?
The cable support isn't in any release yet, so you must use git. I don't
know why the UrJTAG project makes their releases so infrequent. So many
problems.
On Sun, 2011-08-28 at 04:26 +0800, Folkert Saathoff wrote:
> however, the board is not very stable. four out of five times it boots
> straight into a random noise pattern.
Hmm, are you sure you are pressing only the _middle_ pushbutton when
booting?
>
> so i figured that i should flash the firm
Merged, thanks!
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
On Mon, 2011-08-22 at 22:37 +0800, Xiangfu Liu wrote:
> sound great. we will have S-Video(then I don't need VGA-->S-video converter,
> and Chinese :)
I was talking about the input.
> checking for ftrylockfile... no
> checking whether CLOCK_PROCESS_CPUTIME_ID is declared... no
> configure: error:
Hi,
here are some ideas for the next major software version.
New renderer features
* Support selection S-Video and Component sources in the GUI.
* Add a variable to switch between CVBS video sources (if possible).
* Improve patch compiler register allocation, so we can use more
variables in the p
On Tue, 2011-08-16 at 23:51 +0100, Michael Walle wrote:
> What do you think about an small on chip bootrom which initializes the sdram
> core, looks for a magic word and either boots an image from nor or falls back
> to serial boot loader.
SDRAM can be difficult to get to work at times, and the
On Tue, 2011-08-16 at 06:31 -0500, Cristian Paul Peñaranda Rojas wrote:
> > If the BIOS cannot boot at all, there will be a problem since software
> > is supposed to initialize SDRAM. So you won't have memory to load any
> > software - though you might try abusing the softusb on-chip SRAM :)
>
> W
On Tue, 2011-08-16 at 12:24 +0800, Xiangfu Liu wrote:
> if there a way to load soc bitstream and test software without touch NOR
> flash?
> for now we can load soc bitstream with 'pld' can we load test software direct
> to memory
> by jtag?
If the BIOS cannot boot at all, there will be a problem
On Sun, 2011-08-14 at 20:04 +0200, Michael Walle wrote:
> This won't change the interrupts to level triggered one instead it
> leave them as edge triggered but unifies them into one, pulsed
> interrupt.
Combining several event sources on the same pulsed interrupt line cannot
work reliably because
> I also submitted a new port [1] : lm32-rtems-gcc
Can you add the extra multilibs?
http://www.milkymist.org/wiki/index.php?title=Flickernoise_build_instructions#RTEMS_and_toolchain
It's still not in RTEMS... I have recently committed it to gcc 4.5.3
though.
_
Wolfgang,
Having the whole flash memory-mapped and unprotected is not as 'crazy'
as you may think. Not all write cycles to the flash area end up in the
data being modified, and in fact, the flash even requires every data
write to be confirmed with a special word written in a second cycle. In
theor
On Fri, 2011-08-12 at 08:51 +0800, Xiangfu Liu wrote:
> > Michael Walle mentioned on #milkymist that reading the NOR via gdb
> > (using the serial port of the USB-JTAG board) would be much faster
> > than with JTAG. And in addition, gdb protects the data with its own
> > checksum, which may help.
>
On Fri, 2011-08-12 at 09:28 +0800, Xiangfu Liu wrote:
> ERROR:Bitgen:38 - Unknown command line option "INIT_9K". Please consult the
>Command Line Tools User Guide for the appropriate command-line options.
> ERROR:Bitgen:157 - Bitgen will terminate because of the above errors.
Update to ISE 13
On Thu, 2011-08-11 at 09:09 +, Wolfgang Spraul wrote:
> One problem that I see emerging more now is that some boards fail
> after X full power to rendering cycles. So the board renders fine (30
> seconds each time), and it can power cycle, but after a number of
> power cycles it suddenly falls
See here http://comments.gmane.org/gmane.comp.lib.newlib/6676 and make
sure you are using the latest RTEMS toolchain version. I'm not sure if
the automatic build scripts have the latest patches and version of
newlib (and I think they don't).
Btw there is no need for pastebin when posting to the ma
On Mon, 2011-08-08 at 15:49 -0700, JP wrote:
> - .bss : AT (ADDR (.bss))
> + .bss : AT (ADDR (.text) + SIZEOF (.text) + SIZEOF (.data))
I don't think this is correct. With the AVR architecture, there are
separate memories for code and data. Even though e.g. the .text and .bss
sections may b
On Tue, 2011-08-09 at 11:59 +0800, Xiangfu Liu wrote:
> for now I only know the picture not working. I saw the milkydrop can
> load picture(*.tga). m1 not
That's a projectM extension (afaik). I'll probably add that to FN 1.1
(with PNG pictures), as everyone is asking about that :) Plus it's not a
On Mon, 2011-08-08 at 23:37 -0700, August wrote:
> Is this just a opacity difference on the video.
Yes, the operation performed is:
destination pixel = destination pixel + video_a*video in pixel
(with saturation when going out of range).
Btw, there is also the Flickernoise handbook:
https://githu
On Mon, 2011-08-01 at 19:51 -0700, August wrote:
> Ok so with the 3 video ports red green and blue is it possible to hook up
> different sources of video into each or are 2 of them for video? And how can
> I turn them on and off in the patches?
This is not supported by the software yet.
_
I'm done sending the patches. We now have those outstanding RTEMS PRs:
https://www.rtems.org/bugzilla/show_bug.cgi?id=1868
https://www.rtems.org/bugzilla/show_bug.cgi?id=1869
https://www.rtems.org/bugzilla/show_bug.cgi?id=1841
https://www.rtems.org/bugzilla/show_bug.cgi?id=1721
Flickernoise works
On Sat, 2011-07-30 at 18:23 -0700, August wrote:
> I read somewhere that you could load .jpg files on there. Is that true? If so
> could you also load .mov files? Does that mean you could mix into the patches
> your own media that you create?
This is currently not possible but can be a future fe
On Sat, 2011-07-30 at 11:22 -0700, August wrote:
> I was successful! thank you, I had a friend with a Linux computer help
> me. They flashed it with the jtag cable.that got us to version .4 then
> updated via eithernet.
Cool! Future updates should be much easier, since you just have to
connect you
On Wed, 2011-07-27 at 23:47 -0700, August wrote:
> I was trying to turn on the video in and the window popped up and says
> Feature not implemented. What can I do to fix this.?
Update to the latest software, this will make the camera work as well as
fixing many bugs.
http://lekernel.net/blog/2010
Hi,
Thanks to Lars and Michael's great work, there is now a usable OpenWrt
port to the Milkymist One.
The repository is here:
https://github.com/milkymist/openwrt-milkymist
Issues you might run into:
* https://dev.openwrt.org/ticket/9235
* deselect "Ramdisk" and select "Ext4" in the images confi
On Wed, 2011-07-27 at 22:34 +0800, Xiangfu Liu wrote:
> On 07/15/2011 11:35 PM, Sebastien Bourdeauducq wrote:
> >> Maybe you can instead modify the test program so it CRC's all flash
> >> partitions and displays the result for the operator to check?
> >>
>
1 - 100 of 321 matches
Mail list logo
