2011-08-12 00:01 [commit] Bart van Strien: Add libunistring (master) http://qi-hw.com/p/openwrt-packages/bb2a84c 2011-08-12 00:01 that took way too long 2011-08-12 00:03 all things worth doing took longer than they should have 2011-08-12 00:53 xiangfu: reading backlog about flash 2011-08-12 00:53 so by power cycling, you managed to flip a bit in your nor flash? 2011-08-12 00:54 maybe I am not sure. 2011-08-12 00:54 unfortunately the rc2 and rc3 boards are different in that area, that complicates our search 2011-08-12 00:54 werner replied in mailing list. If this is really a NOR corruption and if it is caused by incorrect 2011-08-12 00:54 sequencing of power supplies, perhaps power-cycling (instead of the 2011-08-12 00:54 reset button) could make it happen more often. 2011-08-12 00:55 I don't know how to narrow down the bug. needs help from Werner and Adam :) 2011-08-12 00:55 what is the reset button? werner means reset in the gui? 2011-08-12 00:55 I think he means press all three buttons for reboot. 2011-08-12 00:57 I am do "replug the dc adapter male plug" for power-cycling 2011-08-12 02:32 xiangfu: (reset button) err yes, whatever button press makes the M1 reset ;-) 2011-08-12 02:34 ok so we have 3 ways to reset: 2011-08-12 02:34 for now, i'd suggest to establish how often this happens. i.e., with a fixed reset procedure, repeat until hitting maybe 10 or more corruption events. (after each, reflash) 2011-08-12 02:34 1) cold removal of power supply, either by removing DC jack or by unplugging/switching off the power behind the adapter 2011-08-12 02:34 2) press three buttons at once for reset 2011-08-12 02:34 3) power off (or reset) in the gui 2011-08-12 02:34 so actually it's 5 ways 2011-08-12 02:34 1) unplug DC jack 2011-08-12 02:35 2) unplug power supply itself from mains 2011-08-12 02:35 3) press three buttons 2011-08-12 02:35 4) 'reset' in gui 2011-08-12 02:35 5) 'power off' in gui 2011-08-12 02:35 The build has FAILED, see log here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-08112011-0046/ 2011-08-12 02:37 bartbes: seems you managed to solve it :) sorry i wasnt able to help. actually now that there is a openwrt-milkymist port i think i'll care more about later about learn about makefiles and packaging 2011-08-12 02:43 wpwrak: 10 corruption events!!! :-) 2011-08-12 02:43 you will drive everybody to heart attack. This event is relatively rare, don't forget. 2011-08-12 02:43 if adam sets 38 boards to 'available', that's 380 full power to render cycles without any such occurance. 2011-08-12 02:43 and maybe 3-5 boards did show the problem in between 2011-08-12 02:43 so maybe 1-2 times per 100 power cycles 2011-08-12 02:43 if you look at it that way 2011-08-12 02:43 but right now we know too little 2011-08-12 02:43 not just 'power cycle', actually it's a full rendering cycle with boot-to-render and then let it render for 30 seconds 2011-08-12 02:43 i think we could try and see if unplugging the DC jack does the trick. unplugging mains would be even nastier, but it's also less controllable 2011-08-12 02:43 xiangfu: btw, after flashing, are the partitions write-protected again ? 2011-08-12 02:44 (10 events) yeah, but otherwise you don't know how long you have to test to be reasonably sure you've nailed it :) 2011-08-12 02:45 100 events would of course be better ;-) 2011-08-12 02:47 the good news: unless adam always runs the tests and checks the test logs, he may see a much lower than real incidence, because he'll probably only notice bitstream corruptions 2011-08-12 02:47 wpwrak, (write protected) hmm... I use urjtag flash them. there is now write-protect like command in urjtag 2011-08-12 02:48 wpwrak, the flash output is like unlock... flashing... unlock... flashing... 2011-08-12 02:48 ;-) 2011-08-12 02:49 wpwrak, how this write-protect works? 2011-08-12 02:49 lemme check ... there are many different ways how NOR chips do this 2011-08-12 02:49 0x7F histories: 1. After reflash, D2/D3 is dimly lit by used 1.8M usb cable. 2. http://downloads.qi-hardware.com/hardware/milkymist_one/production/rc3/test_results/7F-reflash-results 3. can reconfigure after powered on since replaced u7/u19/u20 and couple days late 4. tested image pass 2011-08-12 02:50 please don't ask me do some tests now....  i just posted here if i found interesting. ;-) 2011-08-12 02:52 aw_: what's interesting about 0x7F ? 2011-08-12 02:52 0x7F passes all tests now? 2011-08-12 02:52 http://www.micron.com/get-document/?documentId=6062&file=319942_J3_65_256M_MLC_DS.pdf 2011-08-12 02:53 page 28. "Configurable Block Locking" ... " For additional information and collateral request, please contact your filed representative ." haha, very funny 2011-08-12 02:53 the one was d2/d3 dimly lit after used 1.8 M ago. then today I powered on and d2 is fully off so that I started to test it. ;-) surely 0x7f was replaced new u7/u19/u20. ;-) 2011-08-12 02:55 now it's all passed except 8:10 which i forgot to insert card. ;-) do rendering next. :) 2011-08-12 02:55 ok 2011-08-12 02:55 not sure whether that's related to the flash problems 2011-08-12 02:55 xiangfu: however, section 10.1 (on the same page) might be useful. if the blocks are left unlocked, that's an invitation for trouble. you probably still have partitions where writes are expected and don't want to lock these. but at least the bitstream and maybe also the rescue stuff should probably default to being locked 2011-08-12 02:55 but that's why you go through the entire batch now, so that we can then see the flash problem more clearly 2011-08-12 02:56 (locking) good, now i can finally call that nor chip rom :) 2011-08-12 02:57 xiangfu: when your board couldn't boot anymore because standby was corrupted (maybe), was the rescue boot still working? 2011-08-12 02:57 kristianpaul: you could, if you didn't need to store data there. when you download patches, where do they go ? i'd guess to the NOR, right ? 2011-08-12 02:58 wpwrak, thanks. so there are some addition area for store the block lock info? 2011-08-12 02:58 wpwrak: actually sebastien idea is that, for a writable FS  memory card have a job :) 2011-08-12 02:58 hmm...0x7f: bad that can't configure after powered-cyle. :( 2011-08-12 02:58 wpwrak: pathces can be loaded from memcard 2011-08-12 02:58 wpwrak, (rescue stuff shoudl be locked) yes. 2011-08-12 02:59 wpwrak: store, i think user and pass for ftp, dunno what else i lost the track to flickerinose 2011-08-12 02:59 aw_: wait 2011-08-12 02:59 so you just reflashed 0x7f, successfully (according to flash script) 2011-08-12 02:59 then you ran the test software that was loaded over serial, and it succeeded 2011-08-12 03:00 wolfspraul, no reflash 2011-08-12 03:00 section 10.4 is funny. a "password access", some 64 bits string. as if that accomplished much ;-)) 2011-08-12 03:00 yes 2011-08-12 03:00 now you try to power cycle but it won't boot? 2011-08-12 03:00 how did you power cycle? 2011-08-12 03:00 and how does it stop? d2/d3 dimly lit? 2011-08-12 03:00 it successed. so I inserted 8:10 card then powered on ...and d2 is dimly lit though. :( 2011-08-12 03:00 wpwrak: (password) so murphy cant guess that one :) 2011-08-12 03:01 i unplugged the dc jack's plug 2011-08-12 03:01 and replugged it 2011-08-12 03:01 is 'd2 dimly lit' the same as the nor flash corruption or a separate bug? 2011-08-12 03:01 kristianpaul: naw, i think it's meant as a means to protect confidential content. now, how hard would it to record that bit string ? :) 2011-08-12 03:02 ahh 2011-08-12 03:02 shame 2011-08-12 03:02 hum yes 2011-08-12 03:02 seems once it had have d2/d3 dimly lit  after first flash, it will be easily show d2 dimly lit once power on 2011-08-12 03:03 xiangfu: (lock) in the NOR data sheet, sections 6.1 and 6.2. it should be very similar to the unlocking operation 2011-08-12 03:03 well..records firstly then continue other boards. 2011-08-12 03:04 yeah 2011-08-12 03:04 wasn't the reset circuit meant to fix the 'd2 dimly lit' problem? 2011-08-12 03:04 wasn't it reset -> fix NOR corruption and NOR corruption -> "d2 dimly lit" ? 2011-08-12 03:05 unfortunately that's what we will only really learn and understand right now in the middle of the rc3 run ;-) 2011-08-12 03:05 so i think we have some evidence that the reset circuit in its present state isn't sufficient to make NOR corruption go away 2011-08-12 03:06 hmm 2011-08-12 03:06 the 'd2 dimly lit' problem I knew about went after after power cycling again 2011-08-12 03:06 (evidence) at least xiangfu's M1rc2 seems to suffer real NOR corruption. we haven't properly established that on an M1rc3 yet, though 2011-08-12 03:07 aw_: can you try to power cycle 0x7F three times? 2011-08-12 03:07 ah, interesting. thought that was also the symptom of bad NOR 2011-08-12 03:07 wolfspraul, ok 2011-08-12 03:07 many m1 rc2 users have found workarounds for power cycle/boot problems for themselves 2011-08-12 03:08 that complicates our analysis now 2011-08-12 03:08 wpwrak, I only find the unlock code in urjtag. not found the lock code. 2011-08-12 03:09 wpwrak, let me find the source code url. 2011-08-12 03:09 wolfspraul, all d2 dimly lit now in three times powered-cycle. 2011-08-12 03:09 the data they report is biased because of their workarounds. so we need to try to remove that now. 2011-08-12 03:09 aw_: he :-) try another 3 times, wait 5 seconds in between. 2011-08-12 03:09 xiangfu: check the data sheet. it describes the lock/unlock process. once you've found the same bytes for the unlock, it should be easy to do the locking 2011-08-12 03:09 xiangfu: http://www.micron.com/get-document/?documentId=6062&file=319942_J3_65_256M_MLC_DS.pdf 2011-08-12 03:10 wolfspraul, already stays 5 seconds in between. 2011-08-12 03:10 xiangfu: pages 18 to 20 2011-08-12 03:10 can you lock each page separately? 2011-08-12 03:10 and the locking is stored in the nor as well? 2011-08-12 03:10 wolfspraul: correct (2x) 2011-08-12 03:10 aw_: yes just try another 3 times, to be sure 2011-08-12 03:11 if it is so persistent, it's definitely not the 'd2 dimly lit' problem I know from my rc2 2011-08-12 03:11 wolfspraul: well, each block. NOT doesn't have pages :) 2011-08-12 03:11 s/NOT/NOR/ 2011-08-12 03:11 and our partitions end in full blocks? 2011-08-12 03:11 xiangfu ? 2011-08-12 03:12 wpwrak, yes. end in full blocks 2011-08-12 03:13 wpwrak, here is the code for reflash m1: http://urjtag.git.sourceforge.net/git/gitweb.cgi?p=urjtag/urjtag;a=blob;f=urjtag/src/flash/intel.c;h=6e13a4363f73a29a4130c9358b0e2754fcfd2678;hb=HEAD 2011-08-12 03:14 wolfspraul, still d2/d3 dimly lit, wait at least 5 seconds in between. i felt it keeps this stage unless I put aside it long long time even day. ;-) 2011-08-12 03:14 hmm 2011-08-12 03:14 ok 2011-08-12 03:14 move it aside 2011-08-12 03:14 :-) 2011-08-12 03:14 a proper (!) flash corruption will not fix itself 2011-08-12 03:14 :-) 2011-08-12 03:15 so it should not come back even after several days, which it sometimes does 2011-08-12 03:15 so I think there are several different problems here, masking each other partially 2011-08-12 03:15 aw_: just continue with the full round, then we look at all data carefully 2011-08-12 03:16 wolfspraul, yes 2011-08-12 03:16 ok so right now, we are not locking anything in the nor flash 2011-08-12 03:16 xiangfu: you can probably just copy the unlock functions, change UNLOCK_BLOCK to LOCK_BLOCK, and you're done 2011-08-12 03:16 but werner proposes to look several parts like rescue bitstream and maybe more 2011-08-12 03:16 (fix itself) so bus corruption? fpga..  a 20Ghz scope near? ;) 2011-08-12 03:16 xiangfu: well, plus calling them ;-) 2011-08-12 03:17 s/look/lock/ 2011-08-12 03:17 if we lock anything, my thoughts would be: a) how does that impact the ability for web updates or other updates 2011-08-12 03:18 is the NOR mapped in the LM32's memory address space ? 2011-08-12 03:18 b) are we just covering up the real bug behind a lock (even if effective), or is this a proper fix still? 2011-08-12 03:18 just my thoughts, nothing else 2011-08-12 03:18 just an extra protection 2011-08-12 03:18 so you shouldn't set the locks when hunting the corruption 2011-08-12 03:19 and the locks need to be removed for updates 2011-08-12 03:19 wpwrak: yes is mapped 2011-08-12 03:19 then not locking those things borders on insanity ;-) 2011-08-12 03:20 I don't think the "power-to-render cycles leading to unreconfigurable board" is related to anything the fpga does during rendering 2011-08-12 03:20 considering that there's not even an MMU. any little sw bug can corrupt your NOR :) 2011-08-12 03:20 that's because we see this problem regularly when doing sets of 10 power cycles with 30 second rendering sprints 2011-08-12 03:20 ;) 2011-08-12 03:21 but I never once have heard from it after a multi-hour rendering 2011-08-12 03:21 that's a very weak logic, but still 2011-08-12 03:21 it could be that long renderings are rare, and we are not focusing enough on this problem 2011-08-12 03:21 that's not to say that an unlocked memory mapped NOR is insane 2011-08-12 03:22 wolfspraul: (ability to update) the update process would have to unlock before writing, then lock again. should be no problem. 2011-08-12 03:22 welcome to m1 :-) 2011-08-12 03:22 yes 2011-08-12 03:22 but that needs to be added 2011-08-12 03:22 there are two risks in start selling rc3 now, basically signing off boards to leave Taipei 2011-08-12 03:22 wpwrak: okay that another reason for a MMU, i think now i get more sense to me have one :) 2011-08-12 03:22 the first risk is that the hardware is physically in a state that requires a fix later (a hardware fix) 2011-08-12 03:23 the second risk is that it is a software problem only, but the board is driven into a state where a normal user cannot recover it anymore, leading to them potentially having to ship units around the world for unbricking 2011-08-12 03:24 (corrupting NOR via writes) i think it's a little more difficult than just doing a single bus cycle, but with protection off and all that, you're a lot closer to being able to inflict mayhem than you want to be 2011-08-12 03:25 wolfspraul: yes, you could try and see if locking properly protects the rescue partitions. that would at least allow recovery without usb-jtag. but without solving the origin of the corruption (which may be hw), M1s would still see corruption 2011-08-12 03:25 just in recoverable partitions. e.g., the one where all the patches for your show tonight are :) 2011-08-12 03:25 that's exactly how I see it too 2011-08-12 03:26 a lot of work ;-) 2011-08-12 03:26 oh the units are not 'production ready' in its current state 2011-08-12 03:27 the evidence pointing to power cycling being a factor is strong. particularly given that people who rarely power cycle but reset often don't seem to experience NOR corruption easily 2011-08-12 03:27 since the normal (web) update does not update the rescue stuff, it would be a relatively easy next step to lock all rescue partitions 2011-08-12 03:27 xiangfu: so maybe you can try to get the locking done, and the we regularly lock all rescue partitions, as the normal process of reflash_m1.sh ? 2011-08-12 03:28 I don't see the downside to that right now 2011-08-12 03:28 wolfspraul, ye. lock all rescue part partitions should be ok. 2011-08-12 03:29 how many partitions is that? 2011-08-12 03:29 I still don't have a mental map of all our partitions 2011-08-12 03:29 to corrupt the NOR, this should do nicely: volatile uint32_t *p = (void *) 0xSOMEWHERE; *p = 0x40; *p = 0; 2011-08-12 03:29 wpwrak, how can I test if the lock is correct. write some thing to this area then readback. will different. right? 2011-08-12 03:29 test? 2011-08-12 03:29 just lock then be happy 2011-08-12 03:29 :-) 2011-08-12 03:30 i mean make sure the code is do lock correct. 2011-08-12 03:30 sure, I was joking 2011-08-12 03:30 you could use the code snippet from above. if the lock works, then it won't be able to zero the word in question. else, ... :) 2011-08-12 03:30 wolfspraul, http://www.milkymist.org/wiki/index.php?title=Flashing_the_Milkymist_One#Flash_Memory_Distribution 2011-08-12 03:30 wolfspraul, all rescue + standby. so 5 partitions 2011-08-12 03:32 xiangfu: the standby bitstream is needed by the rescue boot path? 2011-08-12 03:32 it will goto standby after you plug the power. 2011-08-12 03:33 so it's always needed, even in rescue mode? 2011-08-12 03:33 yes. 2011-08-12 03:33 is the standby bitstream updated by the web update? 2011-08-12 03:33 no 2011-08-12 03:34 then it should probably be locked as well 2011-08-12 03:34 xiangfu: it seems that you read the lock bit with the Read Device Information command. that command changes the way the NOR behaves. reads then return status information, not the NOR data. 2011-08-12 03:34 if I understand correct. when plug power. fpga will load standby immediately, for enable the power button. reboot button. etc. 2011-08-12 03:34 xiangfu: then you can retrieve the lock bit, see page 22, table 9 2011-08-12 03:34 ah yes, you said that already 2011-08-12 03:34 in total lock 5 partitions 2011-08-12 03:35 btw, the single-bit corruption (if it was one) xiangfu saw is not likely caused by a simple software pointer problem. that would have been much more likely to overwrite an entire word or more 2011-08-12 03:37 probably lock more than 5. the regular bitstream for sure. then, does FN normally need to write to BIOS, splash, APP ? or only to Data ? 2011-08-12 03:38 i don't know how often you can lock/unlock. probably not more often than you can write a regular NOR cell. so locking/unlocking should roughly follow the frequency of program cycles of the respective block. 2011-08-12 03:39 you may want to ask numonyx for clarification, though 2011-08-12 03:39 wpwrak, (read device Information command) yes. 2011-08-12 03:39 wolfspraul: 0 is a very common word value :) 2011-08-12 03:40 but only 1 bit was changed 2011-08-12 03:40 wolfspraul: remember that the transition was 0x1000 -> 0x0000 2011-08-12 03:40 wolfspraul: yes, there was only one "1" bit there to destroy :) 2011-08-12 03:40 more diff: http://dpaste.com/592480/ 2011-08-12 03:40 if the standby bitstream is corrupted in random ways (offsets), then whether D2/D3 stay fully off, or dimly lit, may be just a coincidence and caused by the same root problem 2011-08-12 03:41 hmm, true 2011-08-12 03:42 xiangfu: hmm, does that mean that everything after 0078dd0 is 0 ? or that the file ended at 0078dd0 ? 2011-08-12 03:42 also we maybe needs erase all NOR flash before flash . 2011-08-12 03:43 wpwrak, the origin file is only 495060 length. so it end at 0078dd0 2011-08-12 03:43 wpwrak, when I read back the standy , I read whole 640KB from m1. so it end at 00a0000 2011-08-12 03:43 xiangfu: ah, so the stuff at the end is a retrieval artefact 2011-08-12 03:44 xiangfu: yes erase all sounds good. we don't do that now? 2011-08-12 03:45 no 2011-08-12 03:45 how fast/slow would it be? 2011-08-12 03:45 erase very fast. 2011-08-12 03:45 acceptable 2011-08-12 03:45 you probably erase each block before writing it. that may or may not be sufficient. depends a bit on what the software expects. 2011-08-12 03:46 in a perfect world we should not need the erase, I guess 2011-08-12 03:46 i think you do 2011-08-12 03:46 erase: 0/1 -> 1. write: 1 -> 0 2011-08-12 03:46 when flash we do need erase. 2011-08-12 03:46 well, write: 0/1 -> 0 2011-08-12 03:47 see the http://dpaste.com/592480/ line 16. 2011-08-12 03:47 it maybe because the last standby.bin is small then the previous one 2011-08-12 03:48 erase all nor flash can make all those bit to '1' :) 2011-08-12 03:49 xiangfu: those two extra words (0004 0004) are indeed a little odd. they're within the same block. so they must have been erased. (if you never erased, you would have noticed by now :) 2011-08-12 03:49 xiangfu: so something is writing a bit of extra data that's not in the file 2011-08-12 03:50 wpwrak, (forget the block size). yes. something is writing a bit of extra data. 2011-08-12 03:50 one more for the bug pile ;-) 2011-08-12 03:50 then that is a bug in urjtag 2011-08-12 03:50 yes. 2011-08-12 03:51 yeah, probably urjtag 2011-08-12 03:51 I can read more partition and compare . 2011-08-12 03:51 see if this happen in other partitions. 2011-08-12 03:51 maybe some  for (i = 0; i <= n; i++) program_word(i);   :) 2011-08-12 03:54 fake a file witha now patter 2011-08-12 03:54 write it read back 2011-08-12 03:54 comapre :) 2011-08-12 03:54 then change the size and repeat. dd if=/dev/urandom  is your friend :) 2011-08-12 03:59 bugs everywhere. sigh. but I need to decide whether we can start selling 'good' rc3 boards or not ;-0 2011-08-12 04:01 at least we have _lots_ of good starting points 2011-08-12 04:06 do we have consensus that we should add a full 32 megabytes erase to reflash_m1.sh ? 2011-08-12 04:07 at least will help to track corupt yes ;) 2011-08-12 04:09 xiangfu: is Adam using reflash_m1.sh or reflash_all.batch ? 2011-08-12 04:11 is this up-to-date? http://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule#Flash_Test_Tool_Image 2011-08-12 04:13 wolfspraul xiangfu , i used reflash_m1.sh not reflash_all.batch 2011-08-12 04:13 even is memory mapped i cant get to write as easy as it could sound.. 2011-08-12 04:13 but yes i can read 2011-08-12 04:13 (NOR) 2011-08-12 04:14 ok we should update the wiki instructions, also the wiki points to a commit etc - quite confusing 2011-08-12 04:14 I mean for the test software image 2011-08-12 04:15 aw_: don't worry, you focus on the boards Xiangfu is working on the tools :-) 2011-08-12 04:16 42 'available' now, not bad 2011-08-12 04:17 wolfspraul, good. i just used his xiangfu's last email in private last time though. not sure if already existed on public server. 2011-08-12 04:17 sell sell ! _) 2011-08-12 04:17 growing :-) 2011-08-12 04:17 xiangfu, http://pastebin.com/cAcWHGBN 2011-08-12 04:17 well, xiangfu needs to make sure it's all public and update the wiki too. then it's easier for others to follow the exact same process. 2011-08-12 04:18 alright then ..i go lunch firstly then back to rework on usb. 2011-08-12 04:22 (update) yeah, lots of usefull scripts now 2011-08-12 04:26 xiangfu: alright, so Adam uses reflash_m1.sh 2011-08-12 04:27 should we add a full 32 megabytes erase to reflash_m1.sh ? 2011-08-12 04:28 lol my LG remote now generates ramdon data on flickernoise :) 2011-08-12 04:29 yes I've seen that as well 2011-08-12 04:29 at least we can make sure all non-used area is '1' 2011-08-12 04:29 kristianpaul, it is a test screen. 2011-08-12 04:29 kristianpaul, wait input from serial console. 'b' is for 'boot' 2011-08-12 04:30 I'm just asking what the consensus now is? 2011-08-12 04:30 xiangfu: boot for? 2011-08-12 04:30 we already said we want to lock 5 partitions (standby+rescue) 2011-08-12 04:30 that's clear 2011-08-12 04:30 boot to flickernoise. normal boot 2011-08-12 04:30 ah, sure  running it now :) 2011-08-12 04:30 i could not resist 2011-08-12 04:30 it work out of the box ! 2011-08-12 04:31 kristianpaul, there is a help message output from serial console. that can test screen. 2011-08-12 04:31 bit slow bott.. but well :) 2011-08-12 04:31 how about adding nor erase, don't know 2011-08-12 04:31 maybe a good idea to establish a baseline 2011-08-12 04:31 also because we have so many uncertainties in the tools, jtag, cable, signal integrity, etc. etc. 2011-08-12 04:31 seems like uncertainties everywhere 2011-08-12 04:32 so if we add some more baselines, even if they are theoretically unnecessary, it could help pull some of the other uncertainties apart 2011-08-12 04:32 okay i'll sleep now but let mm1 rendering whole nigh ! 2011-08-12 04:32 that's why I was thinking maybe reflash_m1.sh, at least when it reflashs all partitions, should start with a full 32 megabytes erase 2011-08-12 04:33 will be nice as temp will drop to 19°C (28°C now) 2011-08-12 04:33 s/will/may 2011-08-12 04:33 gn8 2011-08-12 04:33 n8 2011-08-12 04:37 btw a knowlesdge base for know workarounds is not bad ;) 2011-08-12 04:38 to have, i think 2011-08-12 04:38 well 2011-08-12 04:38 not so easy 2011-08-12 04:38 too few users, too many bugs 2011-08-12 04:39 the beginning is difficult, and that's what we go through now 2011-08-12 04:39 with good will and a little patience, we'll make it 2011-08-12 04:40 (users) true, no worth effort yet 2011-08-12 04:40 wiki page : http://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule#Flash_Flickernoise_1.0RC1_.2F_SoC_1.0_updates_and_Run_3_images 2011-08-12 04:40 update a little. 2011-08-12 04:41 should be more clear then before. delete out-data script.  we only use one in RC3. 2011-08-12 04:41 http://milkymist.org/updates/2011-07-13/for-rc3/reflash_m1.sh 2011-08-12 05:13 wolfspraul: (full erase) doesn't seem necessary 2011-08-12 05:27 The JLime kernel tree compiles and sees the entire NAND. I wasn't able to get previous kernels to see that extra NAND. I've deducted that it my be a kernel option. Anyone know what that might be? 2011-08-12 08:26 aw_, Hi 2011-08-12 08:26 http://milkymist.org/updates/current/for-rc3/reflash_m1.sh. I update the reflash_m1.sh, erase the whole nor flash before write anything. 2011-08-12 08:26 xiangfu, hi yes 2011-08-12 08:27 aw_, you can use new one(__VERSION__="2011-08-12") from now on. 2011-08-12 08:27 xiangfu, okay.great 2011-08-12 08:29 xiangfu, just directly use this 08-12 script only, right? no else image file attached? 2011-08-12 08:30 aw_, no needs touch any other files. just this 08-12 script. 2011-08-12 08:32 xiangfu, okay..I'll mark note on those rest boards's record, so i know which board is done by erase. thanks. 2011-08-12 08:32 aw_, your reflash log is enough. yes. you can mark note on boards 2011-08-12 08:34 aw_, the  reflash_m1.sh output will be different 2011-08-12 08:36 xiangfu, okay..I'll watch it..now still reworking. :) 2011-08-12 08:39 aw_, sorry. I upload a new one. if you already download, download again. just output the VERSION before it start flash. 2011-08-12 08:40 xiangfu, alright. ;-) 2011-08-12 10:41 <`antonio`> bartbes, hi, did you manage to compile  guile 2.0 2011-08-12 10:41 `antonio`: still working on it, I just found another dependency 2011-08-12 10:42 which was delayed because that project's hosting went down for a bit 2011-08-12 10:42 it's back up again, so that's building now 2011-08-12 10:44 <`antonio`> how is it going then ? 2011-08-12 10:44 <`antonio`> i a trying to build guile 2.0 as well 2011-08-12 10:44 <`antonio`> but i'm having some problems 2011-08-12 10:46 more dependencies, woo 2011-08-12 10:47 bartbes, did u compile libunistring successfully? 2011-08-12 10:47 yes 2011-08-12 10:47 any patch required? 2011-08-12 10:48 yes 2011-08-12 10:48 it's in the repo already 2011-08-12 10:48 is it uclibc related? 2011-08-12 10:48 http://projects.qi-hardware.com/index.php/p/openwrt-packages/source/tree/master/libunistring 2011-08-12 10:48 yeah 2011-08-12 10:49 ok cool, we had the same issue, patched it. but later we had some other errors related to locale 2011-08-12 10:50 I can only hope I didn't break it 2011-08-12 10:50 time will tell 2011-08-12 10:50 <`antonio`> guile 2.0 have some problems in the future with locale 2011-08-12 10:51 <`antonio`> bartbes, did you create any patch for guile 2.0 ? 2011-08-12 10:51 jivs: if it is, indeed broken, I will see if I can work around, i.e. add some UCLIBC code 2011-08-12 10:51 I had to exchange a faulty configure.ac line, so far 2011-08-12 10:51 we patched it this way, may be it was not right.: #  if __GLIBC__ >= 2 2011-08-12 10:51 +#  if __GLIBC__ >= 2  && !defined __UCLIBC__ 2011-08-12 10:52 ok 2011-08-12 10:52 do note that I have yet to get it to actually get to compiling 2011-08-12 10:53 finally, configure finished 2011-08-12 10:53 now, we'll see what happens 2011-08-12 10:53 .. yeah 2011-08-12 10:53 cool 2011-08-12 10:53 <`antonio`> bartbes, yeh we passed configure 2011-08-12 10:53 that failed 2011-08-12 10:53 <`antonio`> pastebin it 2011-08-12 10:55 duplocal makes pointer from integer 2011-08-12 10:55 <`antonio`> cool 2011-08-12 10:55 <`antonio`> that's fine i solved that 2011-08-12 10:55 do tell 2011-08-12 10:56 <`antonio`> I hope that's the proper way of doing it: 2011-08-12 10:56 <`antonio`> basically in the guile make file add the CONFIGURE_ARGS 2011-08-12 10:57 <`antonio`> CONFIGURE_ARGS += -C 2011-08-12 10:57 <`antonio`> and do make package/guile/{clean,compile} V=99 2011-08-12 10:57 "  -C, --config-cache      alias for `--cache-file=config.cache'"? 2011-08-12 10:58 <`antonio`> yeh 2011-08-12 10:58 hmm right 2011-08-12 10:58 <`antonio`> in the config.cache 2011-08-12 10:58 <`antonio`> basically is failing because we need to set some proper variables 2011-08-12 10:58 <`antonio`> i'll give you the line in a sec 2011-08-12 10:59 it's already recompiling 2011-08-12 10:59 <`antonio`> do clean,prepare then 2011-08-12 10:59 <`antonio`> don't let it pass the configuring otherview it will not go through the config.cache 2011-08-12 11:00 <`antonio`> in the config.cache search for duplocale  and there is something like this 2011-08-12 11:00 <`antonio`> gl_cv_func_duplocale_works=${gl_cv_func_duplocale_works='guessing no'} 2011-08-12 11:00 <`antonio`> change no to yes 2011-08-12 11:00 <`antonio`> and it will pass that error 2011-08-12 11:00 then.. this sounds like a very hacky solution 2011-08-12 11:00 the thing is, I know it doesn't work 2011-08-12 11:00 <`antonio`> this is a temporary solution 2011-08-12 11:01 because I believe it is the function I nerfed 2011-08-12 11:05 bartbes, do u think this error might be related with libunistring in some way? 2011-08-12 11:05 I would expect that, yes 2011-08-12 11:07 hmm 2011-08-12 11:08 it is a different function 2011-08-12 11:18 <`antonio`> which one? 2011-08-12 11:18 `antonio`: the proper way to override that (within an OpenWrt makefile) is  CONFIGURE_VARS += gl_cv_func_duplocale_works=yes 2011-08-12 11:18 no need to edit a config.cache 2011-08-12 11:19 <`antonio`> jow_laptop: nice, thanks 2011-08-12 11:19 the configure should then output something like  "Checking for foo ... yes (cached)" 2011-08-12 11:19 jow_laptop, thanks 2011-08-12 11:22 is there a MAKE_ARGS thing too? 2011-08-12 11:22 jow_laptop: ah, cool 2011-08-12 11:23 bartbes: yes 2011-08-12 11:24 I was going to override it at a later point, during make, but this probably works 2011-08-12 11:24 there is  MAKE_VARS  which overrides the environment (e.g.  FOO=bar make ...) 2011-08-12 11:25 and  MAKE_FLAGS  which extends the args (e.g.  make FOO=bar) 2011-08-12 11:25 right, so if it doesn't work I can play with MAKE_FLAGS, thanks 2011-08-12 11:26 just be sure to always append (+=) to those vars since they already contain a bunch of default overrides and variables 2011-08-12 14:56 `antonio`: I managed to get it down to a link error 2011-08-12 14:56 updating the old patch should fix that 2011-08-12 14:57 <`antonio`> can you paste bin it 2011-08-12 14:57 cool bartbes 2011-08-12 14:57 also time to take out all my desperate attempts 2011-08-12 14:58 it's just the csqrt one 2011-08-12 14:59 also, do you know what this 'issue with threads' is? 2011-08-12 14:59 csqrt, is it similar to the guile1.8.7 patch 2011-08-12 14:59 yeah 2011-08-12 14:59 so easy 2011-08-12 15:00 there is a patch for that already on 1.8.7, hopefully it will work 2011-08-12 15:01 no need to 2011-08-12 15:01 I know what it does 2011-08-12 15:01 so I can just replicate it 2011-08-12 15:01 okay 2011-08-12 15:01 I guess I might as well start working on become the richest man in the world 2011-08-12 15:01 because that will finish sooner than this compile 2011-08-12 15:02 so can be solved using configure_vars from Makefile. isn't it? 2011-08-12 15:02 <`antonio`> bartbes, how long it takes in your machine ? 2011-08-12 15:02 jivs: that's what I tried 2011-08-12 15:03 cool 2011-08-12 15:04 `antonio`: not as long as I made it out to be, but 10 mins, I guess 2011-08-12 15:04 if this build fails I'll time it for you 2011-08-12 15:04 (hoping it doesn't, though) 2011-08-12 15:05 lets be optimistic :-) 2011-08-12 15:06 well, you know, I'm undoing my desperate measures 2011-08-12 15:06 so it might very well happen 2011-08-12 15:21 `antonio`: well, 10 minutes seems like a good estimate for the source to compile 2011-08-12 15:21 it's been chewing through docs for a while now, though 2011-08-12 15:21 stupid texinfo manuals.. 2011-08-12 15:22 <`antonio`> so successfully completed ? 2011-08-12 15:25 <`antonio`> bartbes, then you'r almost there 2011-08-12 15:32 it's still creating manuals 2011-08-12 15:32 I'm going to have to see if there's an option to turn that off 2011-08-12 15:58 `antonio`: progress update: still compiling texinfo manuals 2011-08-12 15:58 not a fun activity 2011-08-12 15:58 <`antonio`> what processor do yo have? 2011-08-12 15:59 it's compiling on an old p4 2011-08-12 15:59 but still, it's coming up to 45 mins 2011-08-12 15:59 still no new error, so good going 2011-08-12 16:00 if it completes fine, will be worth the wait ... 2011-08-12 16:00 jivs: like I said, it's been compiling docs (with the same command) for 45 mins! 2011-08-12 16:00 yeah, I'll just let xiangfu dispatch the build server or something 2011-08-12 16:00 like hell I'm compiling these docs again.. 2011-08-12 16:04 <`antonio`> wpwrak, I am following the INSTALL-Ben instructions and applying patches to the kernel but when  I install the kernel in my nanonote I get  "ERROR: Can't get kernel image!". the problem might be that I am using my own image, can I apply those patches directly to the toolchain?   2011-08-12 16:15 <`antonio`> bartbes, got to go now, let me know if you got it working ! 2011-08-12 17:48 bartbes, How did it go? 2011-08-12 17:49 still.. making.. docs.. 2011-08-12 17:49 omg 2011-08-12 17:50 have u found any way to disable that for future! 2011-08-12 17:51 not yet 2011-08-12 17:51 :( 2011-08-12 17:53 I will also start in my toolchain soon. but its not that powerful though... 2011-08-12 17:54 bbiab 2011-08-12 17:56 guild snarf-check-and-output-texi          > guile-procedures.texi || { rm guile-procedures.texi; false; } 2011-08-12 17:56 30425 pts/1    R+   152:41 /bin/sh /media/shared/home/nanonote/openwrt-xburst/build_dir/target-mipsel_uClibc-0.9.32/guile-2.0.2/meta/guile -e (@@ (guild) main) -s /media/shared/home/nanonote/openwrt-xburst/build_dir/target-mipsel_uClibc-0.9.32/guile-2.0.2/meta/guild snarf-check-and-output-texi 2011-08-12 17:56 oh, minus that first line 2011-08-12 18:02 I couldn't help but interrupt 2011-08-12 18:02 this wasn't going to work 2011-08-12 18:07 oh 2011-08-12 18:08 i think there is some patch to disable snarf on guile 1.87, will that help us now? 2011-08-12 18:18 I've always wondered how someone building linux manage the memory it is going to use 2011-08-12 18:18 (user programs apart, of course) 2011-08-12 18:18 Looking for that, I never found the information I wanted. Does anybody here happen to knuw much about that? 2011-08-12 18:18 know 2011-08-12 18:20 it's clear how to compile away code 2011-08-12 18:20 jivs: probably 2011-08-12 18:20 but not-code... how? 2011-08-12 18:20 jivs: I hope so, because my attempt failed 2011-08-12 18:21 i will update you my progress.. 2011-08-12 18:40 jivs: please tell me you've found a way to disable the docs yet 2011-08-12 18:40 bartbes, can u paste the second confiigure_args 2011-08-12 18:41 configure_vars 2011-08-12 18:41 CONFIGURE_VARS += gl_cv_func_duplocale_works=yes guile_cv_use_csqrt="no, Ben NanoNote (cross-compiling)" 2011-08-12 18:42 sorry I don't have that good news yet.. 2011-08-12 18:42 the worst part is that it takes about 10 mins to verify.. 2011-08-12 18:42 did u get this error? :->  i18n.c: In function 'str_upcase_l': 2011-08-12 18:42 i18n.c:874:12: error: dereferencing pointer to incomplete type 2011-08-12 18:45 this error went away after I added 2nd conf_var 2011-08-12 18:45 Did u get this error? :-> bash: -c: line 0: unexpected EOF while looking for matching `"' 2011-08-12 18:45 bash: -c: line 1: syntax error: unexpected end of file 2011-08-12 18:46 paste here plz, bbiab 2011-08-12 18:48 jivs: I never got the second, probably because I patched the first 2011-08-12 19:14 jivs: I almost cracked it 2011-08-12 19:16 whats the error now? 2011-08-12 19:17 I disabled the build rule and it complained about the lack of output 2011-08-12 19:17 so I disabled that expectation too 2011-08-12 19:21 is it compiling now? 2011-08-12 19:21 yeah 2011-08-12 19:22 we'll see how this ends.. 2011-08-12 19:22 if it builds, I'll commit 2011-08-12 19:22 testing can wait 2011-08-12 19:22 I've spent enough time on this.. 2011-08-12 19:23 ok 2011-08-12 19:24 Can you pastebin your Makefile plz. I am still getting that bash: -c error 2011-08-12 19:24 may be sthg wrong with my Makefile.. 2011-08-12 19:25 http://codepad.org/X5NpqBmf 2011-08-12 19:26 I have 3 patches, though 2011-08-12 19:29 I am using 2.0.0 2011-08-12 19:29 let me try with 2.0.2, if anything changes 2011-08-12 19:29 well 2011-08-12 19:29 new result 2011-08-12 19:29 whats it? 2011-08-12 19:29 it's probably not the docs, it's just the guile scripts seem to hang 2011-08-12 19:30 the one that are supposed to execute on the host 2011-08-12 19:30 Do you have the same version of guile on the host? 2011-08-12 19:30 no 2011-08-12 19:30 try updating ti 2.0.2, may be will do some good 2011-08-12 19:31 yeah.. but isn't the target debian? 2011-08-12 19:31 (which contains 1.8.7 afaik) 2011-08-12 19:32 anyway, I'll zip this up 2011-08-12 19:32 i think we have to install from source.. 2011-08-12 19:32 so you can play with it 2011-08-12 19:32 or anyone else who wants to 2011-08-12 19:32 btw what patches do u have for guile 2011-08-12 19:32 i needed ltdl, and unistring patch 2011-08-12 19:33 I also have one for disabling the docs 2011-08-12 19:33 unistring patch? 2011-08-12 19:33 that's not for guile itself, is it? 2011-08-12 19:33 I have one for i18n 2011-08-12 19:34 http://dl.dropbox.com/u/440010/guile.tar.gz 2011-08-12 19:34 i needed to  change the configure.ac where it checks for libunistring... it was complaining in my case