Re: [Milkymist-devel] [Development Snapshots] Milkymist one software updates 2011-04-22

2011-04-26 Thread Adam Wang
Hi, reflash:(you still need UrJtag installed in your system) > we added autodown images to "reflash_m1.sh" so just download and execute it > http://www.milkymist.org/snapshots/2011-04-22/reflash_m1.sh > > >From your script, if I don't use JTAG/Serial cable, it should show: echo "there are er

Re: [Milkymist-devel] [MM1] DMX TX push and retention type connector

2011-04-26 Thread Wolfgang Spraul
> Ok, then let's not spend undue amounts of time on this minor issue and > just use a notch in the top acrylic plate. Faster and less risky. I think that looks quite ugly. Just wait a little we are trying to do a bit more investigation, you don't need to do anything. The options are all quite cle

Re: [Milkymist-devel] [MM1] DMX TX push and retention type connector

2011-04-26 Thread Sebastien Bourdeauducq
On Tue, 2011-04-26 at 13:17 +0800, Adam Wang wrote: > the retention type one needs a new footprint. Ok, then let's not spend undue amounts of time on this minor issue and just use a notch in the top acrylic plate. Faster and less risky. S. ___ http://

Re: [Milkymist-devel] MMU

2011-04-26 Thread Wesley W. Terpstra
Although I've already mentioned there are absolutely no problems with a VIPT mmu/cache design under the cache-size assumption Sebastien worked with, there is *also* no problem with exceeding this cache-size restriction for an operating system like linux. I'll explain why below. On 25/04/11 07:

Re: [Milkymist-devel] MMU

2011-04-26 Thread Wesley W. Terpstra
On 23/04/11 12:55 PM, Sebastien Bourdeauducq wrote: b) Use a simple cache with cache associativity * page size = cache size. Advantages: simple hardware, and solves above problems. Half the point of the LM32 is the sweet-spot in speed/size that it hits. This approach to an MMU lives at a similar