cladamw | wpwrak, reading email... | 01:23 |
---|---|---|
cladamw | will change them based on the feedback you gave, tks. ;-) | 01:24 |
wpwrak | thanks ! :) | 01:24 |
cladamw | regards to 'crowbar', i've not gone through all contents about that. so I'll direct add it once i totally understand it. :) | 01:26 |
wpwrak | i don't think we have to work too hard on making the schematics look "perfect", since we'll convert them to kicad anyway, but there are a few nasty bits that can get in the way of reviewing, and it's better to fix these | 01:26 |
cladamw | sure, whenever you watch it out, all good stuffs we can fix them if just couples minutes works. :) | 01:28 |
wolfspraul | wpwrak: yes, thank you for the details | 01:34 |
wolfspraul | the overall plan seems to be to first finish R4 in Altium, then work on kicad & boom? | 01:34 |
wolfspraul | and I think the finishing in Altium will take another week or so... | 01:35 |
wolfspraul | cladamw: you work on a Saturday? or today is not Saturday? :-) | 01:35 |
cladamw | cladamw, yes, Saturday now, since some details i still haven't absorbed, so ... ;-) | 01:36 |
wpwrak | yes, i think it's best to finish the altium. then we can do a public call for review. see what feedback we get. after review, adam can talk to the layout guys. and then we can start the conversion. | 01:37 |
cladamw | also yes those are small things to go... ;-) | 01:37 |
wolfspraul | yes sounds right | 01:37 |
wpwrak | maybe we'll find issues during the conversion. so it's sort of another review pass. | 01:37 |
cladamw | sounds good. | 01:37 |
wolfspraul | I still want to go through the connectors and document how/why/why not software can detect insert/removal action | 01:37 |
wolfspraul | but we did that already in chat, so first we just take those old notes, maybe it's just a documentation effort | 01:38 |
wolfspraul | and maybe we find a few ones to improve, we see | 01:38 |
wolfspraul | but after the current burst of activity is settled (j21/j22 etc) | 01:38 |
wpwrak | heh, good :) | 01:39 |
wpwrak | what do we aim for with DVI ? will there be any design verification for the digital side ? | 01:40 |
wpwrak | and is DVI settled, as far as the schematics are concerned ? | 01:40 |
wpwrak | cladamw: oh, i have one more bit of nitpicking for you: the 24 Ohm resistors of USB are all upside-down: R136, ... | 01:41 |
wpwrak | it's funny. at first, you mentally add an "R" and think you're looking at "R24". then you realize that this can't be right ... ;-) | 01:41 |
cladamw | wpwrak, i remembered larsc said once that dvi-i pin16 feature in irc, so i think we have to add a part to test this. | 01:41 |
cladamw | wpwrak, oah..yuh...we few people knew it but else probably can't ! ;-) | 01:43 |
wpwrak | (dvi pin 16) yes, that's for hotplugging. but i mean in general. is DVI "finished" ? | 01:43 |
cladamw | wpwrak, i think so, BUT please review those all pins depends to the related... second... | 01:45 |
cladamw | http://lists.milkymist.org/pipermail/devel-milkymist.org/2012-January/002622.html | 01:45 |
wpwrak | ah, one BIG task that awaits us when going to kicad is to change all those "bidirectional" signals to something meaningful. things like "AC97_CLK". | 01:46 |
cladamw | i mostly followed this thread to finish DVI-I circuit, so please also see this important thread too. ;-) | 01:46 |
cladamw | wpwrak, sure..okay | 01:46 |
wolfspraul | DVI 'finished', not sure | 01:48 |
wolfspraul | maybe we are careful with R4 and first make a handful of boards only | 01:48 |
wolfspraul | we have to think about the fastest yet also most economical way forward | 01:49 |
wolfspraul | can we do any additional dvi (digital path) design verification now? | 01:49 |
wolfspraul | I don't think so | 01:50 |
wolfspraul | pin16 is still todo | 01:50 |
wpwrak | the scary bits are probably in signal integrity. we can't usefully verify these without making the real board | 01:51 |
wolfspraul | yes | 01:51 |
wolfspraul | but it's actually good that we start with low resolutions | 01:51 |
wpwrak | i don't know if we could use the extension header to connect DVI-D, or if it would degrade the signal too much to be useful | 01:52 |
wolfspraul | because the little I understand I think the protocol is relatively failure tolerant, that is signal integrity incrementally gets harder as resolution increases | 01:52 |
wolfspraul | also I think any digital video-out support depends on first switching to migen | 01:52 |
wpwrak | having DVI-D via the extension header would allow the implementation of some test pattern generator that would then accelerate verification of M1r4 | 01:53 |
wpwrak | proper DVI out for sure | 01:53 |
wolfspraul | the only person that can implement both the migen switch or digital video-out support in a timely way is Sebastien now, so we have to ask him | 01:53 |
xiangfu | wpwrak, Hi. I just test the SET_PROTOCOL. | 02:13 |
xiangfu | I guess most usb keyboard support the SET_PROTOCOL. I send the SET_PROTOCOL to combo device's mouse interface. then the mouse totally not working | 02:14 |
xiangfu | wpwrak, so my plan is only check the REPORT_ID from REPORT_DESCRIPTOR | 02:16 |
wpwrak | xiangfu: did the SET_PROTOCOL work with a normal mouse ? | 02:18 |
xiangfu | wpwrak, yes. normal mouse works fine. | 02:19 |
xiangfu | wpwrak, I only have one normal mouse. | 02:19 |
wpwrak | (normal mouse ok, but combo not) ah, pity then. i was afraid that something like this would happen :-( | 02:19 |
wpwrak | one is enough to test for success ;-) | 02:20 |
xiangfu | wpwrak, I would guess those combo device only make keyboard support boot protocol but mouse | 02:21 |
xiangfu | wpwrak, since for BIOS boot system. it only check keyboard | 02:21 |
xiangfu | wpwrak, I have tested the code of check REPORT_ID. it's make both combo device and normal mouse works fine. | 02:22 |
wpwrak | kewl. so it's the report protocol then | 02:23 |
wpwrak | ... and we've learned something more about things going wrong with usb :) | 02:23 |
xiangfu | wpwrak, another thing is when I issue the GET_HID_REPORT to normal mouse. it always give RX timeout error, SETUP not ACKed | 02:26 |
xiangfu | print_hex the return of control_transfer is 0xFF. | 02:26 |
xiangfu | I don't know what wrong with this GET_HID_REPORT. so far only ignore this error. | 02:27 |
wpwrak | hmm, is the interface number correct ? (in the case of the normal mouse) | 02:30 |
wpwrak | ah wait, you determine this at run time. so it should be fine | 02:30 |
xiangfu | this is the first patch . pass ep_status to process: http://pastebin.com/PUKCx0Jy | 02:38 |
xiangfu | this is the second patch : http://pastebin.com/sbmy8DTK | 02:38 |
xiangfu | try to check if there is REPORT_ID in the report data. | 02:38 |
xiangfu | line 78, 79 still hard code. | 02:39 |
xiangfu | working on that now. | 02:40 |
xiangfu | wpwrak, can you please paster the Rii RF mini-keyboard hiddump somewhere. just want compare with my mini-keyboard. :) | 02:42 |
wpwrak | you need to check for ep == NULL at line 108 | 02:42 |
wpwrak | and you can simply line 112 and so on by replacing case X: if (Y) { ... } break; with case X: if (!Y) break; ...; break; | 02:44 |
wpwrak | saves one indentation level :) | 02:44 |
wpwrak | s/simply/simplify/ | 02:44 |
xiangfu | line 112. yeah. | 02:50 |
xiangfu | I like save indentation level. | 02:51 |
wpwrak | :) | 02:51 |
xiangfu | now much better: http://pastebin.com/eJzV42w4 | 02:52 |
xiangfu | and fix a NULL bug. | 02:52 |
wpwrak | yup :) | 02:54 |
wpwrak | if you want to emphasize the NULL check, you could begin both USB_DT_HID and USB_DT_ENDPOINT with if(!ep) break; | 02:55 |
wpwrak | but what you have now looks good to me, too | 02:55 |
xiangfu | you mean like this one: http://pastebin.com/bgyG1FbH | 02:58 |
xiangfu | sorry. I mean this one: http://pastebin.com/eRbkj3Yy | 02:58 |
wpwrak | yeah | 02:59 |
xiangfu | I got a mini wireless keyboard too. | 03:00 |
wpwrak | with built-in mouse ? or just keyboard ? | 03:01 |
xiangfu | same as yours. but it's a ShanZhai device. | 03:01 |
xiangfu | with a build-in mouse | 03:02 |
wpwrak | kewl. and i'm sure it was a lot cheaper ;-)) | 03:02 |
wpwrak | wolfgang is looking for such a device to source for M1r4. so it's good that with both have one, and can make sure it works well. | 03:03 |
xiangfu | yes. ~200RMB. I forget the price. Yi bought it under taobao.com. | 03:05 |
xiangfu | since it's a ShanZhai device. not work out of box. :( | 03:06 |
xiangfu | with these two patches works fine now. :) | 03:06 |
xiangfu | but I need change the hardcode better :) | 03:06 |
wolfspraul | let's be accurate. that's not 'shanzhai'. | 03:07 |
wolfspraul | shanzhai I'd say are really only mtk-driven small outfits. the keyboard you got comes from unisen, anterton or some other keyboard maker. | 03:07 |
xiangfu | oh. another problem you mentioned before. about those keys. like PrtSc = Fn + F2. | 03:07 |
wolfspraul | I know the real shanzhai and they work from the trunks of their cars... | 03:07 |
xiangfu | and screenshot not working. since we need press. Ctrl + Fn + F2. | 03:07 |
wolfspraul | our ambition must be: if the keyboard or kbd+mouse combo works with Linux/notebook, it should work with m1 :-) | 03:09 |
wpwrak | (keys) yes ! ;-) from that i know that sebastien can see the future. and he's vicious :) he accurately predicted all the key combinations one couldn't produce with the kind of keyboard we have, and he used almost exclusively these in FN. about the only thing that works is Esc. | 03:10 |
xiangfu | wolfspraul, yes. shanzhai = mtk-driven or if the device that same with foreign device and people call then shanzhai also. :) | 03:10 |
xiangfu | wolfspraul, yes. just check. there are company name. tel and address on manual. so it's no shanzhai. | 03:10 |
wpwrak | wolfspraul: the problem is that FN requires exotic key combinations that some of the tiny keyboards can't generate | 03:11 |
xiangfu | shanzhai device don't have tel. addr. company name. etc. :) sorry. | 03:11 |
xiangfu | wpwrak, it's made by NOVICE. model N950mini. | 03:11 |
wpwrak | whatever :) | 03:11 |
wolfspraul | we need to move all default keys to such keys that are easily accessible on the most basic keyboards | 03:14 |
wolfspraul | and we have plenty of keyboards now, a good time to do that... | 03:14 |
wolfspraul | (some more samples are on the way) | 03:14 |
wpwrak | (move) agreed. shouldn't be too hard to find better mappings. the mouse replacement may be a bit tricky. maybe with shift it'll be alright. | 03:17 |
wolfspraul | I've found some mini keyboards that advertise 'multi-touch' on the pad | 03:24 |
wolfspraul | not sure what that means - sample on the way | 03:24 |
wolfspraul | (and I'm not sure it's relevant to us, but can never hurt to look at what it actually is) | 03:24 |
wpwrak | that sounds weird ;-) | 03:25 |
wolfspraul | maybe they export 2 mice interfaces? who knows... | 03:25 |
wolfspraul | or maybe just a marketing gimmick. we shall find out soon. | 03:26 |
wpwrak | yeah. "welches maeuserl haetten's denn gern ?" (for an obscure old german reference :) | 03:26 |
wpwrak | my bet would be on marketing | 03:26 |
wpwrak | maybe mouse + scroll strip | 03:27 |
wolfspraul | but in any case xiangfu has to get the one he has now working, since it easily works on a Linux notebook, and our codes cannot be so fragile that they only work with a rare select list of models | 03:27 |
wolfspraul | yes, could be with scroll strip, because some models also seem to say something about 'scroll' feature | 03:28 |
wpwrak | (rate models) sure. we have a number of well-known compatibility issues. not considering report formats is but one of them :) | 03:29 |
wolfspraul | wpwrak: I'm leaning towards an upright one like this one right now http://www.ipazzport.com/05E.html | 03:32 |
wolfspraul | but selection/sampling process is ongoing, and it will depend on quality, feel, whether we can get it to actually work on m1, etc. | 03:32 |
wolfspraul | that 'E' one includes multi-touch & scroll | 03:33 |
wolfspraul | the same without E, 1-2 USD cheaper http://www.ipazzport.com/05.html | 03:33 |
wpwrak | “jest like your TV remote control” | 03:35 |
wpwrak | there's a comma missing ;-) | 03:36 |
wpwrak | both look suitable | 03:37 |
wolfspraul | this one is narrower, for 'single hand operation' http://www.ipazzport.com/08.html | 03:37 |
wolfspraul | not sure what's better with m1 - larger touchpad or narrower / single-hand | 03:38 |
wolfspraul | wow, the -08 weighs 43 gram :-) | 03:39 |
wpwrak | looks cramped | 03:39 |
wolfspraul | I'm also not 100% sure yet about batteries, of course I would prefer standard batteries | 03:39 |
wolfspraul | but I think those ones have nokia-style batteries, maybe even the same as on Ben NanoNote | 03:40 |
wpwrak | as if you had a choice :) li-ion it is | 03:40 |
wpwrak | ah, "standard" li-ion | 03:41 |
wolfspraul | sure, but a CR25 is easier to replace x years later than a nokia bl-4c | 03:41 |
wpwrak | well, you can peek inside. most likely, it won't be anything you'll find convenient to source outside of china | 03:41 |
wolfspraul | ah, increasingly what is convenient to source inside China is the same that is convenient to source worldwide... | 03:42 |
wolfspraul | but still, I would prefer standard, we see | 03:42 |
wolfspraul | I'm learning | 03:42 |
wolfspraul | you think the -08 looks cramped? | 03:42 |
wpwrak | what's cr25 ? | 03:43 |
wolfspraul | those round button batteries | 03:43 |
wolfspraul | sorry maybe it's cr2016, 2025, 2043 | 03:44 |
wolfspraul | 2032 | 03:44 |
wolfspraul | :-) | 03:44 |
wolfspraul | 16/25/32 is the thickness | 03:44 |
wpwrak | -08 looks like my keyboard but with the keys oriented vertically instead of horizontally. so each button would be half the size. | 03:44 |
wpwrak | already mine is small. | 03:44 |
wolfspraul | yeah, so maybe 05 or 05E is better | 03:44 |
wolfspraul | I'm leaning towards those now, but I need to sample and compare more | 03:45 |
wpwrak | ah :) all those keyboards seem to use rechargeable batteries, for better or worse | 03:45 |
wpwrak | ("mine is small") and i like things to be tiny. so i'm already at the tail of the curve :) | 03:46 |
wpwrak | checked the size. it's indeed just as wide as mine is tall | 03:47 |
wpwrak | so that's a size reduction of about 2:3. very small. | 03:49 |
wpwrak | but try it. if it works, even cooler ;-) | 03:49 |
wolfspraul | all moving | 03:50 |
wolfspraul | but we need to make the ones we have work first as well, our sampling effort is gated on several sides :-) | 03:51 |
wpwrak | oh, and the -08 uses a lot of Fn+key for special characters | 03:54 |
wpwrak | nothing that looks too offensive, though | 03:55 |
wpwrak | and so does the -05. i'm discovering the secrets of the upright form factor :) | 03:57 |
wpwrak | well, try them. edit a few patches. then you'll see what feels right. | 03:58 |
lekernel_ | http://www.jedec.org/sites/default/files/JS_Choi_DDR4_miniWorkshop.pdf | 11:10 |
lekernel_ | if I understand correctly, this "bank group" thing is about selecting two banks (one in each group) on read/write operations, each providing half of the data bus? | 11:28 |
wpwrak | hmm, why does it scare me if they state that adding CRC increases performance ? | 11:45 |
lekernel_ | yeah I don't get that either | 11:50 |
lekernel_ | and it seems that those CRCs cause actual data bursts of length 9, which sounds like more scheduling problems | 11:50 |
wpwrak | to me the bank groups sound more like an optimization of (burst) accesses in the same area of the chip, with penalty cycles when crossing a boundary | 11:52 |
wpwrak | (crc) it could mean that they intend to run at speeds at which errors are expected to occur | 11:53 |
lekernel_ | nah, it has do to with data prefetch (aka data bus serialization to a multiple of the DRAM core clock frequency) | 11:54 |
wpwrak | similar to NAND ECC not just being an extra safety feature | 11:54 |
lekernel_ | eg DDR1 has a DRAM core running at half the data rate, but which is 2n bit wide for n data pins | 11:55 |
lekernel_ | DDR3 is 8n | 11:55 |
wpwrak | i think my fairly broad definition would include such cases :) | 11:56 |
lekernel_ | and it seems DDR4, instead of having 16n, is 8n + 8n in two selectable banks | 11:56 |
wpwrak | it doesn't say that you can select them separately | 11:56 |
lekernel_ | I would guess that they simply have to belong to different groups | 11:57 |
wpwrak | maybe it's just 8n bits from bank X at tCCD_S, then it switches internally to bank X+1 with the memory controller selecting tCCD_L for that access | 11:57 |
lekernel_ | nah, the numbers have to add up - you have to provide 16 bits per DRAM cycle per data pin | 11:59 |
lekernel_ | hmm | 11:59 |
lekernel_ | tCCD is the minimum delay between two column commands (ie read/write) from the memory controller | 11:59 |
lekernel_ | which can be larger than the burst length starting with DDR3 | 12:00 |
lekernel_ | http://www.eng.utah.edu/~cs7810/pres/dram-cs7810-protocolx2.pdf | 12:01 |
lekernel_ | I wonder how much this costs: http://www.lecroy.com/protocolanalyzer/protocoloverview.aspx?seriesid=398 | 12:06 |
wpwrak | (tCCD) still sounds compatible like my theory :) maybe tCCD_S is without data read or a somehow reduced data read | 12:07 |
wpwrak | s/like/with/ | 12:08 |
lekernel_ | "the Kibra 480 system allows SoC designers to leverage their R&D budgets and increase their test coverage of next generation DDR memory technology." | 12:08 |
lekernel_ | hahaha | 12:08 |
wpwrak | (kibra) if you have to ask you can't afford it ;-) | 12:11 |
mumptai | mhmm, crc? fec-codes would | 12:12 |
wpwrak | mumptai: CRC+ARQ | 12:16 |
mumptai | urks, but than you get unpredictive timing ... | 12:17 |
wpwrak | a small price to pay for more overall speed ;-) | 12:19 |
wpwrak | and maybe the clock speed can be "trained" as well. cheap motherboard or cheap RAM modules = DDR4 runs a bit slower. nothing new, actually. | 12:20 |
mumptai | and temperature dependant refreshes made timing already a bit unpredictable | 12:21 |
wpwrak | DDR6 will require the system to boot at a low-speed setting, then consult an astrology server over the internet to determine the exact operational parameters for that day | 12:28 |
lekernel_ | wpwrak: (clock speed training) I've read XBox consoles do this sort of thing... during production, they basically throw in whatever cheap DRAMs they find on the market that day, and their ASIC is supposed to cope with them | 12:33 |
lekernel_ | mumptai: I've never heard of temperature dependent refreshes (except for systems that are supposed to operate at more than 80C or so) | 12:34 |
lekernel_ | but then you just stay in the "high refresh rate" mode | 12:34 |
mumptai | or if refresh causes a significant impact on your power budget (and you application runs rather cold) | 12:38 |
lekernel | and is this spec'd by the DRAM vendors, or do you have to do the testing and characterization yourself? | 12:39 |
lekernel | I think you can actually do that to a large extent... just for the heck of it, I've tried killing refresh for several seconds on a M1, without much data loss | 12:41 |
mumptai | dozens of minutes, if cooled (about -20°C) | 12:43 |
lekernel | data loss is much faster when the DRAM power is cut, though | 12:43 |
kristianpaul | morning :) | 13:39 |
--- Sun Feb 5 2012 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!