#milkymist IRC log for Monday, 2011-07-25

wolfspraulwpwrak: update via 8:10 is also not really an option, it's way too difficult with the location of the card in the middle of the pcb.03:06
wolfspraulfirst you need to open the case (still don't know whether roh will use philips or allen keys, if he uses allen keys most people may have a harder time finding an allen key then finding an ethernet connector)03:07
wolfspraulthen after you open the case, you need to access the 8:10 connector, which is fiddly and right in the middle of a heavily populated board. I don't want to send people in that direction.03:07
wolfspraulthe ethernet cable imho is the closest thing to 'easy' we have. I think until now most wifi routers have ethernet plugs.03:08
wolfspraulat least whenever I check, they do03:08
wolfspraulso for someone who is 'all wifi' (and I agree many people by now will be living in such a world), the instruction is "go find your router, and plug the cable in there and press the update button"03:09
wolfspraulthat's why we include the ethernet cable in the box as well, for the 'all wifi' folks03:10
wolfspraulthis solution is as good as it gets with m1, today, so I think that's the right thing to do. from here on it can only get better, I am curiously awaiting user feedback...03:10
kristianpaulfollowed by instructions about how to bridge ethernet with wifi for windows, osx and linux, and so then get the update04:04
kristianpaulgo find plug and press, yeah04:05
GitHub162[linux-milkymist] larsclausen pushed 2 new commits to master: https://github.com/milkymist/linux-milkymist/compare/aaa25ab...b6e559f07:09
GitHub162[linux-milkymist/master] lm32: Use "mirco32" as the device tree cpu name - Lars-Peter Clausen07:09
GitHub162[linux-milkymist/master] lm32: Don't modify parent's registers in copy_thread - Lars-Peter Clausen07:09
wolfspraullarsc: in the commitlog you say 'mirco32', in the sources it's 'micro32', but isn't it actually 'mico32'?07:15
larschm, right. thanks07:22
GitHub121[linux-milkymist] larsclausen force-pushed master from b6e559f to 3eb7cd6: https://github.com/milkymist/linux-milkymist/commits/master07:24
GitHub121[linux-milkymist/master] lm32: Use "mico32" as the device tree cpu name - Lars-Peter Clausen07:24
GitHub121[linux-milkymist/master] lm32: Don't modify parent's registers in copy_thread - Lars-Peter Clausen07:24
GitHub121[linux-milkymist/master] lm32: Properly return syscall errors - Lars-Peter Clausen07:24
wpwrakwolfspraul: (update) let's hope then that those wireless cable modems still keep ethernet around ...08:01
wolfspraulwpwrak: yes that's the assumption right now08:03
wolfspraulthey may be removed one day, but for now I think most still have them08:03
wolfsprauland Milkymist is (hopefully) not standing still either, right?08:03
wpwrakwolfspraul: can the ethernet upgrade also update the recovery image ? e.g., if someone were to implement USB storage in the future, could that be made an upgrade choice for devices already in the field ? (without "difficult" things like jtag)08:03
wolfspraulit's just the best possible path I could see right now08:03
wolfspraultheoretically everything can be updated08:04
wolfspraulbut I think we have to be careful to not brick our users devices08:04
wolfspraulI'm actually quite worried how we test and qualify updates08:04
wolfspraulat the very least we must not break the updatability itself08:04
wolfspraulso right now the 'update' is not touching the rescue image, which is good08:04
wolfspraulthe rescue image has nothing to do with whether there is an 'update over usb storage' or not, it's a separate 'level', 'rescue' (i.e. should not normally be needed unless we screw up with the update procedure)08:05
wolfspraulwhich reminds me that I still haven't done any testing of the update feature as it is now, argh08:05
wpwrakwolfspraul: but the possibility exists to update the update image itself without resorting to jtag ? i know that this is a scary thing to do :)08:06
wolfspraulthat's what it does now, I think08:07
wolfspraulthe rescue image is there to help if that 'self update' fails08:07
wolfsprauland beyond the rescue image is jtag08:07
GitHub153[elf2flt-lm32] none pushed 3 new commits to master: https://github.com/milkymist/elf2flt-lm32/compare/1ed805e...3051fec08:07
GitHub153[elf2flt-lm32/master]  - David McCullough08:07
Last message repeated 1 time(s).08:07
GitHub153[elf2flt-lm32/master] Add support for the LatticeMico32 processor - Michael Walle08:07
GitHub142[uclibc-lm32] none pushed 3 new commits to master: https://github.com/milkymist/uclibc-lm32/compare/f87898c...679f42b08:07
GitHub142[uclibc-lm32/master] x86_64/elfinterp.c: Protect missed debug _dl_printf with __SUPPORT_LD_DEBUG__ - Khem Raj08:07
GitHub142[uclibc-lm32/master] ldso: fix build error due to missing variable 'st' - Douglas Mencken08:07
GitHub142[uclibc-lm32/master] lm32: initial LM32 port import - Michael Walle08:07
wpwrakokay, let me use the correct terminology then: can the rescue image update itself ? or can the "normal" image update the rescue image ?08:08
wolfspraulwpwrak: the update right now will download something, flash it, and then boot from whatever it downloaded and flashed ;-)08:08
wolfspraul'can' if implemented08:08
wolfspraulwe have to be careful to implement this in a way that users don't lock themselves out, or don't brick their devices, including the possibility that we publish bad updates, that data gets corrupted while downloading, or whatever unexpected thing happens08:09
wpwrakso there's no special protection of the area that contains the rescue image08:09
wolfsprauldepends on what you think is 'special'08:09
wpwrak(careful) oh yes, certainly08:09
wolfspraulI don't know how the partitions are 'fixed' in software08:10
wolfspraulthere is no physical switch or so, no08:10
wpwrakspecial = beyond software deciding not to do it :)08:10
wolfspraulit's all in nor08:10
wpwrakspecial protection would be like gta02's write-protected boot flash. or the also write-protected boot partition in atusb.08:10
wolfspraulnot there08:11
wpwrakthings you can only change with some "hardware key"08:11
wolfspraulI'm not so worried about that part. I am worried that the software implementation of our download and flash is strong, that we sense sudden disconnects well.08:12
wolfspraulthat we have a strong process on testing and qualifying update images08:12
wolfspraulthat we have good documentation for users how to do the web-update right, or even how to go to the rescue image and recover from there (which will hopefully never be needed)08:13
wolfspraulit's more 'soft' things I'm worried about08:13
wpwrakyeah, that's part of it too. of course, a "fool proof" upgrade procedure also helps. it's reassuring to know that, no matter what bugs may be there, you can never completely brick the device :)08:14
wpwrakthe other end of the extreme are upgrade instructions that are full of "connect power and insert fresh batteries" and "under no circumstance interrupt the upgrade process" ;-)08:15
wolfspraulwe need to distinguish between theoretically and practically 'never bricking' the device08:16
wolfspraultheoretically of course you cannot08:16
wolfspraulworst case you ship it back to us :-)08:16
wolfspraulbut there are many levels in 'unbrickability friendliness' between shipping back to us and pressing a button and waiting 5 minutes08:16
wolfspraulso I try to push it as far as possible towards the 'push a button and wait' unbrickability08:17
wpwrakyeah, i'd say "no escalation" would be a good criterion08:17
wolfsprauleven the jtag path is super hard in my opinion, although the daughterboard is in each m1 still08:17
wolfspraulhave to open the case etc.08:17
wolfsprauland you need a Linux host, you may need to compile urjtag from source, etc.08:17
wpwraki.e., if you use process X to break it, then you can use process X it bring it back, too08:17
wolfspraulcome on, that's all off-limits08:17
wpwrakagrees. jtag is too hard to the average user08:18
wolfspraulfor most people that practically means either a) bricked, drawer or b) ship back to someone who can unbrick it08:18
wpwrakway too hard :)08:18
wolfspraulone day maybe at least urjtag support will be in upstream, I mean the distro08:18
wpwraki'd also try all other options first before touching jtag ;-)08:18
wolfspraulthen it's down to apt-get install, but still - needs a Linux notebook/desktop08:18
wolfsprauljtag on m1 is actually very user friendly, say to someone with your skill level08:19
wolfspraulit's not the broken mess we had on some om devices08:19
wpwrakand probably has a number of interesting failure patterns. i remember rejon's 24 hours fight ;-)08:19
wolfspraulthe only thing missing is that urjtag upstream makes a new release, and that release shows up in Debian/Fedora and offspring08:19
wolfspraulthat was a libusb breakage08:20
wpwraksee :) that's one of these interesting failure patterns08:20
wolfspraulok but at some point you are complaining about the entire foss/distro quality management, which certainly is a subject of its own08:20
wolfspraulwill it ever stabilize??? :-)08:20
wpwrakand it did sort of got halfway through, so it was a puzzling failure08:21
wolfspraulI'm just saying - m1 support is already in urjtag upstream, but since it was added there hasn't been a release yet, and without release it cannot trickle into distros08:21
wpwraknaw, just saying that jtag has too many moving parts, none of which you use very often08:21
wolfspraulreminds me that we have to send them a 1-line patch for the latest spartan-6 stepping we discovered...08:21
wpwrakso you get failured from unfamiliarity, bugs, misunderstood instructions, and so on08:22
wolfspraulwe'are on the same page08:22
wolfspraulto me it's already off-limits because it requires case opening, Linux host, urjtag from source compilation, etc.08:22
wpwrakyeah. plan B, which currently is the only plan, is ethernet08:23
wolfspraulof course, and it will work well08:24
wolfspraulremind to self: test test test08:24
wolfspraula quick update on what Adam is doing now08:26
wpwraksweating ? :)08:26
wolfspraulhe decided to go in bigger batches, that is he will first apply fix2 to 30 or 40 boards, or even more08:26
wolfspraulthe smt shop (MinBo) will deliver the remaining boards today08:26
wolfspraulafter he has applied fix2 to a bigger batch, he will proceed with impedance, boot and reflash testing08:27
wolfspraulafter that we are most likely looking at a big mess of failed boards :-)08:27
wolfspraulhe he08:27
wpwrakadam will have nightmares of being chased by diodes and when trying to escape, tripping over 15 cm wires08:27
wolfsprauland then off to xray08:27
wolfspraulall this work will take several days, we just have to be patient a little08:27
wpwrakdoes he have access to a thermal imaging sensor ?08:28
wpwrakif yes, a quick test would be to take one of the high-current board, power it, then watch where it gets hot08:28
wolfspraulI'm sure even if he had a thermal sensor, he wouldn't want to use this test08:29
wolfspraulit makes no sense08:29
wpwrakit may not even be destructive. or at least not more destructive than what he has already done08:29
wolfspraulwe are trying to get the production under control, that's all about efficiency. so take a whole pack of boards to xray, and do completely non-intrusive searches for the failure points there.08:29
wolfspraulthat was just 1 board, and that's put side. we are trying to manufacture 100% functioning boards with the least amount of work. So that's the focus :-)08:30
wolfspraulnot a thermal imaging sensor test. you want to use this on how many boards? :-)08:30
wpwraksure, checking the SMT fab's work is also good. but we still don't know why even the first board failed08:30
wpwrakyou seem to be assuming it's a widely distributed failure. but it may very well be a single point.08:31
wolfspraulthen we wouldn't be interested in that board at all08:31
wpwrak(imaging) maybe two. plus a regular one first08:31
wpwrakthe single point failure may still be repeated08:32
wolfsprauloh you mean it's the same failure point on all boards? sure, but xray will find that, and by looking at a lot of boards quickly.08:32
wolfspraulwhichever way you turn it, xray is the right approach here, not thermal sensor08:32
wpwrakit may not be easy to see08:32
wpwrakxray is great, but you need to spot the problem08:32
wolfspraulvery easy because that's what the operators of those xray search every day08:32
wpwrakthermal imaging shows you where it is :)08:32
wolfspraulyou should see the xray operator's speed :-)08:33
wolfspraulit's always the same thing, no rocket science. there's a pcb, and solder paste, and connections...08:33
wpwrakwell, let's see how good they are :) if it's just some generally sloppy with, like poor alignment, they ought to find it very quickly08:33
wolfspraulwe already know it's not a design problem, right?08:33
wpwrakif it's something more obscure, they may have a hard time without knowing the circuit better08:34
wolfspraulotherwise we wouldn't have 5 functioning boards now08:34
wolfspraulso if it's not a design problem, then it's a manufacturing problem08:34
wolfspraulwhich means it's an economical problem08:34
wpwrakit could still be a design problem. weird things happening at the edge of tolerances (could be mechanical tolerances)08:34
wolfspraulone way to fix an economical problem is to throw the trouble-makers away and build more08:34
wolfspraulI'm just saying 'one way'08:34
wpwrakor it could be an IQC problem08:34
wolfspraulyes sure08:35
wolfspraulbut all economical08:35
wpwrakmaybe you got a bad batch of FPGAs :)08:35
wolfspraulso the idea of seeing where it gets hot just doesn't make much sense08:35
wolfspraulit's way too destructive, and only gives you visibility into that one board, which you may even damage08:35
wolfspraulthis will only drag you deeper and deeper into economic mess08:35
wpwrakif i had an imaging sensor, the heat test would be the very first thing i'd do ;-)08:35
wpwrakand after a few tries, i'd probably be good enough at it to not burn up too many boards ;-)08:36
wolfspraulI'm sure, sounds like :-)08:36
wolfspraulyou would then probably do it in sequence on all failure boards, because it's so much fun :-)08:36
wpwraknaw, i wouldn't want to kill them all. but i'd want a quick first clue08:37
wolfspraulthe damage has been done, all 90 are produced08:37
wolfspraulsee your are focusing on the wrong thing08:37
wpwrakto see if it's something that can easily be fixed08:37
wpwrake.g., maybe it's an accidental solder bridge08:37
wolfsprauldoesn't matter anymore, we only need to know that before rc408:37
wpwrake.g., because some component it too close to something it shouldn't be08:37
wolfsprauland since we don't start a parallel rc4 effort now, we are under no time pressure to find the root cause08:37
wolfspraulwe can focus on the per-board costs08:37
wolfspraulso xray is just far more efficient08:38
wpwrakwe'll see :)08:38
wolfspraulboth in speed and as a nondestructive way08:38
wolfspraulI think we can rule out that the problems come from applying fix2.08:39
wolfspraulthat would be the only risk we are taking08:39
wpwrakwe'll see ;-)08:39
wpwraki'm not sure if we should hope all your assumptions are right. you're kinda drawing a worst-case scenario :) and in that one, xray may indeed be the only way to go forward. but things may not be so bad.08:40
wolfspraulthe early or late knowledge of 'components too close' makes no difference for rc3 anymore08:40
wpwrakmaybe it's something simple. and once you know what it is, you can spot and fix it.08:40
wolfspraulso now it's about minimizing costs per board that will eventually be fully ok08:40
wolfspraulwpwrak: I understand. but what's the difference of knowing such a 'simple and easy to fix' problem earlier or later, in our current situation?08:41
wpwrakit may save time. xray will be good if the problem is everywhere (e.g., pick and place systematically off or with high tolerances) or if you know where to look. xray is bad if it's something small and you have to look at 1000 similar places first.08:43
wpwrakthermal is likely to know you the path. it doesn't always work, but it often does.08:44
wolfspraulhave you seen an xray search for this type of problem live?08:44
wpwraki don't remember. what i saw were on-site results of a badly placed BGA. that's the kind of thing xray is great for08:45
wolfspraulthe xray search will allow you to quickly roam/fly around the whole board and definitely scan all chips and connections in maybe 5 minutes / board08:47
wolfsprauleven less08:47
wpwrakyes, xray is basically AOI without the automation08:48
wpwrakand better vision :)08:48
wolfspraulit's really fast. you zoom in on a chip, and with contrast etc. you can immediately see the problem connections08:48
wolfspraulthen you zoom out, left, right, zoom in, etc.08:48
wolfspraulall this is very fast08:48
wolfspraulthe key is to do it with a larger batch of boards08:49
wolfspraulat least if access to the xray machine is not just next-door08:49
wpwrakall i'm saying is that visual inspection is often serial. sometimes you're lucky and you spot something that looks wrong immediately. but you can't count on that08:49
wolfsprauleven I could identify the bad connections right away, simply because they look different from the pins next to it08:49
wpwrakand yes, it's good to bring more than one board. also have a few good ones ready, for comparison08:50
wolfspraulyou cannot see a problem inside the chip08:50
wolfspraulbut xray is really the gold standard in terms of verifying that the soldering itself is good08:50
wpwrakit's a very powerful tool, agreed08:52
wpwrakwhen will adam visit the xray shop ?08:52
wolfspraulsounds like Wednesday to me08:53
wolfspraultoday and tomorrow probably full-day fix2 and test08:53
wolfspraulit also needs an appointment there08:53
wolfspraulwpwrak: when the xray results are inconclusive, you will have your field day and the heat testing can start ;-)08:56
Action: wpwrak rubs hands :)08:56
wolfspraulwhich of course - you are right - is possible (that the results are inconclusive)08:57
wpwrakwould be interesting to have a comparison of the two. see how quickly they yield results. and whether they yield the same results ;-)08:57
wolfspraulbut at that point we would have ruled out a major source of smt problems, because we know for sure that the individual solder connections are all good08:58
wpwrakoh course, xray is ideal when it comes to confronting your SMT fab about lousy handywork ;-)08:58
wolfspraulxray is nondestructive and fast, so in this case (right after smt), it's done first08:58
wolfspraulactually you made a good point about AOI08:59
wolfspraulI'm wondering whether you could build an automatic xray aoi and scan each board :-) and since it's not happening (I think) - why not?09:00
wolfspraulmaybe a lot of difficulties with closed chamber (but flow of boards), too slow, too expensive, etc.09:00
wolfsprauland once the smt process is setup right, it will probably only catch very few cases09:01
roh20*3 buttons glued. now i will wait a few minutes and do a fitting test again09:03
wpwrakwolfspraul: maybe the people who'd think it's a good idea and the people who could pull it off just never met :)09:03
rohif all is well i may be able to finish glueing tomorrow09:03
wolfspraulnah. most likely it's simply uneconomical.09:03
lekernelroh, cool :)09:04
lekernelall the other parts are done?09:04
Action: wpwrak wonders of there are production runs where all boards are routinely xray-inspected. e.g., for high-reliability applications09:04
rohlasered, yes.09:04
lekernelok. and no missing parts? (screws, metal sheet, ...)09:04
rohi still need to do final qc, but they are here, and cut/glued/etc09:05
wpwraklekernel: (l48n) that's the fpga pin that drives FLASH_RESET_N. full name is IO_L48N_M1DQ9_1. i abbreviated it to IO_L48N, because i've seen similar names in the neighbourhood09:05
wolfspraulno, sure not. [missing parts]09:05
wolfspraullekernel: the logo is still missing, I am OK with roh just engraving whatever he thinks looks good09:05
rohthe shields need to be cut on some corners (overhanging foil) but thats done fast09:05
wpwraklekernel: i.e., seems that i still don't quite understand the entire usage pattern of that pin09:05
rohthe logo is missing, true.09:05
wolfspraulthe last idea was 'relatively' small and in the corner, top acrylic09:05
lekernelwpwrak, ok. so after power applied, it's hi-Z with internal pull up. after configuration, it's push-pull (but can be turned into anything else by changing the bitstream)09:07
wpwraklekernel: aah, perfect. thanks !09:10
wpwrakupdate: http://downloads.qi-hardware.com/people/werner/m1/rst/rst.ps09:16
wpwrakR60 removed, fixed the right-hand variant, added uQFN variant09:16
awremaining 39pcs is back.09:18
awlabled done and will pick 20pcs among them.09:19
wolfspraulaw: nice!09:19
aw0x30 has been kept rendering 5 days from 7/20 pm3:3009:20
wolfspraulthat's how it should be09:20
wolfspraulnice test!09:20
wolfspraulaw: make it a full week (168 hours), those are good things to talk about if we tested it09:21
wolfspraulnow we are already over 100 hours, not bad ;-)09:21
awwolfspraul, okay09:21
lekernellet's use SOT-23 instead: easier to source and easier to rework10:08
GitHub149[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/f2ff607f60573e2ea4886fd2c70b65467655b26a10:11
GitHub149[milkymist/master] TMU: get simulation to run - Sebastien Bourdeauducq10:11
wpwraklekernel: yeah. should be a LOT easier to rework :) uQFN is 1x1 mm :) do you still prefer the left-hand side ?10:19
lekernelyou can use the AND gate everywhere by the way, just short the two inputs10:19
lekernelah, but no, it's push pull10:20
wpwrakyup. that's the problem10:20
wpwrakactually .. if you want the same chip and don't mind a pull-up on FLASH_RESET_N, then there's another option ...10:21
lekernelor, put a resistor in series10:21
lekernelbetween INIT_B and the output of the AND gate10:22
lekernelthough there might be an internal pull up in the FPGA... oh, well10:22
lekerneluse either the current capacitor based hack or the left part10:22
lekernelperiod :)10:23
wpwraka small series resistor ? ;-) (1k-ish)10:24
wpwrakalright. that should be all then10:34
wpwrakshall i post a summary to the list ?10:34
lekernelyes, if you want :)10:36
wpwrakand hand-fixed the evil arc :)10:37
GitHub158[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/f88e7e5fa51b26a7f9a7315a1f6d01dd5b0245c711:05
GitHub158[milkymist/master] TMU prefetch: fix qpram module - Sebastien Bourdeauducq11:05
GitHub64[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/df38f9108d4933eb2098d246ce3d7e6c89bb8b1f11:37
GitHub64[milkymist/master] TMU prefetch: ack fragment FIFO on datamem resume - Sebastien Bourdeauducq11:37
Alarmhttp://www.milkymist.org/snapshots does not work?11:52
lekernelno, use /updates11:54
GitHub133[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/79679fbe2c6af1560498afccaf82cc875886259911:59
GitHub133[milkymist/master] TMU prefetch: generate datamem busy signal - Sebastien Bourdeauducq11:59
Alarmdid the update of the  card. Question: the mouse is difficult to control. Is there a setting?13:47
lekernelno, there isn't14:23
lekernelif it's very bad, you can use the keyboard shortcuts14:24
lekernelor, of course, you can implement this setting (or fix the bug if there is any)14:25
lekernelhalf the TMU regression tests are passing with prefetching now ... :)14:44
GitHub198[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/09d45f60326196546c71198a80b83ccb92d8bd5c14:50
GitHub198[milkymist/master] TMU prefetch: fix split module - Sebastien Bourdeauducq14:50
lekernelmwalle, the new lm32 works btw15:02
lekernelyay, now rendering with TMU prefetch15:05
lekernelthere are minor bugs, but it works15:05
lekernel25 fps @ 800x600, encouraging15:10
lekernelin 1024x768 it DoS the sdram controller and screen tends to lose sync... hmm15:11
GitHub87[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/7be5065af6f40e5f5f6e7a71e5f897726d5c34f715:17
GitHub87[milkymist/master] TMU prefetch: assert busy during memory burst in texel fetch unit - Sebastien Bourdeauducq15:17
GitHub169[milkymist] sbourdeauducq pushed 1 new commit to hires: https://github.com/milkymist/milkymist/commit/7448aa97225d70b52c4f1454a78906c185753d7715:18
GitHub169[milkymist/hires] Merge branch 'master' into hires - Sebastien Bourdeauducq15:18
GitHub123[linux-milkymist] larsclausen pushed 3 new commits to master: https://github.com/milkymist/linux-milkymist/compare/3eb7cd6...dd0d8d516:32
GitHub123[linux-milkymist/master] lm32: Readd memblock initialization - Lars-Peter Clausen16:32
GitHub123[linux-milkymist/master] lm32: simplify ret_from_fork - Lars-Peter Clausen16:32
GitHub123[linux-milkymist/master] lm32: Fix return value for manage_signal for kernel mode - Lars-Peter Clausen16:32
mwallelarsc: whoops, sorry for the dropped memblock support16:50
mwallewpwrak: imho if you want a unbrickable mmone, you have to have hw write protection, but unfortunately there are both the bitstream and the bootloader image inside the flash, and im only aware of flashes with hw write protection for the first or last sector16:57
larscmwalle: i've moved the start of physical mem address range to 0, i'm not sure if this is correct though16:57
mwallelarsc: from 0x40000000 ?17:01
mwallemh, 0 is flash17:02
wpwrakmwalle: yeah. probably quite difficult to make it truly unbrickable. maybe something for M2 to consider :)17:02
wpwrakmwalle: if all else fails, maybe someone can make a live cd with all the jtag stuff ;-)17:03
larscmwalle: i did this because the default PAGE_OFFSET is defined as CONFIG_KERNEL_RAM_BASE_ADDRESS and the default translation between physical and virtual addresses is to add/subtract PAGE_OFFSET17:06
larsccan i add watchpoints for register values?17:11
mwallelarsc: in real hw? nope17:14
larscin qemu17:14
mwallein qemu neither, iirc :)17:14
larscwell, it at least accepts watch $ra=0x317:14
mwallebut thats just gdb17:15
mwallei cant remember of any code that checks the value of a register every single step17:16
larscit seems to work17:16
larscbut is ultra slow17:16
mwalleah is gdb single stepping? :)17:16
larscmust be17:16
methril_worklarsc, your github repo has the latest MMOne Linux-kernel changes17:18
larscmethril_work: yes17:19
mwallelarsc: default translation in asm-generic?17:20
larscmwalle: yes17:20
larscif wonder if physical memory addresses should be relative to address of memory inside the physical ram, which would be 0, or the address where the ram is mapped in the cpu17:24
mwallethe absolute address17:26
mwallelike the cpu without any translation sees it17:26
larscso we'd set PAGE_OFFSET to 017:29
mwalleCONFIG_KERNEL_RAM_BASE_ADDRESS == 0x40000000 ?17:31
larscthat's what it is set to right now17:31
larschm, setting PAGE_OFFSET to 0 and move the ram region in the dts to 0x40000000 seems to work17:34
Action: mwalle tries to understand the default page.h :)17:35
mwallegit show 5c01b46bb617:37
mwallebbl, dinner17:39
mwallelarsc: btw if KERNEL_RAM_BASE_ADDRESS is really the physical ram base, it cant be a compile time option19:15
Alarms it possible to load the patches by the jtag cable?19:17
mwalleAlarm: nope19:18
mwalleuse network with ftp19:19
Alarms it possible to transfer the patches to the PC by ethernet card Milkymist?19:27
mwalleAlarm: yes19:27
mwallelarsc: mhh unfortunately the linker script needs that address, too :(19:28
lekernelin theory I should be able to tune the thing to make the blue curve flat and always at the initial value20:03
lekernel(x-axis is "difficulty" of the texture mapping operation)20:05
GitHub59[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/64ec8317c8f387fa73512c6622a90492e778673820:06
GitHub59[milkymist/master] tmubench: send data to UART only - Sebastien Bourdeauducq20:06
Alarmis there a wiki page to configure the ftp transfer between the PC and the card?20:22
lekerneljust set login/password in the GUI and the FTP server should work20:28
lekerneljust click "system settings"20:28
Alarmyes but my PC must be FTP server?20:40
mwalleAlarm: no only ftp client20:40
GitHub156[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/9460bd9d1d9338a60a4fce3a5d5e04ce16a7a03e20:56
GitHub156[milkymist/master] TMU: make fragment, fetch and commit FIFO sizes configurable at top level - Sebastien Bourdeauducq20:56
Alarmthe card has an IP address?21:03
GitHub88[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/4939ee31d26ea4ff4a6cd64e23d39f9ebd47789d21:03
GitHub88[milkymist/master] renderer: enlarge texture buffers - Sebastien Bourdeauducq21:03
lekernelAlarm, yes21:03
lekernelif you open the system settings dialog box, you will be able to see and set it21:04
wpwraklekernel: what's the spike on the red curve ?21:04
lekernelexperimental fun?21:06
lekernelactually I don't know. maybe an error or some cache/sdram effect21:07
GitHub110[linux-milkymist] mwalle pushed 5 new commits to master: https://github.com/milkymist/linux-milkymist/compare/dd0d8d5...f77b79421:53
GitHub110[linux-milkymist/master] lm32: undefine KERNEL_RAM_BASE_ADDRESS - Michael Walle21:53
GitHub110[linux-milkymist/master] lm32: remove compiled in kernel command line - Michael Walle21:53
GitHub110[linux-milkymist/master] lm32: use generic scan memory function directly - Michael Walle21:53
--- Tue Jul 26 201100:00

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