<wolfspraul> wpwrak: 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.
<wolfspraul> first 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)
<wolfspraul> then 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.
<wolfspraul> the ethernet cable imho is the closest thing to 'easy' we have. I think until now most wifi routers have ethernet plugs.
<wolfspraul> at least whenever I check, they do
<wolfspraul> so 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"
<wolfspraul> that's why we include the ethernet cable in the box as well, for the 'all wifi' folks
<wolfspraul> this 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...
<kristianpaul> followed by instructions about how to bridge ethernet with wifi for windows, osx and linux, and so then get the update
<kristianpaul> go find plug and press, yeah
<GitHub162> [linux-milkymist] larsclausen pushed 2 new commits to master: https://github.com/milkymist/linux-milkymist/compare/aaa25ab...b6e559f
<GitHub162> [linux-milkymist/master] lm32: Use "mirco32" as the device tree cpu name - Lars-Peter Clausen
<GitHub162> [linux-milkymist/master] lm32: Don't modify parent's registers in copy_thread - Lars-Peter Clausen
<wolfspraul> larsc: in the commitlog you say 'mirco32', in the sources it's 'micro32', but isn't it actually 'mico32'?
<larsc> hm, right. thanks
<GitHub121> [linux-milkymist] larsclausen force-pushed master from b6e559f to 3eb7cd6: https://github.com/milkymist/linux-milkymist/commits/master
<GitHub121> [linux-milkymist/master] lm32: Use "mico32" as the device tree cpu name - Lars-Peter Clausen
<GitHub121> [linux-milkymist/master] lm32: Don't modify parent's registers in copy_thread - Lars-Peter Clausen
<GitHub121> [linux-milkymist/master] lm32: Properly return syscall errors - Lars-Peter Clausen
<wpwrak> wolfspraul: (update) let's hope then that those wireless cable modems still keep ethernet around ...
<wolfspraul> wpwrak: yes that's the assumption right now
<wolfspraul> they may be removed one day, but for now I think most still have them
<wolfspraul> and Milkymist is (hopefully) not standing still either, right?
<wpwrak> wolfspraul: 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)
<wolfspraul> it's just the best possible path I could see right now
<wolfspraul> theoretically everything can be updated
<wolfspraul> but I think we have to be careful to not brick our users devices
<wolfspraul> I'm actually quite worried how we test and qualify updates
<wolfspraul> at the very least we must not break the updatability itself
<wolfspraul> so right now the 'update' is not touching the rescue image, which is good
<wolfspraul> the 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)
<wolfspraul> which reminds me that I still haven't done any testing of the update feature as it is now, argh
<wolfspraul> :-)
<wpwrak> wolfspraul: but the possibility exists to update the update image itself without resorting to jtag ? i know that this is a scary thing to do :)
<wolfspraul> that's what it does now, I think
<wolfspraul> the rescue image is there to help if that 'self update' fails
<wolfspraul> and beyond the rescue image is jtag
<GitHub153> [elf2flt-lm32] none pushed 3 new commits to master: https://github.com/milkymist/elf2flt-lm32/compare/1ed805e...3051fec
<GitHub153> [elf2flt-lm32/master]  - David McCullough
<GitHub153> [elf2flt-lm32/master] Add support for the LatticeMico32 processor - Michael Walle
<GitHub142> [uclibc-lm32] none pushed 3 new commits to master: https://github.com/milkymist/uclibc-lm32/compare/f87898c...679f42b
<GitHub142> [uclibc-lm32/master] x86_64/elfinterp.c: Protect missed debug _dl_printf with __SUPPORT_LD_DEBUG__ - Khem Raj
<GitHub142> [uclibc-lm32/master] ldso: fix build error due to missing variable 'st' - Douglas Mencken
<GitHub142> [uclibc-lm32/master] lm32: initial LM32 port import - Michael Walle
<wpwrak> okay, let me use the correct terminology then: can the rescue image update itself ? or can the "normal" image update the rescue image ?
<wolfspraul> wpwrak: the update right now will download something, flash it, and then boot from whatever it downloaded and flashed ;-)
<wolfspraul> both
<wolfspraul> 'can' if implemented
<wolfspraul> we 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 happens
<wpwrak> so there's no special protection of the area that contains the rescue image
<wolfspraul> depends on what you think is 'special'
<wpwrak> (careful) oh yes, certainly
<wolfspraul> I don't know how the partitions are 'fixed' in software
<wolfspraul> there is no physical switch or so, no
<wpwrak> special = beyond software deciding not to do it :)
<wolfspraul> it's all in nor
<wpwrak> special protection would be like gta02's write-protected boot flash. or the also write-protected boot partition in atusb.
<wolfspraul> not there
<wpwrak> things you can only change with some "hardware key"
<wpwrak> okay
<wolfspraul> I'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.
<wolfspraul> that we have a strong process on testing and qualifying update images
<wolfspraul> that 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)
<wolfspraul> it's more 'soft' things I'm worried about
<wpwrak> yeah, 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 :)
<wpwrak> the 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" ;-)
<wolfspraul> we need to distinguish between theoretically and practically 'never bricking' the device
<wolfspraul> theoretically of course you cannot
<wolfspraul> worst case you ship it back to us :-)
<wolfspraul> but there are many levels in 'unbrickability friendliness' between shipping back to us and pressing a button and waiting 5 minutes
<wolfspraul> so I try to push it as far as possible towards the 'push a button and wait' unbrickability
<wpwrak> yeah, i'd say "no escalation" would be a good criterion
<wolfspraul> even the jtag path is super hard in my opinion, although the daughterboard is in each m1 still
<wolfspraul> have to open the case etc.
<wolfspraul> and you need a Linux host, you may need to compile urjtag from source, etc.
<wpwrak> i.e., if you use process X to break it, then you can use process X it bring it back, too
<wolfspraul> come on, that's all off-limits
<wpwrak> agrees. jtag is too hard to the average user
<wolfspraul> for most people that practically means either a) bricked, drawer or b) ship back to someone who can unbrick it
<wpwrak> way too hard :)
<wolfspraul> one day maybe at least urjtag support will be in upstream, I mean the distro
<wpwrak> i'd also try all other options first before touching jtag ;-)
<wolfspraul> then it's down to apt-get install, but still - needs a Linux notebook/desktop
<wolfspraul> jtag on m1 is actually very user friendly, say to someone with your skill level
<wolfspraul> it's not the broken mess we had on some om devices
<wpwrak> and probably has a number of interesting failure patterns. i remember rejon's 24 hours fight ;-)
<wolfspraul> the only thing missing is that urjtag upstream makes a new release, and that release shows up in Debian/Fedora and offspring
<wolfspraul> that was a libusb breakage
<wpwrak> see :) that's one of these interesting failure patterns
<wolfspraul> ok but at some point you are complaining about the entire foss/distro quality management, which certainly is a subject of its own
<wolfspraul> will it ever stabilize??? :-)
<wpwrak> and it did sort of got halfway through, so it was a puzzling failure
<wolfspraul> I'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 distros
<wpwrak> naw, just saying that jtag has too many moving parts, none of which you use very often
<wolfspraul> reminds me that we have to send them a 1-line patch for the latest spartan-6 stepping we discovered...
<wpwrak> so you get failured from unfamiliarity, bugs, misunderstood instructions, and so on
<wolfspraul> we'are on the same page
<wolfspraul> to me it's already off-limits because it requires case opening, Linux host, urjtag from source compilation, etc.
<wpwrak> yeah. plan B, which currently is the only plan, is ethernet
<wolfspraul> of course, and it will work well
<wolfspraul> remind to self: test test test
<wolfspraul> :-)
<wolfspraul> a quick update on what Adam is doing now
<wpwrak> sweating ? :)
<wolfspraul> he decided to go in bigger batches, that is he will first apply fix2 to 30 or 40 boards, or even more
<wolfspraul> the smt shop (MinBo) will deliver the remaining boards today
<wolfspraul> after he has applied fix2 to a bigger batch, he will proceed with impedance, boot and reflash testing
<wolfspraul> after that we are most likely looking at a big mess of failed boards :-)
<wolfspraul> he he
<wpwrak> adam will have nightmares of being chased by diodes and when trying to escape, tripping over 15 cm wires
<wolfspraul> and then off to xray
<wolfspraul> all this work will take several days, we just have to be patient a little
<wpwrak> does he have access to a thermal imaging sensor ?
<wpwrak> if yes, a quick test would be to take one of the high-current board, power it, then watch where it gets hot
<wolfspraul> I'm sure even if he had a thermal sensor, he wouldn't want to use this test
<wolfspraul> it makes no sense
<wpwrak> it may not even be destructive. or at least not more destructive than what he has already done
<wolfspraul> we 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.
<wolfspraul> that 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 :-)
<wolfspraul> not a thermal imaging sensor test. you want to use this on how many boards? :-)
<wpwrak> sure, checking the SMT fab's work is also good. but we still don't know why even the first board failed
<wpwrak> you seem to be assuming it's a widely distributed failure. but it may very well be a single point.
<wolfspraul> then we wouldn't be interested in that board at all
<wpwrak> (imaging) maybe two. plus a regular one first
<wpwrak> the single point failure may still be repeated
<wolfspraul> oh 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.
<wpwrak> yes
<wolfspraul> whichever way you turn it, xray is the right approach here, not thermal sensor
<wpwrak> it may not be easy to see
<wpwrak> xray is great, but you need to spot the problem
<wolfspraul> very easy because that's what the operators of those xray search every day
<wpwrak> thermal imaging shows you where it is :)
<wolfspraul> you should see the xray operator's speed :-)
<wolfspraul> it's always the same thing, no rocket science. there's a pcb, and solder paste, and connections...
<wpwrak> well, let's see how good they are :) if it's just some generally sloppy with, like poor alignment, they ought to find it very quickly
<wolfspraul> we already know it's not a design problem, right?
<wpwrak> if it's something more obscure, they may have a hard time without knowing the circuit better
<wolfspraul> otherwise we wouldn't have 5 functioning boards now
<wolfspraul> so if it's not a design problem, then it's a manufacturing problem
<wolfspraul> which means it's an economical problem
<wpwrak> it could still be a design problem. weird things happening at the edge of tolerances (could be mechanical tolerances)
<wolfspraul> one way to fix an economical problem is to throw the trouble-makers away and build more
<wolfspraul> I'm just saying 'one way'
<wpwrak> or it could be an IQC problem
<wolfspraul> yes sure
<wolfspraul> but all economical
<wpwrak> maybe you got a bad batch of FPGAs :)
<wolfspraul> so the idea of seeing where it gets hot just doesn't make much sense
<wolfspraul> it's way too destructive, and only gives you visibility into that one board, which you may even damage
<wolfspraul> this will only drag you deeper and deeper into economic mess
<wpwrak> if i had an imaging sensor, the heat test would be the very first thing i'd do ;-)
<wpwrak> and after a few tries, i'd probably be good enough at it to not burn up too many boards ;-)
<wolfspraul> I'm sure, sounds like :-)
<wolfspraul> you would then probably do it in sequence on all failure boards, because it's so much fun :-)
<wpwrak> naw, i wouldn't want to kill them all. but i'd want a quick first clue
<wolfspraul> why?
<wolfspraul> the damage has been done, all 90 are produced
<wolfspraul> see your are focusing on the wrong thing
<wpwrak> to see if it's something that can easily be fixed
<wpwrak> e.g., maybe it's an accidental solder bridge
<wolfspraul> doesn't matter anymore, we only need to know that before rc4
<wpwrak> e.g., because some component it too close to something it shouldn't be
<wolfspraul> and since we don't start a parallel rc4 effort now, we are under no time pressure to find the root cause
<wolfspraul> we can focus on the per-board costs
<wolfspraul> so xray is just far more efficient
<wpwrak> we'll see :)
<wolfspraul> both in speed and as a nondestructive way
<wolfspraul> I think we can rule out that the problems come from applying fix2.
<wolfspraul> that would be the only risk we are taking
<wpwrak> we'll see ;-)
<wpwrak> i'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.
<wolfspraul> the early or late knowledge of 'components too close' makes no difference for rc3 anymore
<wpwrak> maybe it's something simple. and once you know what it is, you can spot and fix it.
<wolfspraul> so now it's about minimizing costs per board that will eventually be fully ok
<wolfspraul> wpwrak: I understand. but what's the difference of knowing such a 'simple and easy to fix' problem earlier or later, in our current situation?
<wpwrak> it 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.
<wpwrak> thermal is likely to know you the path. it doesn't always work, but it often does.
<wolfspraul> have you seen an xray search for this type of problem live?
<wpwrak> i don't remember. what i saw were on-site results of a badly placed BGA. that's the kind of thing xray is great for
<wolfspraul> the xray search will allow you to quickly roam/fly around the whole board and definitely scan all chips and connections in maybe 5 minutes / board
<wolfspraul> even less
<wpwrak> yes, xray is basically AOI without the automation
<wpwrak> and better vision :)
<wolfspraul> it's really fast. you zoom in on a chip, and with contrast etc. you can immediately see the problem connections
<wolfspraul> then you zoom out, left, right, zoom in, etc.
<wolfspraul> all this is very fast
<wolfspraul> the key is to do it with a larger batch of boards
<wolfspraul> at least if access to the xray machine is not just next-door
<wpwrak> all 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 that
<wolfspraul> even I could identify the bad connections right away, simply because they look different from the pins next to it
<wpwrak> and yes, it's good to bring more than one board. also have a few good ones ready, for comparison
<wolfspraul> you cannot see a problem inside the chip
<wolfspraul> but xray is really the gold standard in terms of verifying that the soldering itself is good
<wpwrak> it's a very powerful tool, agreed
<wpwrak> when will adam visit the xray shop ?
<wolfspraul> sounds like Wednesday to me
<wolfspraul> today and tomorrow probably full-day fix2 and test
<wolfspraul> it also needs an appointment there
<wolfspraul> wpwrak: when the xray results are inconclusive, you will have your field day and the heat testing can start ;-)
<wpwrak> rubs hands :)
<wolfspraul> which of course - you are right - is possible (that the results are inconclusive)
<wpwrak> would be interesting to have a comparison of the two. see how quickly they yield results. and whether they yield the same results ;-)
<wolfspraul> but 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 good
<wpwrak> oh course, xray is ideal when it comes to confronting your SMT fab about lousy handywork ;-)
<wolfspraul> xray is nondestructive and fast, so in this case (right after smt), it's done first
<wolfspraul> actually you made a good point about AOI
<wolfspraul> I'm wondering whether you could build an automatic xray aoi and scan each board :-) and since it's not happening (I think) - why not?
<wolfspraul> maybe a lot of difficulties with closed chamber (but flow of boards), too slow, too expensive, etc.
<wolfspraul> and once the smt process is setup right, it will probably only catch very few cases
<wolfspraul> axi
<roh> re
<roh> 20*3 buttons glued. now i will wait a few minutes and do a fitting test again
<wpwrak> wolfspraul: maybe the people who'd think it's a good idea and the people who could pull it off just never met :)
<roh> if all is well i may be able to finish glueing tomorrow
<wolfspraul> nah. most likely it's simply uneconomical.
<lekernel> roh, cool :)
<lekernel> all the other parts are done?
<wpwrak> wonders of there are production runs where all boards are routinely xray-inspected. e.g., for high-reliability applications
<roh> lasered, yes.
<lekernel> ok. and no missing parts? (screws, metal sheet, ...)
<roh> i still need to do final qc, but they are here, and cut/glued/etc
<wpwrak> lekernel: (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 neighbourhood
<wolfspraul> no, sure not. [missing parts]
<wolfspraul> lekernel: the logo is still missing, I am OK with roh just engraving whatever he thinks looks good
<roh> the shields need to be cut on some corners (overhanging foil) but thats done fast
<wpwrak> lekernel: i.e., seems that i still don't quite understand the entire usage pattern of that pin
<roh> the logo is missing, true.
<wolfspraul> the last idea was 'relatively' small and in the corner, top acrylic
<lekernel> wpwrak, 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)
<wpwrak> lekernel: aah, perfect. thanks !
<wpwrak> R60 removed, fixed the right-hand variant, added uQFN variant
<aw> remaining 39pcs is back.
<aw> labled done and will pick 20pcs among them.
<wolfspraul> aw: nice!
<aw> 0x30 has been kept rendering 5 days from 7/20 pm3:30
<wolfspraul> that's how it should be
<wolfspraul> nice test!
<wolfspraul> aw: make it a full week (168 hours), those are good things to talk about if we tested it
<wolfspraul> now we are already over 100 hours, not bad ;-)
<aw> wolfspraul, okay
<lekernel> uQFN?
<lekernel> let's use SOT-23 instead: easier to source and easier to rework
<GitHub149> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/f2ff607f60573e2ea4886fd2c70b65467655b26a
<GitHub149> [milkymist/master] TMU: get simulation to run - Sebastien Bourdeauducq
<wpwrak> lekernel: yeah. should be a LOT easier to rework :) uQFN is 1x1 mm :) do you still prefer the left-hand side ?
<lekernel> yes
<lekernel> you can use the AND gate everywhere by the way, just short the two inputs
<lekernel> ah, but no, it's push pull
<wpwrak> yup. that's the problem
<wpwrak> actually .. if you want the same chip and don't mind a pull-up on FLASH_RESET_N, then there's another option ...
<lekernel> or, put a resistor in series
<lekernel> between INIT_B and the output of the AND gate
<lekernel> though there might be an internal pull up in the FPGA... oh, well
<lekernel> use either the current capacitor based hack or the left part
<lekernel> period :)
<wpwrak> a small series resistor ? ;-) (1k-ish)
<lekernel> no
<lekernel> enough
<wpwrak> ;-)
<wpwrak> alright. that should be all then
<wpwrak> shall i post a summary to the list ?
<lekernel> yes, if you want :)
<wpwrak> and hand-fixed the evil arc :)
<GitHub158> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/f88e7e5fa51b26a7f9a7315a1f6d01dd5b0245c7
<GitHub158> [milkymist/master] TMU prefetch: fix qpram module - Sebastien Bourdeauducq
<GitHub64> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/df38f9108d4933eb2098d246ce3d7e6c89bb8b1f
<GitHub64> [milkymist/master] TMU prefetch: ack fragment FIFO on datamem resume - Sebastien Bourdeauducq
<Alarm> http://www.milkymist.org/snapshots does not work?
<lekernel> no, use /updates
<GitHub133> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/79679fbe2c6af1560498afccaf82cc8758862599
<GitHub133> [milkymist/master] TMU prefetch: generate datamem busy signal - Sebastien Bourdeauducq
<Alarm> did the update of the  card. Question: the mouse is difficult to control. Is there a setting?
<lekernel> no, there isn't
<lekernel> if it's very bad, you can use the keyboard shortcuts
<lekernel> or, of course, you can implement this setting (or fix the bug if there is any)
<lekernel> half the TMU regression tests are passing with prefetching now ... :)
<GitHub198> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/09d45f60326196546c71198a80b83ccb92d8bd5c
<GitHub198> [milkymist/master] TMU prefetch: fix split module - Sebastien Bourdeauducq
<lekernel> mwalle, the new lm32 works btw
<lekernel> yay, now rendering with TMU prefetch
<lekernel> there are minor bugs, but it works
<lekernel> 25 fps @ 800x600, encouraging
<lekernel> in 1024x768 it DoS the sdram controller and screen tends to lose sync... hmm
<GitHub87> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/7be5065af6f40e5f5f6e7a71e5f897726d5c34f7
<GitHub87> [milkymist/master] TMU prefetch: assert busy during memory burst in texel fetch unit - Sebastien Bourdeauducq
<GitHub169> [milkymist] sbourdeauducq pushed 1 new commit to hires: https://github.com/milkymist/milkymist/commit/7448aa97225d70b52c4f1454a78906c185753d77
<GitHub169> [milkymist/hires] Merge branch 'master' into hires - Sebastien Bourdeauducq
<GitHub123> [linux-milkymist] larsclausen pushed 3 new commits to master: https://github.com/milkymist/linux-milkymist/compare/3eb7cd6...dd0d8d5
<GitHub123> [linux-milkymist/master] lm32: Readd memblock initialization - Lars-Peter Clausen
<GitHub123> [linux-milkymist/master] lm32: simplify ret_from_fork - Lars-Peter Clausen
<GitHub123> [linux-milkymist/master] lm32: Fix return value for manage_signal for kernel mode - Lars-Peter Clausen
<mwalle> larsc: whoops, sorry for the dropped memblock support
<mwalle> wpwrak: 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 sector
<larsc> mwalle: i've moved the start of physical mem address range to 0, i'm not sure if this is correct though
<mwalle> larsc: from 0x40000000 ?
<larsc> yes
<mwalle> mh, 0 is flash
<wpwrak> mwalle: yeah. probably quite difficult to make it truly unbrickable. maybe something for M2 to consider :)
<wpwrak> mwalle: if all else fails, maybe someone can make a live cd with all the jtag stuff ;-)
<larsc> mwalle: 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_OFFSET
<larsc> can i add watchpoints for register values?
<mwalle> larsc: in real hw? nope
<larsc> in qemu
<mwalle> in qemu neither, iirc :)
<larsc> well, it at least accepts watch $ra=0x3
<mwalle> but thats just gdb
<mwalle> i cant remember of any code that checks the value of a register every single step
<larsc> it seems to work
<larsc> but is ultra slow
<mwalle> ah is gdb single stepping? :)
<larsc> must be
<methril_work> larsc, your github repo has the latest MMOne Linux-kernel changes
<methril_work> ?
<larsc> methril_work: yes
<mwalle> larsc: default translation in asm-generic?
<larsc> mwalle: yes
<larsc> if 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 cpu
<mwalle> the absolute address
<mwalle> like the cpu without any translation sees it
<larsc> so we'd set PAGE_OFFSET to 0
<mwalle> CONFIG_KERNEL_RAM_BASE_ADDRESS == 0x40000000 ?
<larsc> that's what it is set to right now
<larsc> hm, setting PAGE_OFFSET to 0 and move the ram region in the dts to 0x40000000 seems to work
<mwalle> tries to understand the default page.h :)
<larsc> hehe
<mwalle> git show 5c01b46bb6
<mwalle> bbl, dinner
<mwalle> larsc: btw if KERNEL_RAM_BASE_ADDRESS is really the physical ram base, it cant be a compile time option
<Alarm> s it possible to load the patches by the jtag cable?
<mwalle> Alarm: nope
<mwalle> use network with ftp
<Alarm> ok
<Alarm> s it possible to transfer the patches to the PC by ethernet card Milkymist?
<mwalle> Alarm: yes
<mwalle> larsc: mhh unfortunately the linker script needs that address, too :(
<lekernel> in theory I should be able to tune the thing to make the blue curve flat and always at the initial value
<lekernel> (x-axis is "difficulty" of the texture mapping operation)
<GitHub59> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/64ec8317c8f387fa73512c6622a90492e7786738
<GitHub59> [milkymist/master] tmubench: send data to UART only - Sebastien Bourdeauducq
<Alarm> is there a wiki page to configure the ftp transfer between the PC and the card?
<lekernel> just set login/password in the GUI and the FTP server should work
<lekernel> just click "system settings"
<Alarm> yes but my PC must be FTP server?
<mwalle> Alarm: no only ftp client
<GitHub156> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/9460bd9d1d9338a60a4fce3a5d5e04ce16a7a03e
<GitHub156> [milkymist/master] TMU: make fragment, fetch and commit FIFO sizes configurable at top level - Sebastien Bourdeauducq
<Alarm> the card has an IP address?
<GitHub88> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/4939ee31d26ea4ff4a6cd64e23d39f9ebd47789d
<GitHub88> [milkymist/master] renderer: enlarge texture buffers - Sebastien Bourdeauducq
<lekernel> Alarm, yes
<lekernel> if you open the system settings dialog box, you will be able to see and set it
<wpwrak> lekernel: what's the spike on the red curve ?
<lekernel> experimental fun?
<lekernel> actually I don't know. maybe an error or some cache/sdram effect
<lekernel> gn8
<GitHub110> [linux-milkymist] mwalle pushed 5 new commits to master: https://github.com/milkymist/linux-milkymist/compare/dd0d8d5...f77b794
<GitHub110> [linux-milkymist/master] lm32: undefine KERNEL_RAM_BASE_ADDRESS - Michael Walle
<GitHub110> [linux-milkymist/master] lm32: remove compiled in kernel command line - Michael Walle
<GitHub110> [linux-milkymist/master] lm32: use generic scan memory function directly - Michael Walle