<kristianpaul> xiangfu: when you boot uclinux on your M1 the VGA out is working?
<wpwrak> grmbl. i hate it when my final strictly pro forma test produces worrying data. in a scenario what is fully exposed to NOR corruption, so far, loop2 has been doing 1300 cycles without trouble. i've never had it do more than 700 this far ...
<wpwrak> s/what/that/
<wpwrak> (loop2 is the ones that boots RTEMS but doesn't wait until FN is up)
<xiangfu> kristianpaul: VGA not working. under Linux.
<errordeveloper> lekernel: have you heard of this http://vrq.sourceforge.net/ ?
<lekernel> errordeveloper, no. interesting :-)
<lekernel> how to wait forever in verilog? like "wait;" in VHDL... does "wait(0);" work?
<lekernel> it does :)
<errordeveloper> ;]
<errordeveloper> I'm working on a script for PD rith now, just bumped into the vrq thing
<lekernel> PD?
<errordeveloper> puredata
<lekernel> mh? how does it relate to vrq?
<errordeveloper> there no relation
<errordeveloper> I was googling something and vrq came up somewhat :{]
<wpwrak> and of course it's mainly galling that the NOR corruption seems to have vanished now, even when i remove locking. this means that there is some yet unexplained parameter that affects all this. (or i'm having just incredibly bad luck and i've spent the last days way out on the tail of the bell curve)
<Guest33465> ouch
<wolfspra1l> that sounds depressing
<wpwrak> quite :-( i made some small changes to the test setup, namely connected a scope to monitor the power and tightened a loose nut in labsw. maybe these shifted things out of the "problem range"
<wpwrak> tightening the nut may have shifted some cables. i now notice fewer failures to switch (caused by interference). so maybe it wasn't the regular power cycling that triggered the corruption by these very brief surges. intentionally producing these is next on the list.
<wpwrak> at the moment, i'm testing with the scope removed (so DC IN isn't grounded). but that doesn't seem to have an effect. still need a few hundred more cycles, though.
<wpwrak> if it's the brief surges that triggered the NOR corruption, i should be able to make it happen up to about 10x more often that my initial tests showed. but we'll see.
<wolfspra1l> by now anything I say is this rumor-land, compared to your mountains of hard test data
<wolfspra1l> s/is this/is just/
<wolfspra1l> but I still am dubious whether electrical issues can trigger a write
<wolfspra1l> that's a pure guess though
<wolfspra1l> maybe someone is just writing :-) (in software)
<wolfspra1l> or is that ruled out already?
<wpwrak> it could be just sw
<wolfspra1l> that's my uneducated lazy guess
<wolfspra1l> :-)
<wpwrak> a possible failure scenario could be a 0x40 bit pattern present on D0-D7 plus some glitches on the write signal. that would provide the first write to enable word writing and then the second write to provide the actual data.
<wpwrak> (you need two write cycles to actually program a word into the NOR)
<wpwrak> 1304 cycles and counting. next test due at ~2000 (which would be 3-4x the number of cycles i needed originally to see a corruption)
<wpwrak> if the "quick surge" test doesn't do anything either, i'll go back to include rendering in the loop, i.e., the very beginning
<wpwrak> if that still doesn't do anything, i'll check the lock bits again. need to see if there's a non-destructive test for this. (e.g., write 0xffff and just check the status)
<wpwrak> of course, i've already made sure twice the lock bits aren't set, so i don't really expect to find something unusual at that step
<wpwrak> if things still are weird, i think it's a for a bottle of wine. that followed by a nap often helps to boost out of the box thinking ;-)
<wpwrak> wolfspra1l: btw, how are the launch preparations going ? did you already book the airtime on youtube ? ;-)
<wolfspra1l> need to discuss with Jon
<wolfspra1l> right now I am working through a list of people who have expressed interest
<wpwrak> sort of the first wave ? while adam is assembling cases
<wolfspra1l> yes, correct
<wolfspra1l> first 'wave' maybe a little too much
<wolfspra1l> as expected most people bail once it comes to paying
<wolfspra1l> that's how I clear out my Inbox :-)
<wolfspra1l> but some don't, and we have shipped out units
<wolfspra1l> Adam builds up inventory
<wpwrak> (inventory) good. don't want to build up long lead times instants after the great announcement :)
<wpwrak> (bail out) there's that great distance between the mouth and the wallet ...
<wolfspra1l> yes I love how it clears my Inbox
<wolfspra1l> fresh air
<wpwrak> ;-))
<wpwrak> what's the serious vs. vapour ratio ?
<wolfspra1l> ratio again may be too much, I think I shipped out 2 units to paying customers :-)
<wolfspra1l> a few more are in process
<wolfspra1l> some definitely went MIA after receiving the mail that they can now order :-)
<wolfspra1l> all fine
<wolfspra1l> yes, launch still coming, asap
<wolfspra1l> that depends on journalists too, in fact mostly
<wpwrak> what's the process with journalists ?
<wolfspra1l> need to email some and see what they say, coordinate with Jon
<wolfspra1l> next week probably
<wpwrak> good. so, the public launch would be in about one week ?
<wolfspra1l> he
<wolfspra1l> we don't have that much control over it, it requires journalists to cooperate
<wolfspra1l> but yes, sure, it's getting close
<wpwrak> do you want them to just reproduce your press statement or do you plan to provide them with a hands-on experience ?
<wpwrak> or, somewhere in the middle, do an interview ?
<wolfspra1l> your quality standards come from a time long gone :-)
<wolfspra1l> almost nobody writes about things they actually tried anymore
<wolfspra1l> what you read are 'stories', imagined stuff :-)
<wpwrak> some do :) depends on whom you're targetting
<wolfspra1l> with the NanoNote, we did have 2 or 3 stories from journalists that actually worked on their piece
<wolfspra1l> they bought a NanoNote, there was an email exchange with questions etc. and eventually the article
<wpwrak> wow. quite a lot then.
<wolfspra1l> but the majority, and especially the 'launch', was not like this and I don't expect it for M1
<wpwrak> the majority will probably already fail to get your "have to buy to play" rule
<wolfspra1l> nah they have not time and no interest
<wpwrak> of course, with M1 that gets even worse - on both sides
<wolfspra1l> no. their time is far more valuable.
<wolfspra1l> it's all made up.
<wolfspra1l> actually I've wondered this myself
<wpwrak> (time valuable) do they see it like that, too ?
<wolfspra1l> how can a journalist write day after day mostly on hearsay? crazy
<wolfspra1l> :-)
<wolfspra1l> that's why the entire tech journalism is in the state it's in, deplorable imho
<wpwrak> welcome to corporate planet earth :)
<wolfspra1l> and who reads it... bored geeks
<wpwrak> :)
<wolfspra1l> you just go to engadget.com, and you go through, and I guarantee you, it's all hearsay, every last story
<wolfspra1l> it's more like a 'reality show' :-)
<wolfspra1l> which of course is also not about reality...
<wpwrak> a rarely venture to engadget ... :)
<wolfspra1l> yes hard to read
<wolfspra1l> painful
<wolfspra1l> they should spice it up more
<wolfspra1l> get some good screenwriters from actual reality shows, to add some drama
<wpwrak> heh ;-)
<wpwrak> some martial arts fighter from samsung against a nazghul from apple. that could be fun :)
<wolfspra1l> well, the raw material is tough
<wolfspra1l> lots of overweight middle-aged men
<wpwrak> ;-
<wpwrak> ))
<wolfspra1l> but they are quite creative to turn the lamest raw ingredients to something thrilling on TV...
<wpwrak> reminds me to have lunch :)
<wolfspra1l> so? can anybody help the tech press?
<wolfspra1l> probably not
<wpwrak> you used TV and thrilling in the same sentence ? i'm impressed :)
<wolfspra1l> but anyway, we do need a launch, and we need some luck
<wpwrak> yeah. let's hope there is poetic justice and all the hard work does pay off :)
<lekernel> wolfspra1l, we shouldn't focus only on the tech press
<lekernel> the music/arts press is worth trying too
<roh> if apple continues on that course they'll end up in simpsons again.
<wpwrak> roh: do you think jobs has a simpsonphobia ?
<lekernel> wolfspra1l, also, again: why don't you enable the sharism webshop again? it would take you 10 minutes, looks more professional, and you don't have to deal manually with people bailing out again
<roh> naaah. but its still entertaining if even in there somebody makes fun of em
<wpwrak> lekernel: agreed. a web shop that just says "closed" looks very very bad
<wpwrak> might as well board it up
<lekernel> I have totally removed the link from milkymist.org/buy.html ... and said to email sales@
<roh> change the 'closed' to 'open soon'
<lekernel> hoping this would last only a few days...
<wpwrak> lekernel: probably a good choice. that "OUT OF STOCK - GO AWAY" is quite anti-marketing ...
<lekernel> yes, it's less bad
<wpwrak> it' basically says "we don't have it. we don't have any plans either. we don't want your questions either. we don't even know if we're in business anymore."
<kristianpaul> rtems internals had changed a bit since last git pull :-)
<kristianpaul> he, finally rtems_nfsfs_initialize is  rtems_nfs_initialize, wich make more sense :-)
<kristianpaul> oh, yaffs had changed too including a flush task? ..
<kristianpaul> the only feature needs a RTEMS_FILESYSTEM_READ_WRITE is telnet user/paswwd to be stored, and wallpaper preference i guess too
<larsc> lekernel: hm, so how does the lm32 interrupt controller work? i send a trigger pulse to mark an interrupt as active and get an ack pulse back, when the interrupt is cleared?
<mwalle> larsc: ack pulse?
<larsc> mwalle: there doesn't seem to be one
<mwalle> larsc: who needs an ack anyway?
<larsc> me
<larsc> ;)
<larsc> looking at the source code, it looks as if the interrupts are level triggered
<mwalle> mm/bios sourcecode or lm32 verilog code?
<larsc> lm32
<larsc> verilog code
<larsc> cores/lm32/rtl/lm32_interrupt.v
<mwalle> the cpu interrupt line is latched until the cpu actually executes the interrupt iirc
<mwalle> and is then cleared
<mwalle> have a look at my serial break interrupt logic
<larsc> i meant the signals which go into the interrupt controller
<mwalle> IP stays asserted until you ack it, if any(IP & IM) => cpu_interrupt
<mwalle> IE is cleared and saved in BIE/EIE if interrupt is executed
<larsc> but IP will also stay asserted if the source has not been cleared
<mwalle> yes
<mwalle> so you can either use pulses or levels, in the latter case you have to make sure to ack your core before you ack IP
<larsc> yes
<larsc> i was just confused, because the way i understood it in the discussion a few weeks ago was that it was edge triggered
<mwalle> no its actually level triggered ;)
<larsc> which makes things easier
<kristianpaul> argg obj/main.o:(.data+0x148): undefined reference to `shellext'
<wpwrak> edge triggered is if you want to live on the edge - permanently ;-)
<larsc> it is usefull for certain external signals, but not really for internal signals
<wpwrak> (external) you mean where there's no means to ack ?
<larsc> yes
<larsc> like buttons
<wpwrak> heh :)
<wpwrak> buttons are tricky. need rather lavish preventions against all sorts of upsets if your environment is just hostile enough.
<larsc> we can do debouncing in software
<wpwrak> sometimes :)
<wpwrak> some of the bounces are of a different nature, though ...
<wpwrak> (i.e., interference)
<larsc> hm?