| wpwrak_ | back from the dead ... | 09:22 |
|---|---|---|
| wolfspraul | :-) | 09:23 |
| wpwrak_ | wolfspraul: about the USB adapter: with the USB connector pointing upward, it won't be much fun. you'll need some angled element, either in the adapter itself, or between M1 and adapter (the latter being messy) | 09:23 |
| wolfspraul | oh, I didn't mean to point to that one because of any specific use case | 09:23 |
| wolfspraul | but I simply ran into it and saw the 2*5 keyed connector and thought "wow, would that fit on R4?" | 09:24 |
| wolfspraul | as I'm not 100% sure about 'standard' there yet | 09:24 |
| wolfspraul | USB 3.0 will change some things, and I noticed higher maximum currents as well recently | 09:25 |
| wpwrak_ | that adapter would fit, yes | 09:25 |
| wolfspraul | I think USB 3.0 allows 900mA / port, and there seem to be 'high-current' ports even before that I have seen labeled as "1.3A high-current USB port" | 09:25 |
| wpwrak_ | i think they're pretty much all the same. well, there must be *SOMEONE* who did their own thing. but ... :) | 09:26 |
| wolfspraul | I wouldn't be so sure about that, it's all in motion | 09:26 |
| wpwrak_ | i mean < USB 3. USB 3 may be more troublesome | 09:26 |
| wolfspraul | sure, and it's not relevant to us right now, but I am just noticing these changes then we can think of where that might drive any standards, informal or not | 09:27 |
| wpwrak_ | i suspect they made USB 3 mainly because USB 2 worked too well ... | 09:27 |
| wolfspraul | I noticed higher currents here and there, 900mA and 1.3A | 09:27 |
| wpwrak_ | oh, the craving for more current will never stop :) | 09:27 |
| wolfspraul | and if you look at the picture of that startech adapter closely, you will see "via/asus/gigabyte" marking on it | 09:28 |
| wpwrak_ | in 20 years we'll have USB 7 with a connector < 1 mm^2 but delivering 20 A ;-) | 09:28 |
| wolfspraul | why that? | 09:28 |
| wolfspraul | they are all taiwanese corps. so we could see what the mainlanders are doing, on lenovo boards for example | 09:28 |
| wpwrak_ | they probably all copy from intel :) | 09:29 |
| wolfspraul | they may very well not follow and do their own thing, and over time they may create enough volume to influence informal standards just because of their volume | 09:29 |
| wolfspraul | I don't think these connectors are standardized, at best informally | 09:29 |
| wpwrak_ | (more current) because there's always one more thing that wouldn't need its own power supply if USB could just provide a little more ... | 09:29 |
| wolfspraul | but anyway, if the planned R4 connector fits with that one I ran into, I'd say we are on a good path | 09:29 |
| wolfspraul | at least not totally unreasonable NIH syndrome | 09:29 |
| wpwrak_ | and sooner or later, battery charging will speed up, too. and up goes the current | 09:30 |
| wolfspraul | I will keep an eye on lenovo/mainland, usb3, and higher currents. but just remotely, I think the R4 usb strategy is solid | 09:30 |
| wolfspraul | we do what we need and what helps us now, and luckily don't have to catchup with this or that industry trend | 09:31 |
| wpwrak_ | yes, i think we're perfectly mainstream there | 09:31 |
| wpwrak_ | all we need to find/make now is an adapter | 09:31 |
| wolfspraul | oh, the koreans and japanese may have their own informal standards as well, but I think we can safely skip over those :-) | 09:31 |
| wpwrak_ | the startech one is pleasantly simple. just two connectors. not even a cap to make it look more important ;) | 09:32 |
| wpwrak_ | maybe sony ... | 09:32 |
| wolfspraul | yeah but I won't look there, just saying. maybe lenovo if I get to it. | 09:33 |
| wolfspraul | those headers are big, I doubt anything even close would be found on a notebook mainboard. and then I doubt whether there is much desktop mainboard production left in Korea and Japan at all. | 09:34 |
| wpwrak_ | maybe some all-in-one pc. and yes, that's not really laptop technology. let alone tablet, etc. | 09:36 |
| qi-bot | The firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120317-1455/ | 15:34 |
| Action: Fallenou is turning crazy trying to make mmu dtlb tests pass ... | 16:15 | |
| Fallenou | I have something like map(vaddr,paddr); activate_mmu(); read/write disactivate_mmu(); printf("test n°%d", i); if (something) puts("PASS"); else puts("FAIL"); | 16:16 |
| Fallenou | it prints "t" and then the SoC crashes ... | 16:16 |
| wpwrak | maybe it crashes on the (something) | 16:17 |
| wpwrak | or are you sure there is no serial buffer, or if there is, it is flushed before you reach the (something) | 16:18 |
| Fallenou | something is just a test between to "register unsigned int" | 16:18 |
| Fallenou | which are written to during the read/write test | 16:18 |
| Fallenou | between *two* | 16:18 |
| wpwrak | for such extreme low-level things, it may make sense to write to serial like this: while (uart_busy); uart_tx = char; | 16:19 |
| Fallenou | oh yes why not | 16:19 |
| wpwrak | hmm, interesting | 16:19 |
| Fallenou | I thought I was hitting an access to something unmapped while mmu activated | 16:19 |
| Fallenou | like for example receiving an IRQ while mmu activated | 16:19 |
| wpwrak | ah yes, that could get messy :) | 16:20 |
| Fallenou | and then irq handler doing things like sw (sp+0), something | 16:20 |
| wpwrak | if you have multiple such tests, then the "t" could also be from an earlier test | 16:20 |
| Fallenou | but I did something like asm volatile("sw %0, sp" : "=r"(stack) ::); and then map(stack, stack); | 16:20 |
| Fallenou | actually I did a lot of map(a,a); for the entire flash used | 16:21 |
| Fallenou | wpwrak: yes I have 16 tests like this one after the other | 16:21 |
| Fallenou | so the printing could crash while mmu is activated for the next test | 16:21 |
| Fallenou | I should push my tests somewhere to let you see :) | 16:21 |
| Fallenou | but I'm really runing crazy here | 16:21 |
| Fallenou | turning* | 16:22 |
| Fallenou | oh and btw the same *exact* dtlb_load_test() function runs perfectly well on the simulator | 16:22 |
| Fallenou | but with no irq :) | 16:22 |
| Fallenou | and fake printf(); and puts() | 16:22 |
| Fallenou | (to simulate calli playing with stack and ret) | 16:22 |
| wpwrak | so: disable interrupts and poll the UART | 16:24 |
| wpwrak | or make the MMU work with interrupts :) | 16:24 |
| Fallenou | https://github.com/fallen/milkymist-mmu/commit/80185247b9d6cdc39fd6f48a75d3d9a210049ae0 hop | 16:27 |
| Fallenou | I run this modified bios, I cancel flickernoise boot with ESC, and I type "dtlbtest" in the prompt | 16:28 |
| Fallenou | and it runs the tests (and crashes ;)) | 16:28 |
| Fallenou | tests are generated by mmu_test_gen.c | 16:28 |
| Fallenou | my guess is : I forgot to map something | 16:29 |
| Fallenou | but I don't know what =( | 16:29 |
| wpwrak | mmu.c: *inline* void mmu_dtlb_map ? it's "extern inline", so it'll work. but ... | 16:31 |
| Fallenou | 17:29 < wpwrak> so: disable interrupts and poll the UART < ah yes I think there are functions to use uart in poll mode | 16:31 |
| Fallenou | oh yes not sure if the inline is usefull here | 16:32 |
| wpwrak | i guess you could just make this a standalone program, without bios. your_printf("hello. press ENTER to continue."); your_getchar(); ... test ... | 16:33 |
| wpwrak | that's about all the BIOS you'd need, no ? ;-) | 16:33 |
| Fallenou | hum yes :p | 16:33 |
| wpwrak | well, perhaps DRAM setup and such. but in any case not much | 16:33 |
| Fallenou | I just need to read/write uart, and init sdram | 16:34 |
| wpwrak | yup | 16:34 |
| Fallenou | as you can see I tried to map all the irq path down to uart_isr() and it's content | 16:34 |
| Fallenou | so that it would not crash | 16:34 |
| Fallenou | but in vain | 16:34 |
| wpwrak | the inline does two things: a) since it's "extern inline", the function gets placed in the object file. this would also happen if you removed the "inline". b) any function in the same compilation unit using mmu_dtlb_map is encouraged to inline a copy of it. | 16:35 |
| wpwrak | since there are no other functions in the same compilation unit, b) is kinda moot ;) | 16:35 |
| Fallenou | yes I think inline is totally pointless here | 16:36 |
| Fallenou | in the first place mmu should be disactivated in the isr handler | 16:37 |
| Fallenou | and reactivated afterward | 16:37 |
| Fallenou | maybe I could try that | 16:38 |
| wpwrak | does the LM32 actually have some kind of supervisor mode ? | 16:40 |
| wpwrak | (or "kernel" mode, etc.) | 16:41 |
| wpwrak | something it would switch to when there's an interrupt, exception, etc. | 16:41 |
| Fallenou | I think there is no such thing | 16:41 |
| Fallenou | there will be a hidden kernel_mode register in the mmu | 16:42 |
| wpwrak | so that's something we'll need, too. to disable/switch the mmu and also to disable things like wcsr | 16:45 |
| wpwrak | (while in user mode) | 16:45 |
| qi-bot | The firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120317-1634/ | 17:14 |
| lekernel_ | Fallenou: you really should do the tests with simulation first | 18:03 |
| lekernel_ | you have very little visibility on the hardware | 18:04 |
| lekernel_ | who the hell is Kristen Eisenberg and clones (Ute Bachmeier etc.) ?! | 18:46 |
| lekernel_ | seems they repost messages on every single open source project mailing list they can find, e.g. http://seclists.org/nanog/2011/Oct/208 => http://comments.gmane.org/gmane.org.operators.nanog/89959 | 18:47 |
| lekernel_ | or http://naif.jpl.nasa.gov/pipermail/spice_discussion/2011-September/000346.html | 18:47 |
| lekernel_ | time to inaugurate the first ban, I guess ... | 18:48 |
| lekernel_ | strange way to spam for a flight booking website | 18:48 |
| lekernel | oh yeah, and our message is here http://comments.gmane.org/gmane.network.mnet.devel/148 | 18:50 |
| larsc | lekernel: you are in berlin you could visit them and ask them wtf they do | 19:25 |
| lekernel | do I really want to know ... | 19:48 |
| larsc | you asked | 19:55 |
| wpwrak | i think it's pretty clear, no ? | 20:13 |
| wpwrak | they post comments that aren't trivially identified as spam. and they carry their advertisement. | 20:14 |
| larsc | but why would you include your address, telephone number and e-mail address? | 20:16 |
| wpwrak | maybe these are the contact details of the shop ? | 20:17 |
| wpwrak | or maybe it's just an address they picked from the telephone book, to make their spam more authentic, and expecting people who are interested to follow the URL anyway | 20:19 |
| Fallenou | lekernel_: I do both, test are passing in simulation | 20:24 |
| Fallenou | I was trying to understand why they dont on hw | 20:25 |
| Fallenou | I will simplify bios as wpwrak said | 20:26 |
| Fallenou | to use the minimum | 20:26 |
| Fallenou | without isr | 20:26 |
| lekernel_ | roh: http://www.laser-optics-berlin.de/ | 20:30 |
| lekernel_ | Fallenou: you know you can run the BIOS in the simulator, right? | 20:31 |
| lekernel_ | some simplifications will help, of course | 20:31 |
| lekernel_ | and if you use IRQs... of course, an interrupt can fall in the middle of your messing with the TLB, unless you disable interrupts for that time | 20:32 |
| roh | lekernel_: yeah. already found it, but it seems all the talks are with pre-registration | 20:32 |
| lekernel_ | in fact a simple modification would be to encapsulate the TLB test code with irq_disable/irq_enable | 20:32 |
| lekernel_ | you can still use printf() with the interrupts disabled, it will buffer the data | 20:34 |
| lekernel_ | roh: yeah, you need a ticket - or you can just try to crash in, many corporate/academic conferences have lousy security | 20:36 |
| roh | i know *g* | 20:37 |
| roh | sounds quite startrek, but i feel that i'd be quite lost in there | 20:37 |
| lekernel_ | he, if you don't try, you'll never learn :) | 20:37 |
| roh | need to run now. bbl | 20:38 |
| lekernel_ | roh: there's also http://berlin12.dpg-tagungen.de/ one week later | 20:41 |
| roh | hm. i dunno. i am really not somebody who likes fairs | 20:42 |
| roh | it usually takes quite some money payed to me to get me there | 20:43 |
| roh | anyhow. need to run | 20:43 |
| Fallenou | lekernel: the soc.v i use for my simulation does not have any uart | 22:30 |
| Fallenou | just lm32 and sram | 22:30 |
| Fallenou | maybe i should upgrade | 22:30 |
| Fallenou | to a more complete version of milkymist-ng | 22:30 |
| kristianpaul | no uart? ! | 22:33 |
| lekernel | if you fix icarus, you should even be able to simulate and direct it to a pty quite easily :) | 22:51 |
| kristianpaul | or perhaps migen could replace clogb2 in lm32 and provide a generated lm32 that works with icarus as it is :-) | 23:00 |
| lekernel | it's just a problem with clogb2? | 23:02 |
| kristianpaul | from icarus.. well thats the first on the list | 23:02 |
| kristianpaul | but also with some instaciations... | 23:02 |
| kristianpaul | instansiations* | 23:02 |
| kristianpaul | ergh you know :) | 23:02 |
| GitHub46 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/5f281037691419530064eb5e5f50f926ea010649 | 23:16 |
| GitHub46 | [migen/master] corelogic/fsm: delayed enters - Sebastien Bourdeauducq | 23:16 |
| GitHub139 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/XCEm4g | 23:18 |
| GitHub139 | [milkymist-ng/master] asmicon: bank machine (untested) - Sebastien Bourdeauducq | 23:18 |
| wpwrak | an ATM ? that sounds useful. i hope there's a backdoor :) | 23:26 |
| --- Sun Mar 18 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!