#qi-hardware IRC log for Friday, 2011-08-12

qi-bot[commit] Bart van Strien: Add libunistring (master) http://qi-hw.com/p/openwrt-packages/bb2a84c00:01
bartbesthat took way too long00:01
wolfspraulall things worth doing took longer than they should have00:03
wolfspraulxiangfu: reading backlog about flash00:53
wolfspraulso by power cycling, you managed to flip a bit in your nor flash?00:53
xiangfumaybe I am not sure.00:54
wolfspraulunfortunately the rc2 and rc3 boards are different in that area, that complicates our search00:54
xiangfuwerner replied in mailing list. If this is really a NOR corruption and if it is caused by incorrect00:54
xiangfusequencing of power supplies, perhaps power-cycling (instead of the00:54
xiangfureset button) could make it happen more often.00:54
xiangfuI don't know how to narrow down the bug. needs help from Werner and Adam :)00:55
wolfspraulwhat is the reset button? werner means reset in the gui?00:55
xiangfuI think he means press all three buttons for reboot.00:55
xiangfuI am do "replug the dc adapter male plug" for power-cycling00:57
wpwrakxiangfu: (reset button) err yes, whatever button press makes the M1 reset ;-)02:32
wolfspraulok so we have 3 ways to reset:02:34
wpwrakfor 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)02:34
wolfspraul1) cold removal of power supply, either by removing DC jack or by unplugging/switching off the power behind the adapter02:34
wolfspraul2) press three buttons at once for reset02:34
wolfspraul3) power off (or reset) in the gui02:34
wolfspraulso actually it's 5 ways02:34
wolfspraul1) unplug DC jack02:34
wolfspraul2) unplug power supply itself from mains02:35
wolfspraul3) press three buttons02:35
wolfspraul4) 'reset' in gui02:35
wolfspraul5) 'power off' in gui02:35
qi-botThe build has FAILED, see log here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-08112011-0046/02:35
kristianpaulbartbes: 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 packaging02:37
wolfspraulwpwrak: 10 corruption events!!! :-)02:43
wolfspraulyou will drive everybody to heart attack. This event is relatively rare, don't forget.02:43
wolfspraulif adam sets 38 boards to 'available', that's 380 full power to render cycles without any such occurance.02:43
wolfsprauland maybe 3-5 boards did show the problem in between02:43
wolfspraulso maybe 1-2 times per 100 power cycles02:43
wolfspraulif you look at it that way02:43
wolfspraulbut right now we know too little02:43
wolfspraulnot just 'power cycle', actually it's a full rendering cycle with boot-to-render and then let it render for 30 seconds02:43
wpwraki 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 controllable02:43
wpwrakxiangfu: btw, after flashing, are the partitions write-protected again ?02:43
wpwrak(10 events) yeah, but otherwise you don't know how long you have to test to be reasonably sure you've nailed it :)02:44
wpwrak100 events would of course be better ;-)02:45
wpwrakthe 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 corruptions02:47
xiangfuwpwrak, (write protected) hmm... I use urjtag flash them. there is now write-protect like command in urjtag02:47
xiangfuwpwrak, the flash output is like unlock... flashing... unlock... flashing... 02:48
xiangfuwpwrak, how this write-protect works?02:49
wpwraklemme check ... there are many different ways how NOR chips do this02:49
aw_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 pass02:49
aw_please don't ask me do some tests now....  i just posted here if i found interesting. ;-)02:50
wolfspraulaw_: what's interesting about 0x7F ?02:52
wolfspraul0x7F passes all tests now?02:52
wpwrakpage 28. "Configurable Block Locking" ... " For additional information and collateral request, please contact your filed representative ." haha, very funny02:53
aw_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. ;-)02:53
aw_now it's all passed except 8:10 which i forgot to insert card. ;-) do rendering next. :)02:55
wolfspraulnot sure whether that's related to the flash problems02:55
wpwrakxiangfu: 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 locked02:55
wolfspraulbut that's why you go through the entire batch now, so that we can then see the flash problem more clearly02:55
kristianpaul(locking) good, now i can finally call that nor chip rom :)02:56
wolfspraulxiangfu: when your board couldn't boot anymore because standby was corrupted (maybe), was the rescue boot still working?02:57
wpwrakkristianpaul: 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 ?02:57
xiangfuwpwrak, thanks. so there are some addition area for store the block lock info?02:58
kristianpaulwpwrak: actually sebastien idea is that, for a writable FS  memory card have a job :)02:58
aw_hmm...0x7f: bad that can't configure after powered-cyle. :(02:58
kristianpaulwpwrak: pathces can be loaded from memcard02:58
xiangfuwpwrak, (rescue stuff shoudl be locked) yes.02:58
kristianpaulwpwrak: store, i think user and pass for ftp, dunno what else i lost the track to flickerinose02:59
wolfspraulaw_: wait02:59
wolfspraulso you just reflashed 0x7f, successfully (according to flash script)02:59
wolfspraulthen you ran the test software that was loaded over serial, and it succeeded02:59
aw_wolfspraul, no reflash 03:00
wpwraksection 10.4 is funny. a "password access", some 64 bits string. as if that accomplished much ;-))03:00
wolfspraulnow you try to power cycle but it won't boot?03:00
wolfspraulhow did you power cycle?03:00
wolfsprauland how does it stop? d2/d3 dimly lit?03:00
aw_it successed. so I inserted 8:10 card then powered on ...and d2 is dimly lit though. :(03:00
kristianpaulwpwrak: (password) so murphy cant guess that one :)03:00
aw_i unplugged the dc jack's plug03:01
aw_and replugged it03:01
wolfspraulis 'd2 dimly lit' the same as the nor flash corruption or a separate bug?03:01
wpwrakkristianpaul: naw, i think it's meant as a means to protect confidential content. now, how hard would it to record that bit string ? :)03:01
kristianpaulhum yes03:02
aw_seems once it had have d2/d3 dimly lit  after first flash, it will be easily show d2 dimly lit once power on03:02
wpwrakxiangfu: (lock) in the NOR data sheet, sections 6.1 and 6.2. it should be very similar to the unlocking operation03:03
aw_well..records firstly then continue other boards.03:03
wolfspraulwasn't the reset circuit meant to fix the 'd2 dimly lit' problem?03:04
wpwrakwasn't it reset -> fix NOR corruption and NOR corruption -> "d2 dimly lit" ?03:04
wolfspraulunfortunately that's what we will only really learn and understand right now in the middle of the rc3 run ;-)03:05
wpwrakso i think we have some evidence that the reset circuit in its present state isn't sufficient to make NOR corruption go away03:05
wolfspraulthe 'd2 dimly lit' problem I knew about went after after power cycling again03:06
wpwrak(evidence) at least xiangfu's M1rc2 seems to suffer real NOR corruption. we haven't properly established that on an M1rc3 yet, though03:06
wolfspraulaw_: can you try to power cycle 0x7F three times?03:07
wpwrakah, interesting. thought that was also the symptom of bad NOR03:07
aw_wolfspraul, ok03:07
wolfspraulmany m1 rc2 users have found workarounds for power cycle/boot problems for themselves03:07
wolfspraulthat complicates our analysis now03:08
xiangfuwpwrak, I only find the unlock code in urjtag. not found the lock code. 03:08
xiangfuwpwrak, let me find the source code url.03:09
aw_wolfspraul, all d2 dimly lit now in three times powered-cycle.03:09
wolfspraulthe data they report is biased because of their workarounds. so we need to try to remove that now.03:09
wolfspraulaw_: he :-) try another 3 times, wait 5 seconds in between.03:09
wpwrakxiangfu: 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 locking03:09
wpwrakxiangfu: http://www.micron.com/get-document/?documentId=6062&file=319942_J3_65_256M_MLC_DS.pdf03:09
aw_wolfspraul, already stays 5 seconds in between.03:10
wpwrakxiangfu: pages 18 to 2003:10
wolfspraulcan you lock each page separately?03:10
wolfsprauland the locking is stored in the nor as well?03:10
wpwrakwolfspraul: correct (2x)03:10
wolfspraulaw_: yes just try another 3 times, to be sure03:10
wolfspraulif it is so persistent, it's definitely not the 'd2 dimly lit' problem I know from my rc203:11
wpwrakwolfspraul: well, each block. NOT doesn't have pages :)03:11
wolfsprauland our partitions end in full blocks?03:11
wpwrakxiangfu ?03:11
xiangfuwpwrak, yes. end in full blocks03:12
xiangfuwpwrak, 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=HEAD03:13
aw_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. ;-)03:14
wolfspraulmove it aside03:14
wolfspraula proper (!) flash corruption will not fix itself03:14
wolfspraulso it should not come back even after several days, which it sometimes does03:15
wolfspraulso I think there are several different problems here, masking each other partially03:15
wolfspraulaw_: just continue with the full round, then we look at all data carefully03:15
aw_wolfspraul, yes03:16
wolfspraulok so right now, we are not locking anything in the nor flash03:16
wpwrakxiangfu: you can probably just copy the unlock functions, change UNLOCK_BLOCK to LOCK_BLOCK, and you're done03:16
wolfspraulbut werner proposes to look several parts like rescue bitstream and maybe more03:16
kristianpaul(fix itself) so bus corruption? fpga..  a 20Ghz scope near? ;)03:16
wpwrakxiangfu: well, plus calling them ;-)03:16
wolfspraulif we lock anything, my thoughts would be: a) how does that impact the ability for web updates or other updates03:17
wpwrakis the NOR mapped in the LM32's memory address space ?03:18
wolfspraulb) are we just covering up the real bug behind a lock (even if effective), or is this a proper fix still?03:18
wolfsprauljust my thoughts, nothing else03:18
wpwrakjust an extra protection03:18
wpwrakso you shouldn't set the locks when hunting the corruption03:18
wolfsprauland the locks need to be removed for updates03:19
kristianpaulwpwrak: yes is mapped03:19
wpwrakthen not locking those things borders on insanity ;-)03:19
wolfspraulI don't think the "power-to-render cycles leading to unreconfigurable board" is related to anything the fpga does during rendering03:20
wpwrakconsidering that there's not even an MMU. any little sw bug can corrupt your NOR :)03:20
wolfspraulthat's because we see this problem regularly when doing sets of 10 power cycles with 30 second rendering sprints03:20
wolfspraulbut I never once have heard from it after a multi-hour rendering03:21
wolfspraulthat's a very weak logic, but still03:21
wolfspraulit could be that long renderings are rare, and we are not focusing enough on this problem03:21
wolfspraulthat's not to say that an unlocked memory mapped NOR is insane03:21
wpwrakwolfspraul: (ability to update) the update process would have to unlock before writing, then lock again. should be no problem.03:22
wolfspraulwelcome to m1 :-)03:22
wolfspraulbut that needs to be added03:22
wolfspraulthere are two risks in start selling rc3 now, basically signing off boards to leave Taipei03:22
kristianpaulwpwrak: okay that another reason for a MMU, i think now i get more sense to me have one :)03:22
wolfspraulthe first risk is that the hardware is physically in a state that requires a fix later (a hardware fix)03:22
wolfspraulthe 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 unbricking03:23
wpwrak(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 be03:24
wpwrakwolfspraul: 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 corruption03:25
wpwrakjust in recoverable partitions. e.g., the one where all the patches for your show tonight are :)03:25
wolfspraulthat's exactly how I see it too03:25
wolfspraula lot of work ;-)03:26
wolfsprauloh the units are not 'production ready' in its current state03:26
wpwrakthe 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 easily03:27
wolfspraulsince the normal (web) update does not update the rescue stuff, it would be a relatively easy next step to lock all rescue partitions03:27
wolfspraulxiangfu: 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 ?03:27
wolfspraulI don't see the downside to that right now03:28
xiangfuwolfspraul, ye. lock all rescue part partitions should be ok.03:28
wolfspraulhow many partitions is that?03:29
wolfspraulI still don't have a mental map of all our partitions03:29
wpwrakto corrupt the NOR, this should do nicely: volatile uint32_t *p = (void *) 0xSOMEWHERE; *p = 0x40; *p = 0;03:29
xiangfuwpwrak, how can I test if the lock is correct. write some thing to this area then readback. will different. right?03:29
wolfsprauljust lock then be happy03:29
xiangfui mean make sure the code is do lock correct. 03:30
wolfspraulsure, I was joking03:30
wpwrakyou could use the code snippet from above. if the lock works, then it won't be able to zero the word in question. else, ... :)03:30
xiangfuwolfspraul, http://www.milkymist.org/wiki/index.php?title=Flashing_the_Milkymist_One#Flash_Memory_Distribution03:30
xiangfuwolfspraul, all rescue + standby. so 5 partitions03:30
wolfspraulxiangfu: the standby bitstream is needed by the rescue boot path?03:32
xiangfuit will goto standby after you plug the power.03:32
wolfspraulso it's always needed, even in rescue mode?03:33
xiangfuyes. 03:33
wolfspraulis the standby bitstream updated by the web update?03:33
wolfspraulthen it should probably be locked as well03:34
wpwrakxiangfu: 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.03:34
xiangfuif I understand correct. when plug power. fpga will load standby immediately, for enable the power button. reboot button. etc.03:34
wpwrakxiangfu: then you can retrieve the lock bit, see page 22, table 903:34
wolfspraulah yes, you said that already03:34
wolfspraulin total lock 5 partitions03:34
wolfspraulbtw, 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 more03:35
wpwrakprobably lock more than 5. the regular bitstream for sure. then, does FN normally need to write to BIOS, splash, APP ? or only to Data ?03:37
wpwraki 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.03:38
wpwrakyou may want to ask numonyx for clarification, though03:39
xiangfuwpwrak, (read device Information command) yes.03:39
wpwrakwolfspraul: 0 is a very common word value :)03:39
wolfspraulbut only 1 bit was changed03:40
wpwrakwolfspraul: remember that the transition was 0x1000 -> 0x000003:40
wpwrakwolfspraul: yes, there was only one "1" bit there to destroy :)03:40
xiangfumore diff: http://dpaste.com/592480/03:40
wolfspraulif 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 problem03:40
wolfspraulhmm, true03:41
wpwrakxiangfu: hmm, does that mean that everything after 0078dd0 is 0 ? or that the file ended at 0078dd0 ?03:42
xiangfualso we maybe needs erase all NOR flash before flash .03:42
xiangfuwpwrak, the origin file is only 495060 length. so it end at 0078dd003:43
xiangfuwpwrak, when I read back the standy , I read whole 640KB from m1. so it end at 00a000003:43
wpwrakxiangfu: ah, so the stuff at the end is a retrieval artefact03:43
wolfspraulxiangfu: yes erase all sounds good. we don't do that now?03:44
wolfspraulhow fast/slow would it be?03:45
xiangfuerase very fast.03:45
xiangfuacceptable 03:45
wpwrakyou probably erase each block before writing it. that may or may not be sufficient. depends a bit on what the software expects.03:45
wolfspraulin a perfect world we should not need the erase, I guess03:46
wpwraki think you do03:46
wpwrakerase: 0/1 -> 1. write: 1 -> 003:46
xiangfuwhen flash we do need erase.03:46
wpwrakwell, write: 0/1 -> 003:46
xiangfusee the http://dpaste.com/592480/ line 16.03:47
xiangfuit maybe because the last standby.bin is small then the previous one03:47
xiangfuerase all nor flash can make all those bit to '1' :)03:48
wpwrakxiangfu: 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 :)03:49
wpwrakxiangfu: so something is writing a bit of extra data that's not in the file03:49
xiangfuwpwrak, (forget the block size). yes. something is writing a bit of extra data.03:50
wpwrakone more for the bug pile ;-)03:50
xiangfuthen that is a bug in urjtag03:50
xiangfuyes. 03:50
wpwrakyeah, probably urjtag03:51
xiangfuI can read more partition and compare .03:51
xiangfusee if this happen in other partitions.03:51
wpwrakmaybe some  for (i = 0; i <= n; i++) program_word(i);   :)03:51
kristianpaulfake a file witha now patter03:54
kristianpaulwrite it read back03:54
kristianpaulcomapre :)03:54
wpwrakthen change the size and repeat. dd if=/dev/urandom  is your friend :)03:54
wolfspraulbugs everywhere. sigh. but I need to decide whether we can start selling 'good' rc3 boards or not ;-003:59
wolfspraulat least we have _lots_ of good starting points04:01
wolfsprauldo we have consensus that we should add a full 32 megabytes erase to reflash_m1.sh ?04:06
kristianpaulat least will help to track corupt yes ;)04:07
wolfspraulxiangfu: is Adam using reflash_m1.sh or reflash_all.batch ?04:09
wolfspraulis this up-to-date? http://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule#Flash_Test_Tool_Image04:11
aw_wolfspraul xiangfu , i used reflash_m1.sh not reflash_all.batch04:13
kristianpauleven is memory mapped i cant get to write as easy as it could sound..04:13
kristianpaulbut yes i can read04:13
wolfspraulok we should update the wiki instructions, also the wiki points to a commit etc - quite confusing04:14
wolfspraulI mean for the test software image04:14
wolfspraulaw_: don't worry, you focus on the boards Xiangfu is working on the tools :-)04:15
wolfspraul42 'available' now, not bad04:16
aw_wolfspraul, good. i just used his xiangfu's last email in private last time though. not sure if already existed on public server.04:17
kristianpaulsell sell ! _)04:17
wolfspraulgrowing :-)04:17
aw_xiangfu, http://pastebin.com/cAcWHGBN04:17
wolfspraulwell, 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.04:17
aw_alright then ..i go lunch firstly then back to rework on usb.04:18
kristianpaul(update) yeah, lots of usefull scripts now04:22
wolfspraulxiangfu: alright, so Adam uses reflash_m1.sh04:26
wolfspraulshould we add a full 32 megabytes erase to reflash_m1.sh ?04:27
kristianpaullol my LG remote now generates ramdon data on flickernoise :)04:28
wolfspraulyes I've seen that as well04:29
xiangfuat least we can make sure all non-used area is '1'04:29
xiangfukristianpaul, it is a test screen. 04:29
xiangfukristianpaul, wait input from serial console. 'b' is for 'boot'04:29
wolfspraulI'm just asking what the consensus now is?04:30
kristianpaulxiangfu: boot for?04:30
wolfspraulwe already said we want to lock 5 partitions (standby+rescue)04:30
wolfspraulthat's clear04:30
xiangfuboot to flickernoise. normal boot04:30
kristianpaulah, sure  running it now :)04:30
kristianpauli could not resist04:30
kristianpaulit work out of the box !04:30
xiangfukristianpaul, there is a help message output from serial console. that can test screen. 04:31
kristianpaulbit slow bott.. but well :)04:31
wolfspraulhow about adding nor erase, don't know04:31
wolfspraulmaybe a good idea to establish a baseline04:31
wolfspraulalso because we have so many uncertainties in the tools, jtag, cable, signal integrity, etc. etc.04:31
wolfspraulseems like uncertainties everywhere04:31
wolfspraulso if we add some more baselines, even if they are theoretically unnecessary, it could help pull some of the other uncertainties apart04:32
kristianpaulokay i'll sleep now but let mm1 rendering whole nigh !04:32
wolfspraulthat's why I was thinking maybe reflash_m1.sh, at least when it reflashs all partitions, should start with a full 32 megabytes erase04:32
kristianpaulwill be nice as temp will drop to 19°C (28°C now)04:33
kristianpaulbtw a knowlesdge base for know workarounds is not bad ;)04:37
kristianpaulto have, i think04:38
wolfspraulnot so easy04:38
wolfspraultoo few users, too many bugs04:38
wolfspraulthe beginning is difficult, and that's what we go through now04:39
wolfspraulwith good will and a little patience, we'll make it04:39
kristianpaul(users) true, no worth effort yet04:40
xiangfuwiki 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 04:40
xiangfuupdate a little. 04:40
xiangfushould be more clear then before. delete out-data script.  we only use one in RC3.04:41
wpwrakwolfspraul: (full erase) doesn't seem necessary05:13
ignatius-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?05:27
xiangfuaw_, Hi 08:26
xiangfuhttp://milkymist.org/updates/current/for-rc3/reflash_m1.sh. I update the reflash_m1.sh, erase the whole nor flash before write anything.08:26
aw_xiangfu, hi yes08:26
xiangfuaw_, you can use new one(__VERSION__="2011-08-12") from now on.08:27
aw_xiangfu, okay.great 08:27
aw_xiangfu, just directly use this 08-12 script only, right? no else image file attached?08:29
xiangfuaw_, no needs touch any other files. just this 08-12 script.08:30
aw_xiangfu, okay..I'll mark note on those rest boards's record, so i know which board is done by erase. thanks.08:32
xiangfuaw_, your reflash log is enough. yes. you can mark note on boards08:32
xiangfuaw_, the  reflash_m1.sh output will be different08:34
aw_xiangfu, okay..I'll watch it..now still reworking. :)08:36
xiangfuaw_, sorry. I upload a new one. if you already download, download again. just output the VERSION before it start flash. 08:39
aw_xiangfu, alright. ;-)08:40
`antonio`bartbes, hi, did you manage to compile  guile 2.0 10:41
bartbes`antonio`: still working on it, I just found another dependency10:41
bartbeswhich was delayed because that project's hosting went down for a bit10:42
bartbesit's back up again, so that's building now10:42
`antonio`how is it going then ?10:44
`antonio` i a trying to build guile 2.0 as well10:44
`antonio` but i'm having some problems10:44
bartbesmore dependencies, woo10:46
jivsbartbes, did u compile libunistring successfully?10:47
jivsany patch required?10:47
bartbesit's in the repo already10:48
jivsis it uclibc related?10:48
jivsok cool, we had the same issue, patched it. but later we had some other errors related to locale10:49
bartbesI can only hope I didn't break it10:50
bartbestime will tell10:50
`antonio`guile 2.0 have some problems in the future with locale10:50
`antonio`bartbes, did you create any patch for guile 2.0 ?10:51
bartbesjivs: if it is, indeed broken, I will see if I can work around, i.e. add some UCLIBC code10:51
bartbesI had to exchange a faulty configure.ac line, so far10:51
jivswe patched it this way, may be it was not right.: #  if __GLIBC__ >= 210:51
jivs+#  if __GLIBC__ >= 2  && !defined __UCLIBC__10:51
bartbesdo note that I have yet to get it to actually get to compiling10:52
bartbesfinally, configure finished10:53
bartbesnow, we'll see what happens10:53
bartbes.. yeah10:53
`antonio`bartbes, yeh we passed configure 10:53
bartbesthat failed10:53
`antonio`pastebin it 10:53
bartbesduplocal makes pointer from integer10:55
`antonio`that's fine i solved that10:55
bartbesdo tell10:55
`antonio`I hope that's the proper way of doing it: 10:56
`antonio`basically in the guile make file add the CONFIGURE_ARGS10:56
`antonio`CONFIGURE_ARGS += -C10:57
`antonio`and do make package/guile/{clean,compile} V=9910:57
bartbes"  -C, --config-cache      alias for `--cache-file=config.cache'"?10:57
bartbeshmm right10:58
`antonio`in the config.cache 10:58
`antonio`basically is failing because we need to set some proper variables10:58
`antonio`i'll give you the line in a sec10:58
bartbesit's already recompiling10:59
`antonio`do clean,prepare then10:59
`antonio`don't let it pass the configuring otherview it will not go through the config.cache10:59
`antonio`in the config.cache search for duplocale  and there is something like this 11:00
`antonio`gl_cv_func_duplocale_works=${gl_cv_func_duplocale_works='guessing no'}11:00
`antonio`change no to yes11:00
`antonio` and it will pass that error11:00
bartbesthen.. this sounds like a very hacky solution11:00
bartbesthe thing is, I know it doesn't work11:00
`antonio`this is a temporary solution11:00
bartbesbecause I believe it is the function I nerfed11:01
jivsbartbes, do u think this error might be related with libunistring in some way?11:05
bartbesI would expect that, yes11:05
bartbesit is a different function11:08
`antonio`which one?11:18
jow_laptop`antonio`: the proper way to override that (within an OpenWrt makefile) is  CONFIGURE_VARS += gl_cv_func_duplocale_works=yes11:18
jow_laptopno need to edit a config.cache11:18
`antonio`jow_laptop: nice, thanks11:19
jow_laptopthe configure should then output something like  "Checking for foo ... yes (cached)"11:19
jivsjow_laptop, thanks11:19
bartbesis there a MAKE_ARGS thing too?11:22
bartbesjow_laptop: ah, cool11:22
jow_laptopbartbes: yes11:23
bartbesI was going to override it at a later point, during make, but this probably works11:24
jow_laptopthere is  MAKE_VARS  which overrides the environment (e.g.  FOO=bar make ...)11:24
jow_laptopand  MAKE_FLAGS  which extends the args (e.g.  make FOO=bar)11:25
bartbesright, so if it doesn't work I can play with MAKE_FLAGS, thanks11:25
jow_laptopjust be sure to always append (+=) to those vars since they already contain a bunch of default overrides and variables11:26
bartbes`antonio`: I managed to get it down to a link error14:56
bartbesupdating the old patch should fix that14:56
`antonio`can you paste bin it14:57
jivscool bartbes 14:57
bartbesalso time to take out all my desperate attempts14:57
bartbesit's just the csqrt one14:58
bartbesalso, do you know what this 'issue with threads' is?14:59
jivscsqrt, is it similar to the guile1.8.7 patch14:59
bartbesso easy14:59
jivsthere is a patch for that already on 1.8.7, hopefully it will work 15:00
bartbesno need to15:01
bartbesI know what it does15:01
bartbesso I can just replicate it15:01
bartbesI guess I might as well start working on become the richest man in the world15:01
bartbesbecause that will finish sooner than this compile15:01
jivsso can be solved using configure_vars from Makefile. isn't it?15:02
`antonio`bartbes, how long it takes in your machine ?15:02
bartbesjivs: that's what I tried15:02
bartbes`antonio`: not as long as I made it out to be, but 10 mins, I guess15:04
bartbesif this build fails I'll time it for you15:04
bartbes(hoping it doesn't, though)15:04
jivslets be optimistic :-)15:05
bartbeswell, you know, I'm undoing my desperate measures15:06
bartbesso it might very well happen15:06
bartbes`antonio`: well, 10 minutes seems like a good estimate for the source to compile15:21
bartbesit's been chewing through docs for a while now, though15:21
bartbesstupid texinfo manuals..15:21
`antonio`so successfully completed ?15:22
`antonio`bartbes, then you'r almost there 15:25
bartbesit's still creating manuals15:32
bartbesI'm going to have to see if there's an option to turn that off15:32
bartbes`antonio`: progress update: still compiling texinfo manuals15:58
bartbesnot a fun activity15:58
`antonio`what processor do yo have?15:58
bartbesit's compiling on an old p415:59
bartbesbut still, it's coming up to 45 mins15:59
jivsstill no new error, so good going15:59
jivsif it completes fine, will be worth the wait ...16:00
bartbesjivs: like I said, it's been compiling docs (with the same command) for 45 mins!16:00
bartbesyeah, I'll just let xiangfu dispatch the build server or something16:00
bartbeslike hell I'm compiling these docs again..16:00
`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?  16:04
`antonio`bartbes, got to go now, let me know if you got it working !16:15
jivsbartbes, How did it go?17:48
bartbesstill.. making.. docs..17:49
jivshave u found any way to disable that for future!17:50
bartbesnot yet17:51
jivsI will also start in my toolchain soon. but its not that powerful though...17:53
bartbes guild snarf-check-and-output-texi          > guile-procedures.texi || { rm guile-procedures.texi; false; }17:56
bartbes30425 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-texi17:56
bartbesoh, minus that first line17:56
bartbesI couldn't help but interrupt18:02
bartbesthis wasn't going to work18:02
jivsi think there is some patch to disable snarf on guile 1.87, will that help us now?18:08
viricI've always wondered how someone building linux manage the memory it is going to use18:18
viric(user programs apart, of course)18:18
viricLooking for that, I never found the information I wanted. Does anybody here happen to knuw much about that?18:18
viricit's clear how to compile away code18:20
bartbesjivs: probably18:20
viricbut not-code... how?18:20
bartbesjivs: I hope so, because my attempt failed18:20
jivsi will update you my progress..18:21
bartbesjivs: please tell me you've found a way to disable the docs yet18:40
jivsbartbes, can u paste the second confiigure_args 18:40
bartbesCONFIGURE_VARS += gl_cv_func_duplocale_works=yes guile_cv_use_csqrt="no, Ben NanoNote (cross-compiling)"18:41
jivssorry I don't have that good news yet..18:42
bartbesthe worst part is that it takes about 10 mins to verify..18:42
jivsdid u get this error? :->  i18n.c: In function 'str_upcase_l':18:42
jivsi18n.c:874:12: error: dereferencing pointer to incomplete type18:42
jivsthis error went away after I added 2nd conf_var18:45
jivsDid u get this error? :-> bash: -c: line 0: unexpected EOF while looking for matching `"'18:45
jivsbash: -c: line 1: syntax error: unexpected end of file18:45
jivspaste here plz, bbiab18:46
bartbesjivs: I never got the second, probably because I patched the first18:48
bartbesjivs: I almost cracked it19:14
jivswhats the error now?19:16
bartbesI disabled the build rule and it complained about the lack of output19:17
bartbesso I disabled that expectation too19:17
jivsis it compiling now?19:21
bartbeswe'll see how this ends..19:22
bartbesif it builds, I'll commit19:22
bartbestesting can wait19:22
bartbesI've spent enough time on this..19:22
jivsCan you pastebin your Makefile plz. I am still getting that bash: -c error19:24
jivsmay be sthg wrong with my Makefile..19:24
bartbesI have 3 patches, though19:26
jivsI am using 2.0.0 19:29
jivslet me try with 2.0.2, if anything changes19:29
bartbesnew result19:29
jivswhats it?19:29
bartbesit's probably not the docs, it's just the guile scripts seem to hang19:29
bartbesthe one that are supposed to execute on the host19:30
jivsDo you have the same version of guile on the host?19:30
jivstry updating ti 2.0.2, may be will do some good19:30
bartbesyeah.. but isn't the target debian?19:31
bartbes(which contains 1.8.7 afaik)19:31
bartbesanyway, I'll zip this up19:32
jivsi think we have to install from source..19:32
bartbesso you can play with it19:32
bartbesor anyone else who wants to19:32
jivsbtw what patches do u have for guile19:32
jivsi needed ltdl, and unistring patch19:32
bartbesI also have one for disabling the docs19:33
bartbesunistring patch?19:33
bartbesthat's not for guile itself, is it?19:33
bartbesI have one for i18n19:33
jivsi needed to  change the configure.ac where it checks for libunistring... it was complaining in my case19:34
--- Sat Aug 13 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!