| wpwrak | hmm, http://www.milkymist.org/updates/2011-11-13/ lacks bios-rescue.bin splash-rescue.raw splash.raw standby.fpg | 07:38 |
|---|---|---|
| wpwrak | may be nice to keep them around even if they didn't change | 07:38 |
| wpwrak | kewl. now also the 8 k SOC+BIOS boots. | 08:19 |
| wpwrak | does indeed seem to be the sample clock that's messing things up | 09:11 |
| wpwrak | sb0: you have a scope with decent speed, right ? | 09:11 |
| wpwrak | (decent speed) let's say 50 MHz or better | 09:18 |
| sb0 | at home? I have a 80MHz analog scope from the 80s | 09:19 |
| wpwrak | alright. that'll do :) | 09:20 |
| wpwrak | that is, if it has more than just one channel :) | 09:21 |
| wpwrak | if you can output the sample clock somewhere, this will let you see where in the waveform you're sampling | 09:22 |
| sb0 | yes, 2 channels | 09:25 |
| sb0 | well I have already done a verilog simulation of this and it seemed ok | 09:25 |
| wpwrak | yes, i mean in the real waveform. | 09:26 |
| sb0 | simulations are generally accurate :) want to try deglitch first? | 09:53 |
| sb0 | hmm.. just got your email | 09:58 |
| sb0 | want to try sampling 1/4 bit time later? | 09:59 |
| mwalle | wpwrak: do you have ise running? | 11:15 |
| wolfspra1l | sb0: do you think we should make measurements to verify the analog signal quality of the usb wires? | 11:18 |
| wolfspra1l | or you think it's very unlikely that we will find a problem there? | 11:18 |
| sb0 | I have already examined those signals when the rc1 boards went out (with a simple 12MHz oscillator in the FPGA) and I saw nothing unusual | 11:19 |
| sb0 | according to Werner's email it sounds more like the FPGA sampling the signal at inappropriate times | 11:21 |
| wolfspra1l | ok | 11:24 |
| sb0 | what about a livecoding mode? where you edit the patch in the OSD layer while rendering it | 11:36 |
| Action: sb0 is still digesting wpwrak's email | 11:36 | |
| wpwrak | mwalle: (ISE) no, not yet | 11:48 |
| wpwrak | sb0: the NRZI representation of the incorrect patterns looks like IN, but "stretched" | 11:49 |
| wpwrak | so this suggests that too many samples were taken | 11:49 |
| sb0 | yes, but the same clock is used for TX as well, so if the frequency is wrong you'd get TX problems as well | 11:49 |
| sb0 | maybe it is currently sampling just near the edge of the signal? and sometimes a wrong sample slips through | 11:50 |
| wpwrak | how often do you synchronize the phase of the sample clock ? only at the very first edge of the SYNC ? or also inside the packet ? | 11:50 |
| wpwrak | yes, that could also be | 11:51 |
| sb0 | at each transition | 11:51 |
| sb0 | so inside the packet as well | 11:51 |
| wpwrak | that could explain it :) | 11:51 |
| wpwrak | if yuo see too many transitions, your effective sample clock will run faster than the bit clock | 11:51 |
| sb0 | the sample clock generator is very simple | 11:52 |
| sb0 | it's just a counter that divides 48MHz by 4 | 11:52 |
| sb0 | and a transition resets it | 11:52 |
| wpwrak | that's enough to run too fast :) | 11:52 |
| wpwrak | introduce glitches, and voila :) | 11:52 |
| sb0 | if the transitions are improperly timed, yes | 11:53 |
| sb0 | or glitches too | 11:53 |
| sb0 | should we try a deglitcher too? | 11:53 |
| wpwrak | for low-speed, does it also run at 48 MHz ? (with a larger offset then) | 11:53 |
| sb0 | yes, same design, but the counter is larger | 11:53 |
| sb0 | which makes the wrong sample point theory more plausible than glitches | 11:54 |
| wpwrak | that would explain why it doesn't happen at low-speed: you have more room for errors | 11:54 |
| sb0 | yes | 11:54 |
| wpwrak | glitches also mean a wrong sample point. but yes, it's hard to tell the two apart with such a short pattern | 11:54 |
| sb0 | wpwrak, what about a deglitcher based on deglitched = majority(deglitched, signal, signal_delayed_1_cycle) ? | 11:55 |
| sb0 | running at 48MHz | 11:55 |
| sb0 | or majority(signal, signal_d1, signal_d2) | 11:56 |
| wpwrak | or just (signal, signal_d1) ? | 11:56 |
| sb0 | how do you tell a glitch from a legit transition if you have only two samples? | 11:57 |
| wpwrak | they both have to be the same :) | 11:57 |
| sb0 | yes, that's majority(deglitched, signal, signal_delayed_1_cycle) | 11:57 |
| wpwrak | but yes, depends on how big your glitches are. and what exactly they look like | 11:57 |
| wpwrak | that looks like a filter over 3 cycles. but maybe i just misunderstand | 11:58 |
| wpwrak | in any case, what's important is that the deglitching happens before the clock synchronization | 11:58 |
| sb0 | majority(b1, b2, b3) is the bit value that is the most present in the 3 samples | 11:59 |
| wpwrak | ah, i see what you mean. yes, looks good | 12:00 |
| sb0 | with deglitched = majority(deglitched, signal, signal_delayed_1_cycle), deglitched only changes when the two signals are the same and therefore change the vote | 12:00 |
| sb0 | it's equivalent to updating only when signal = signal_d1 | 12:01 |
| sb0 | wpwrak, want an untested patch to try before I go home? | 12:01 |
| wpwrak | if it comes with soc.fpg ... :) otherwise, it'll take longer anyway | 12:03 |
| sb0 | depends on your bandwidth | 12:03 |
| sb0 | my plane is in 6:30 hours ... | 12:03 |
| sb0 | I should have installed ISE on my eee *g* | 12:04 |
| wpwrak | ah, and how do you test the SYNC pattern ? if you get a partial SYNC, e.g., with the first transition missing, does the packet still make it ? | 12:07 |
| sb0 | no | 12:10 |
| sb0 | there's a FSM that waits for each transition, with a global timeout | 12:11 |
| wpwrak | if the SYNC pattern is corrupted (for example, not a SYNC at all), do you abandon the packet ? | 12:11 |
| sb0 | yes | 12:12 |
| wpwrak | or will basically anything that starts with a "0" be accepted as SYNC ? | 12:12 |
| sb0 | no, it has to have all the SYNC transitions | 12:12 |
| wpwrak | (abandon) ah, good | 12:12 |
| wpwrak | that explains why i didn't see any worse shifts | 12:12 |
| sb0 | and the global timeout is just enough for a correct SYNC token | 12:13 |
| wpwrak | so each shift is basically a jump of the sample clock in one of eight possible positions | 12:13 |
| sb0 | so any SYNC messup likely gets the complete packet discarded, unless that packet also happens to contain 0x80 | 12:13 |
| wpwrak | grr. i just realized that my mail doesn't make sense :) | 12:14 |
| wpwrak | wait a minute ... | 12:14 |
| wpwrak | just mis-labeling :) | 12:14 |
| wpwrak | s/IN/NAK/ :) | 12:16 |
| sb0 | ah, yes :) | 12:17 |
| sb0 | I was also wondering | 12:17 |
| wpwrak | so .. the BER (Bit Error Rate), if we want to call it this, is about 3000 ppm. | 12:18 |
| wpwrak | from this we could calculate the probability of a corrupt packet even passing the CRC check | 12:21 |
| wpwrak | about 1:200000 if my estimates are right. still not too horrible for HID and such | 12:24 |
| wpwrak | of course for bulk data, the odds go to hell | 12:24 |
| wpwrak | naw, should be less. maybe 1:1.3 M | 12:28 |
| wpwrak | hmm, 260 M :) still too early to day to do math :) | 12:32 |
| wolfspra1l | was work on the NOR corruption finished actually? | 12:55 |
| wolfspra1l | I think I will check tomorrow whether Adam is 100% clear on the final proposed rc4 reset circuit, then we should act on that asap | 12:56 |
| wolfspra1l | that is - buy parts, design-verify 2 boards in Taipei, send one to Werner | 12:56 |
| Action: mwalle could synthesize the soc for wpwrak (ise 13.1 here) | 13:05 | |
| wpwrak | mwalle: thanks ! | 13:18 |
| wpwrak | wolfspra1l: (NOR finished) no, and i also still have to run some more extensive tests. well, we can do that after the "official" rework. | 13:19 |
| wpwrak | worst case would be that it turns out the rework doesn't help and i just had one of those one-in-a-thousand statistical outliers | 13:20 |
| mwalle | mh sebastien left | 13:21 |
| mwalle | wpwrak: what patch should i apply now? the one sebastien mailed? | 13:21 |
| mwalle | s | 13:22 |
| wolfspra1l | hmm | 13:25 |
| wpwrak | mwalle: the patch he's still working on (i think :) | 13:25 |
| wolfspra1l | but we are reasonably sure that we have a 100% good rc4 plan now? | 13:25 |
| wolfspra1l | I think that would move this item pretty much to the top of Adam's priority list, to get those 2 boards fully reworked & verified asap, and 1 sent out to Buenos Aires | 13:26 |
| wolfspra1l | until now I was under the impression that some bits of wisdom would still come from you before it moves over to Adam, but maybe not... | 13:26 |
| wolfspra1l | is he 100% clear on the final proposed circuit? | 13:27 |
| wpwrak | we can be about 99.8% certain that my reset circuit made the NOR corruption go away | 13:30 |
| wpwrak | not sure how clear adam is on the final circuit. we discussed only bits. there, we seemed to agree. | 13:30 |
| wolfspra1l | hmm | 13:38 |
| wolfspra1l | wpwrak: ok, I will ask Adam tomorrow to write up a final and complete diff from the original rc3 | 13:38 |
| wolfspra1l | including the latest usb power switch stuff | 13:38 |
| wolfspra1l | it would be great if you could sign it off, then Adam tries to rework 2 boards asap | 13:38 |
| wpwrak | sounds like a good plan | 13:39 |
| wolfspra1l | actually I think you did send some pieces already, just not sure about the latest or final version since it was so much in flux | 13:39 |
| wolfspra1l | ok great | 13:39 |
| wolfspra1l | thanks! | 13:39 |
| wolfspra1l | I want to close this one out :-) | 13:39 |
| wolfspra1l | move onto bigger and better things... | 13:40 |
| wpwrak | i also don't like spoon-feeding adam too much. he doesn't need that :) | 13:40 |
| wolfspra1l | sure, I just want to be clear on the process | 13:40 |
| wolfspra1l | otherwise you know how it is, everybody thinks someone else will do something, wait, etc. | 13:40 |
| wolfspra1l | but I have a mental plan now, let's see whether it works out | 13:41 |
| wpwrak | yes, dining philosophers ;-) | 13:41 |
| wpwrak | wolfspra1l: ah, regarding labsw: i came to the conclusion that it's difficult to make a device suitable for larger numbers based on the current case. specifically, there's not enough room for some connectors that are good and easily available. the ones i use are hard to source and don't have entirely convincing properties. | 13:54 |
| wpwrak | so i shelfed it until i have time for a larger redesign | 13:55 |
| mwalle | wpwrak: are you interested in a soc.bit with the patch sebastien mailed already applied? | 13:58 |
| mwalle | (the old one= | 13:59 |
| wpwrak | problems with the current connectors include that they can be shaken loose from the front panel and that they have a very large area of exposed metal inside that can't be isolated. so if any cable comes loose inside the box, there's a risk of a short to a high voltage | 13:59 |
| wpwrak | mwalle: hmm, i think i'll wait for the new one, thanks :) just shifting the sample point probably won't help | 14:00 |
| mwalle | ok so i'll do a make clean now :) | 14:01 |
| wpwrak | mwalle: a bad sample point would explain single-bit errors but not shifts of the remaining pattern. now, the errors i saw could still be explained by single-bit corruptions, but a clock problem seems far more likely | 14:01 |
| wpwrak | we can optimize the sampling point later, when the clock is stable. there ought to be a nice gauss curve to fit to :) | 14:03 |
| wpwrak | ah, and another things to look for would be an algorithm that used the whole information available to determine the clock. i think usb is designed such that you don't need to resync inside the packet. so the SYNC pattern alone should give you enough accuracy | 14:05 |
| lars_ | mwalle: with the new uart core I get sometimes repeated input during tx. | 14:05 |
| mwalle | lars_: on real hw and/or qemu? | 14:19 |
| lars_ | real hw | 14:22 |
| lars_ | haven't tested in qemu yet | 14:22 |
| wolfspra1l | understood [labsw] | 14:24 |
| wolfspra1l | we have *LOTS* of stuff in different degrees of finishedness :-) | 14:24 |
| wolfspra1l | schhist, brdhist, boom, labsw, atben/atusb, ... | 14:25 |
| wolfspra1l | but I think all fine, everything is in good shape and can be reactivated | 14:25 |
| wpwrak | yeah, the amount of semi-finished stuff is a bit embarrassing :) | 14:26 |
| mwalle | lars_: repeated rx chars while you transmit sth? | 14:27 |
| wolfspra1l | no it's ok | 14:28 |
| wolfspra1l | we are spread super thin | 14:28 |
| wolfspra1l | what can we do | 14:28 |
| wolfspra1l | counterweight | 14:28 |
| wolfspra1l | nanonote case scans | 14:28 |
| wolfspra1l | I could go on :-) | 14:28 |
| wpwrak | counterweight is kinda finished :) | 14:29 |
| wpwrak | and brdhist has never started. so i'm good there ;-) | 14:29 |
| lars_ | mwalle: yes. the last received character is repeated | 14:31 |
| lars_ | just as if the rx irq bit was set again | 14:31 |
| wolfspra1l | wpwrak: I think the documentation level on all these things is good, so I am not worried | 14:33 |
| wolfspra1l | some are only in conceptual stage, some finished, some in between | 14:34 |
| wolfspra1l | for labsw, if we have the nor corruption solved we can shelf it until the next real emergency/use case comes up | 14:34 |
| wolfspra1l | of course it would be better to finish those things on the spot, theoretically if we had a real money making company somewhere... | 14:35 |
| wolfspra1l | hopefully we can still do that later | 14:36 |
| wolfspra1l | good seeds | 14:36 |
| wpwrak | labsw is kinda infrastructure. so that's something everyone doing design verification in the project has. i (still) strongly believe in having a "standard" lab infrastructure :) | 14:46 |
| wpwrak | of course, most elements of that would be expensive. labsw is the easy and cheap one :) | 14:46 |
| kristianpaul | wpwrak: btw this modification seabastien did to detecte NULL pointers is it working? and how it works? | 14:49 |
| kristianpaul | i mean how it handle the expection | 14:49 |
| wpwrak | kristianpaul: i haven't tested it yet. but i don't doubt that it works | 14:49 |
| kristianpaul | of course | 14:50 |
| wpwrak | kristianpaul: i think you can set an exception vector (lm32 seems to have a table for that). or just let gdbstub signal it. not sure if gdbstub simply overrides the exception or if you have to choose at build time | 14:51 |
| mwalle | kristianpaul: i think it generates a bus error if an address within the first 512kb is accessed | 14:51 |
| kristianpaul | mwalle: bus error? i tought that kind of errors werent handled either.. | 14:51 |
| mwalle | DEBA and EBA can be set by yourself (iirc bus error is a debug exception) | 14:52 |
| kristianpaul | but interesting | 14:52 |
| kristianpaul | i think that explain (acess first 512kb) some hangs i had when using the bios | 14:52 |
| kristianpaul | i just need to confirm | 14:52 |
| mwalle | kristianpaul: well it isnt exactly a bus error, but sebastien is using that error (and its exception vector) to signal NULL pointer access | 14:52 |
| kristianpaul | BTW mwalle, there is a way to use gdb to debug bios and barematal apps for m1 in the real hw? | 14:53 |
| kristianpaul | or dint worth ? | 14:53 |
| mwalle | should work right now | 14:53 |
| mwalle | just load the debug elf binary with your gdb | 14:54 |
| kristianpaul | you mean i need add a gdb flag to my makefile and use flterm to load it? | 14:55 |
| kristianpaul | then launch a gdb server that connect to serial port ? (wich binary btw?) | 14:56 |
| mwalle | kristianpaul: lm32-elf-gdb <elf> then type load in gdb cli | 14:56 |
| kristianpaul | mwalle: so i dont need flterm? | 14:56 |
| mwalle | just for serial output | 14:56 |
| mwalle | use it with the passthrough parameter | 14:57 |
| kristianpaul | ok, yes because the thing is my program needs human interacion trouhgt the uart | 14:57 |
| mwalle | btw flickernoise is treated as a bare metal application too | 14:57 |
| kristianpaul | so is not a problem run gdb and flterm at same time | 14:57 |
| kristianpaul | ah ok | 14:57 |
| kristianpaul | thats fair :-) | 14:57 |
| wpwrak | is the new UART the only difference between "old" and "new" SoC / milkymist+RTEMS+FN that isn't backward-compatible ? | 14:59 |
| kristianpaul | lars_: btw, there is a reason why the busybox for uclinux is kinda limited, i mean really limited shell... so, if is just as simple as enable some configs in the make menuconfig or do i need to search somewhere else? | 15:01 |
| kristianpaul | lars_: i'm talking about milkymist port of course | 15:01 |
| wpwrak | wolfspra1l: btw, my overall goal in M1 at the moment is to get controls to be generally usable | 15:02 |
| mwalle | wpwrak: iirc thats the only one | 15:02 |
| mwalle | is anyone usiong reflash_m1.sh with snapshots? | 15:02 |
| wpwrak | wolfspra1l: hence MIDI and all that | 15:02 |
| mwalle | reflash_m1.sh complains about missing md5sums file if i use it with --snapshot milkymist-firmware-11202011-0004 | 15:03 |
| lars_ | kristianpaul: what is missing? | 15:14 |
| kristianpaul | lars_: ls cp vi cat rx and poke ;-) | 15:16 |
| kristianpaul | sed ! | 15:16 |
| kristianpaul | but with those i'm happy | 15:17 |
| kristianpaul | and could work | 15:17 |
| lars_ | i have them | 15:17 |
| kristianpaul | why i dont.. | 15:17 |
| kristianpaul | btw there is a rx equivalent for tx? :-) | 15:17 |
| kristianpaul | well i a printf works, just wondering :) | 15:18 |
| kristianpaul | lars_: where i can confirm that those commands above are been included in openwrt-milkymist= | 15:20 |
| kristianpaul | ? | 15:21 |
| lars_ | you can mount the image as a loopback locally | 15:21 |
| kristianpaul | i meant in the source code for openwrt-milkymist | 15:22 |
| kristianpaul | i was using qemu | 15:22 |
| lars_ | kristianpaul: hm? the source code is standard upstream busybox | 15:35 |
| kristianpaul | okay seems i'm in the wrong channel to ask :p | 15:37 |
| kristianpaul | lars_: last thingm can you share your .config for openwrt-milkymist ? | 15:39 |
| lars_ | kristianpaul: http://pastebin.com/dvmk4wwk | 15:42 |
| kristianpaul | Thasks ! :-) | 15:42 |
| mwalle | lars_: does milkymist-linux/master work for you? i pulled it, cherry-picked the new-uart patch, boot seems to hang at "calibrating delay loop.." | 16:22 |
| lars_ | mwalle: even in qemu? | 16:28 |
| lars_ | mwalle: could this be due to the reordered irq numbers? | 16:37 |
| lars_ | i only tested master with the current soc release | 16:37 |
| mwalle | lars_: but there is no new uart driver in master? | 18:25 |
| lars_ | yes | 18:26 |
| lars_ | i've tested the new uart driver with the new uart core, but not with the milkymist soc | 18:26 |
| lars_ | at least not all of it | 18:26 |
| lars_ | mwalle: but i'm pretty sure that it is because of the irq reording | 18:26 |
| lars_ | getting stuck at 'calibrating delay loop' is always a good indication that there are no timer interrupts | 18:27 |
| mwalle | old dts ;) | 18:33 |
| mwalle | arg we have to get rid of the asm/hw/ stuff :) | 18:50 |
| mwalle | lars_: could you please send me (or me point me to) a working initrd/initramfs? | 18:53 |
| lars_ | http://metafoo.de/initrd.bin works if you renable mmap support in the kernel | 18:55 |
| mwalle | lars_: is sys_mmap2 not working? | 18:58 |
| lars_ | it is | 18:58 |
| lars_ | but is is an old initrd | 18:58 |
| lars_ | but it is | 18:58 |
| mwalle | funny, my initramfs is working for qemu but not on the real hw | 18:58 |
| mwalle | on real hw it isnt even detected as an initramfs | 18:59 |
| lars_ | btw. I'm working on something which auto-assigns memory addresses and irq numbers, generates a verilog file and dts from it and embeds the compiled dts into a on-SoC ROM. So no more out-of-date dts' | 19:00 |
| wpwrak | hmm, so "make" now has to re-sythesize ? | 19:01 |
| lars_ | unfortunately that is probably something rtems isn't able to use | 19:01 |
| mwalle | lars_: consider, that the mac address may be emedded into the dts | 19:01 |
| lars_ | wpwrak: only if something changed ;) | 19:02 |
| wpwrak | hmm, kickstarting from repository will be tricky then | 19:03 |
| lars_ | why? | 19:04 |
| Action: mwalle thinks that the dtb should be on a flash partition, but nonetheless autogenerating sounds nice ;) | 19:04 | |
| wpwrak | because you'll need ISE just to get the build dependencies sorted out | 19:04 |
| wpwrak | after applying the uart-interrupt patch, rtems build fails with things like MM_IRQ_UART not being define. who normally provides them ? | 19:05 |
| kristianpaul | wpwrak: rtems-milkymist/c/src/lib/libbsp/lm32/milkymist/include/system_conf.h | 19:08 |
| wpwrak | oh, rtems itself. interesting ... | 19:09 |
| wpwrak | indeed. there it is. thanks ! now .. why doesn't it find it ... | 19:09 |
| kristianpaul | missing export RTEMS_MAKEFILE_PATH=/opt/rtems-4.11/lm32-rtems4.11/milkymist ? | 19:11 |
| kristianpaul | wich i personally consider ugly (dont ask me why) | 19:12 |
| wpwrak | gotta love those paths: ../../../../../../../../c/src/lib/libbsp/lm32/milkymist/../../lm32/shared/milkymist_console/uart.c | 19:12 |
| kristianpaul | 0_o | 19:12 |
| wpwrak | no, i have it set | 19:13 |
| wpwrak | and it should then only not find the things from milkymist.git, not its own headers (i hope :) | 19:14 |
| wpwrak | phew. compiles. | 19:22 |
| wpwrak | mwalle: (no --kernel requirement) nice ! :) | 19:23 |
| wpwrak | i often just give it /etc/passwd, to make it shut up :) | 19:23 |
| mwalle | i've passed /dev/zero :) | 19:24 |
| mwalle | and discovered a divbyzero bug ;) | 19:24 |
| wpwrak | victory ! it boots again ! with the new soc ! :) | 19:25 |
| mwalle | hehe | 19:25 |
| wpwrak | mwalle: seems strangely appropriate :) | 19:25 |
| mwalle | wpwrak: is gdb still working ? :) | 19:25 |
| wpwrak | oddly enough, it seems to, yes | 19:27 |
| mwalle | does bt work? | 19:27 |
| wpwrak | of course :) | 19:27 |
| mwalle | mh | 19:27 |
| wpwrak | and medit 1234 5 produces a very satisfying SIGSEGV ;-) | 19:27 |
| mwalle | lars_: do you happen to know if the initrd_end includes or excludes the last byte of the actual initrd? | 19:29 |
| wpwrak | hmm. would be nice if FN would say something if it segfaults without gdb around | 19:29 |
| mwalle | +pointer | 19:29 |
| mwalle | wpwrak: mh, i guess fn cant figure out if a gdb is connected | 19:30 |
| wpwrak | how does gdb find the segfault ? does FN catch it and tell gdbstub ? | 19:31 |
| mwalle | the cpu jumps to DEBA+x which is the gdbstubs exception vector | 19:32 |
| mwalle | oh, bus error seems to be a non-debug exception, then PC <- EBA+x | 19:35 |
| mwalle | so FN should have some logic which jumps to DEBA+x | 19:35 |
| mwalle | we could introduce a variable at some predefined address which tells you if a gdb is connected | 19:36 |
| mwalle | iff we can load a memory address with one register (r0) | 19:38 |
| mwalle | +from | 19:39 |
| mwalle | otherwise you'll destroy some register contents | 19:39 |
| wpwrak | how does the communication between gdbstub and FN work ? i was imagining gdbstub was operating somehow like a supervisor to the CPU. a bit like jtag. but that's not the case, isn't it ? | 19:40 |
| mwalle | wpwrak: there is no communication between the active program an the gdbstub | 19:41 |
| mwalle | the gdbstub is executed instead of the normal program once an exception occurs | 19:41 |
| mwalle | that is the gdbstubs mainloop polls for gdb packets and processes it, once you continue the program/exit gdb control is handed back to the original program | 19:42 |
| wpwrak | so gdbstub could simply execute the original exception vector if there is no gdb connected ? | 19:43 |
| mwalle | wpwrak: yes, but that way you wont be able to connect with gdb once the execption occured | 19:45 |
| mwalle | eg post mortem analysis is not possible | 19:46 |
| mwalle | sth like "an exception occured blubb blubb, please connect gdb or reset board" message wouild be really helpful :) | 19:47 |
| wpwrak | well, gdb could wait, say, 5 second ;-) | 19:47 |
| wpwrak | secondS | 19:47 |
| wpwrak | but you could also do the post-mortem from an FN exception handler. you'd just have a bit more stack to cover | 19:48 |
| wpwrak | for FN, i was thinking more of a register dump and/or stack trace. like a linux kernel oops. | 19:49 |
| mwalle | wpwrak: yeah and then jump to gdbstub :) | 19:49 |
| wpwrak | yeah, why not | 19:49 |
| lars_ | mwalle: i would guess that it includes the last byte | 19:53 |
| lars_ | on the other hand: memset((void *)initrd_start, 0, initrd_end - initrd_start); | 19:54 |
| lars_ | so initrd_end - initrd_start = initrd_size | 19:54 |
| mwalle | lars_: yep, like qemu does, now initramfs images are working :) | 20:06 |
| lars_ | strange though, that it worked for me | 20:07 |
| mwalle | lars_: initramfs or initrd? | 20:10 |
| lars_ | initrd | 20:13 |
| lars_ | you are using a compressed initramfs? | 20:13 |
| mwalle | i guess there cant be a (fs) check :) | 20:13 |
| mwalle | lars_: yep | 20:13 |
| wpwrak | and now, bit errors, your soul is mine. bwahaha ! | 20:22 |
| kristianpaul | (aw | 21:04 |
| kristianpaul | ah nice, no more kernel, and yes i had passsed just the word moo and worked too :-) | 21:11 |
| kristianpaul | arghh, again i "eat" the namuru_add wire... | 21:37 |
| wpwrak | buen provecho ! :) | 21:56 |
| kristianpaul | s/add/adr | 22:03 |
| kristianpaul | wpwrak: is amazing the wire not defined and xst not generated a error, i guess a warning but come on... | 22:04 |
| wpwrak | if it doesn't work, isn't this warning enough ? :) | 22:05 |
| kristianpaul | sure but it doesnt work partially, but anyway vimdiff helped a lot :-) | 22:15 |
| mwalle | wpwrak: nice script, you could add a "pld reconfigure" at the end of the jtag script | 23:00 |
| wpwrak | hmm, i always do a "make boot" | 23:00 |
| mwalle | wpwrak: btw is gdb (with new uart) working with ^C for you? | 23:03 |
| mwalle | eg cont, ^C | 23:03 |
| wpwrak | yup. works fine | 23:04 |
| mwalle | wpwrak: without flterm+gdbpassthrough? | 23:05 |
| wpwrak | i only tried with flterm | 23:06 |
| mwalle | (m1nor) i dont have a makefile with boot target ;) | 23:09 |
| wpwrak | good old wernermisc/m1/jtag-boot/ :) | 23:10 |
| wpwrak | it's way too much work to reach over to press that button :) | 23:11 |
| wpwrak | besides, that may upset the delicate cabling that goes into my M1 | 23:11 |
| mwalle | what i wanted to say is that i dont want another script :) | 23:11 |
| mwalle | imho you load fjmem but you dont unload it ;) | 23:12 |
| wpwrak | hmm, you may have a point there :) | 23:15 |
| wpwrak | updated | 23:24 |
| wpwrak | interesting. when i comment out debug output, softusb has fewer CRC problems | 23:29 |
| wpwrak | notabene debug output that is printed after a problem, not while things are still good | 23:29 |
| mwalle | gn8 | 23:38 |
| --- Mon Nov 21 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!