<kristianpaul>
but i wonder if the Loongsoon follow MIPS arch at all
<larsc>
yes, they even got a license from MIPS
<kristianpaul>
hmm yes
<kristianpaul>
even i think next cpus will run x86 instructions
<kristianpaul>
rafa: did wotk for you that folder?
<kristianpaul>
.
<rafa>
kristianpaul: I have not tried yet, I am reading how qt works for different platforms and how to crosscompile using that
<rafa>
kristianpaul: from that I am reading we have all the tools on repository to do that, but no sure to build on nn, I'm talking about crosscompile
<kristianpaul>
hmm
<kristianpaul>
is too hard got wt build env on jlime?
<rafa>
mmhÂ?
<rafa>
?
<rafa>
what?
<rafa>
sorry, I did not understand that
<rafa>
kristianpaul: what did you mean?
<kristianpaul>
i wanr type qmake
<kristianpaul>
and got my ADC
<rafa>
so you already built?
<rafa>
kristianpaul: btw, qmake just generates Makefiles to build
<rafa>
kristianpaul: after that you need to run make to build
<kristianpaul>
ajap
<kristianpaul>
hm
<kristianpaul>
so
<kristianpaul>
there is QT build Envrioment avaliable for Jlime?
<kristianpaul>
is this the qt4-core package?
<rafa>
kristianpaul: I have no idea.. trying to learn about that right now.. if you look for qt on repositories you will find around 300 packages. SO better I read a while about qt development :) (i am reaking nokia docs currently)
<kristianpaul>
o
<kristianpaul>
k
<Ornotermes>
is any one familiar with linux (software)sd-stack?
<viric>
Where is tuxbrain, btw?
<viric>
I wonder, is anyone going to sell SIEs ?
<kristianpaul>
viric: seems is sold out for now
<kristianpaul>
i hear SIEv3 is coming
<kristianpaul>
may be juan64bits can tell more about next SIE version and next production date?
<juan64bits>
the design  v3 is in process.... carlos camargo know more about that ...
<juan64bits>
about date
<viric>
ahh really out?
<viric>
impressive :)
<viric>
and how much were v2?
<viric>
have them to be...mmmm  "encargados"?
<viric>
kristianpaul: I know that word in Spanish and not in English.
<viric>
pues, hace falta encargarlos?
<kristianpaul>
no se si ya se pueda
<viric>
ok
<kristianpaul>
i dont know if is posible order SIE now
<B_Lizzard>
larsc, did I ever mention that 2.6.36 doesn't give me console output on boot and shutdown other than the initial kernel messages?
<B_Lizzard>
I think that also prevents stuff like psplash of running during boot
<larsc>
B_Lizzard: thats probably just a config issue
<B_Lizzard>
cmdline seems OK... I'm using the config from projects.qi-hardware...
<B_Lizzard>
Lemme check
<B_Lizzard>
Which config option would that be?
<B_Lizzard>
:/
<B_Lizzard>
Hmmm, maybe it's not a kernel issue.
<B_Lizzard>
Yeah, probably not a kernel issue...
<B_Lizzard>
What could it be?
<B_Lizzard>
I see in cmdline that console is defined twice, one with tty0 and one with ttyS0
<B_Lizzard>
Maybe stuff is ending up in the serial console?
<larsc>
if its in the cmdline twice it should end up on both consoles
<B_Lizzard>
You mentioned a kernel config that could be responsible?
<larsc>
uff
<larsc>
hm, framebuffer console is enabled
<B_Lizzard>
Maybe CONFIG_FB_VIRTUAL?
<larsc>
no
<B_Lizzard>
Hmmm
<B_Lizzard>
It's not my sysvinit either
<B_Lizzard>
I can't think of anything other than the kernel
<B_Lizzard>
Most definately is the kernel, I'm getting messages from init with 2.6.34 and no messages with 2.6.36
<larsc>
ok
<wpwrak>
Ornotermes: i worked with it some time ago (~2 years)
<Ornotermes>
wpwrak: i was thinking of digging in a bit in it to see if it would be at all possible to make a cheap mcu of some kind emulate a block device over 4-bit MMC/SD (instead of using gpio), what do you think?
<wpwrak>
Ornotermes: hmm, if you can find an MCU with a built-in SD device controller. i've never seen such a thing, but i guess it must exist somewhere
<wpwrak>
Ornotermes: i think it would be difficult to get the bus timing right just with software. maybe in 1 bit more, but i'm not even sure about this.
<Ornotermes>
wpwrak: i dont expect to find that, but since it is possible to use a cheap 8bit avr to bitbang usb with 1.5Mbit/s it soesent seem unlikely to work with SD either
<Ornotermes>
people have done incredible things with simple hardware
<wpwrak>
hmm, it would depend on the ability to slow down the clock sufficiently
<Ornotermes>
i was thinking of looking a bit at old SD hardware
<wpwrak>
okay, low-speed SDIO is not too demanding. only 400 kHz, with 4 bit being optional. so it's 400-1600 kbps
<Ornotermes>
the problem is SDIO, not all hardware supports it
<Ornotermes>
there for i want to emulate a block device
<wpwrak>
interesting idea ... :)
<wpwrak>
hmm, what's the problem with SDIO ? you'll probably need some driver for your peripheral anyway
<Ornotermes>
i think the spectec wifi cards works as block devices and there for don't require hardware with sdio
<wpwrak>
that is, unless it's really just storage
<wpwrak>
really ? that would be quite odd. possible but odd.
<wpwrak>
but what problem are you trying to solve anyway ? on which host that's sd-capable but not sdio-capable do you want to use your peripheral ?
<Ornotermes>
wpwrak: i might be wron, but i think i heard/read something about wificards looking as block devices
<wejp>
there are these special wifi sd cards that work in arbitrary devices using sd slots. those work just like storage devices, but "normal" wifi sd cards always use sdio
<FrankBlues>
waves
<Ornotermes>
wpwrak: the problem is bens lack of expandability, and i rather put the load of bit banging on a external mcu rather than the cpu
<Ornotermes>
and a device that works on other hardware than just ben could be very useful not only for us
<wpwrak>
hmm, i see. not sure how efficient that would be, though. without sdio, you don't have interrupts. so you'd have to poll the card for events.
<Ornotermes>
and yes, some sort of driver would probably be needed, but it could even be a virtual fs that lets the software sun in usermode
<Ornotermes>
wpwrak: off course that is something worth taking under concideration but i still think it would be better than bitbanging things like spi from the sd-port, also it could give a whole buch of extra gpio
<wpwrak>
hmm, with caching and all that, you'd heavily depend on the host operating system's internals for this to work.
<Ornotermes>
does linux cache on block device level? i thought it cached on filesystem level?
<wpwrak>
what's nice about big-banging from the host is that you can make very simple and dumb boards. also, all the software sits on the host, so you don't need yet another cross-chain, knowledge about an MCU architecture, tools to flash the MCU, etc.
<wpwrak>
Ornotermes: linux caches on the block level. some file systems may have additional caches. e.g., msdos(fs) has a read cache for the FAT.
<Ornotermes>
wpwrak: the bad thing with bit-bang is that it takes more cpu time than the mmc-interface
<wpwrak>
yes, that's true
<Ornotermes>
i see, i thought it only cached on filesystem level because there is options like sync
<wpwrak>
of course, if you need to go from interrupt to polling, that may be even more expensive. but i could see a point in implementing SDIO with an MCU.
<wpwrak>
(sync) the file system can tell the buffer cache when it wants data to be committed to disk. (if it's that what you mean)
<Ornotermes>
maybe it would be possible to have both even, mainly SDIO but failover to SD if there is no SDIO
<wpwrak>
sure. there are a lot of possibilities :)
<Ornotermes>
any way, was thinking of trying some stuff on stm32 (if i get things working)
<Ornotermes>
and i think the linux source is a good way to get information
<wpwrak>
if you wan to implement an SD/SDIO device, the linux kernel isn't so helpful. you'll eventually have to look at it, because there will be bugs and it helps if you can catch things at a lower layer :)
<wpwrak>
what you need to understand are the SD and SDIO specs.
<Ornotermes>
yeah, it is atleast woth a shot
<wpwrak>
if you have a scope with at least 3 channels, that helps too. there's even an SDIO decoder in my TMC package.
<wpwrak>
(channels) digital is sufficient. e.g., an MSO with 2 analog and some digital channels is fine. or some logic analyzer. unfortuntely, there are very very few PC LAs that are linux-friendly
<Ornotermes>
i also have a board since before with stm32 that i never have put to use (avr works too good with linux :P)
<Ornotermes>
sadly i only have a cheap 2 channel scope
<Ornotermes>
but i have a bus pirate
<Ornotermes>
but that is probably too slow
<wpwrak>
(bus pirate) says up to 1 MHz logic analyzer. that shuold be enough for a low-speed SDIO card (400 kHz)
<Ornotermes>
wpwrak: sounds good
<Ornotermes>
wpwrak: i also got an idea how to slove the polling issue(if it works)
<Ornotermes>
if one would like to get the status and reads a status block, what if it instead of returning 0 would wait to return anything at all til there is something to report?
<Ornotermes>
steve|m: i saw it earlier today, it's a really cool project
<wpwrak>
(status block) hmm, but once you read it, it would be caches. also, if you don't respond, you get a timeout. so the host will think there's an i/o error.
<Ornotermes>
the cache is ofc a problem again
<Ornotermes>
one could read new adresses all time but that would probably cache out everything else
<wpwrak>
you would recycle cache entries, yes. also, there is readahead. so the file system may decide to read more than just one block, assuming you'll want the other blocks as well.
<Ornotermes>
hmmm, true
<lekernel>
(old mac) why do i find that boring...?
<wpwrak>
Ornotermes: an SDIO implementation with an MCU should be feasible. however, one problem is that you'll still have very tight timing if you bit-bang the I/Os. i.e., you couldn't do more than one timing-critical thing reliably in this device.
<steve|m>
lekernel: well, I like the linux framebuffer-via-usb thing most interesting :)
<steve|m>
*find
<wpwrak>
Ornotermes: i'm not sure how v-usb does it. i would suspect that it either had the same restriction or that it heavily relies on USB's built-in retransmission mechanism
<Ornotermes>
wpwrak: yes, i will try to find out how sd(io) select the clock speed
<wpwrak>
Ornotermes: if your MCU has DMA (or large FIFOs), you may be able to mitigate the timing issues, though.
<Ornotermes>
and i don't really know how v-usb does it, what i know is that it requires at least 12MHz to work and reads input on a hardware interupt pin
<wpwrak>
pages 29 and 32
<lekernel>
does what? (sorry didn't follow)
<Ornotermes>
lekernel: how v-usb handles usb bit banging
<lekernel>
hand crafted asm
<lekernel>
on avr all instructions execute in a fixed time, so all you have to do is some asm wizardry so that the bits are out at the right time
<wpwrak>
lekernel: the question is: how do you get anything else done, besides USB communication ? there doesn't seem to be much tolerance, unless you accept that you may miss a transmission from time to time.
<lekernel>
interrupts I guess
<lekernel>
no?
<Ornotermes>
still, even if one use interupts it might take a buch of tics from triggering till the software get to check it
<lekernel>
no, the interrupt latency on AVR is low
<lekernel>
and aren't you able to use GPIO-triggered interrupts?
<lekernel>
ie get an irq when some external pin changes value
<steve|m>
my experience with v-usb is that it works quite reliable, even if a bunch of other interrupts are active (3 timers, TWI, SPI, etc.)
<Ornotermes>
lekernel: i don't relly know but what i read v-usb needs the highest dedicated interupt in use
<wpwrak>
steve|m: would be interesting if someone dug into it and figured out how many spare cycles it really has.
<wpwrak>
steve|m: or if it causes long "blackouts" during which interrupts are blocked
<wpwrak>
steve|m: e.g., can you make an interface for sustained SPI input to USB, without losing SPI data ?
<wpwrak>
steve|m: if yes, how many USB transmission do you lose ?
<wpwrak>
steve|m: and of course, up to which SPI clock rate ?
<lekernel>
you could just use a ftdi-chip for that :)
<steve|m>
wpwrak: it worked fine for 200kHz I2C with an atmega168 @ 12MHz without any loss.. no data on spi
<Ornotermes>
wpwrak: most AVRs have hardware spi
<wpwrak>
lekernel: so you're supporting chips that are largely undocumented ? :)
<lekernel>
that or the AVR, it doesn't make much difference
<lekernel>
and the ftdi is faster and less work to get working
<wpwrak>
steve|m: I2C master, slave, or both ?
<steve|m>
wpwrak: master only
<wpwrak>
lekernel: depends a lot on which FTDI and what you're trying to do. e.g., i got burned with the FT232 and bit-banging. the darn thing just doesn't work reliably.
<wpwrak>
steve|m: okay, that's not a challenge ;-)
<steve|m>
in support of the FT2232 I have to say that it works fine as jtag adapter and supports odd baudrates :)
<wpwrak>
steve|m: as long as you can control the timing of anything besides the USB, you're fine. also, if the other thing gives you plenty of time to respond (e.g., enough to process a USB packet), you're fine too.
<steve|m>
what about one of those avrs with usb? Atmega8U2 or something
<Ornotermes>
well, time to sleep
<Ornotermes>
good night every one
<wpwrak>
steve|m: the FT2232 seems to be okay (except for the documentation situation, of course). but the FT232 seems to have issues. of course, without proper documentation, it's hard to tell where the problem is. maybe the chip itself is fine, just nobody has figured out how to use it correctly.
<wpwrak>
steve|m: V-USB was just an example for a timing-critical protocol implemented in software. what we're after is SDIO. also there, you need to respond quickly when the host sends a command.
<wpwrak>
lekernel: how long until you'll have your own fab ? ;-)
<wpwrak>
and we have a new name for notches in corners. mousebite. this thing also exists in the cnc world, where you have to mill into a concave/inner corner if you want to fit something with a rectangular corner.
<steve|m>
wpwrak: ah okay.. quite some time ago I built a time-lapse cam and wanted to transfer the images via wifi.. one idea was to emulate an sd-card, but instead I went for a sd/usb dual card, toggling the "battery compartment open" switch to unmount the card, move the pics off, remount, take next picture etc.
<wpwrak>
one name i found there was "dogbone", referring to the orientation of the notch (you could have the same effect with an infinite number of different notches. "dogbone" is evenly placed beteen the two sides. "t-bone" would mill only into one, not the other, etc.). not sure if that's official, though.
<wpwrak>
steve|m: cool ! :) how did you implement the "SD card" ?
<steve|m>
wpwrak: well, I didn't implement it, I cheated an used something like that: http://cache.gizmodo.com/assets/resources/2006/06/buffalosd.jpg .. so I controlled the gpios of the cam with an avr and "unmounted" the card by toggling the battery compartment switch.. the card was connected via usb to a router with openwrt, where the card then was mounted etc.
<steve|m>
didn't use it that long, but would have been interesting how long it'll take until the card fails :)
<qi-bot>
[commit] Werner Almesberger: Document that the input circuit does not reach the design frequency (3 MHz) yet. http://qi-hw.com/p/ben-wpan/8cb17bb
<qi-bot>
[commit] Werner Almesberger: Added burst counter mode to cntr tool, plus assorted small improvements. http://qi-hw.com/p/ben-wpan/df1706f
<qi-bot>
[commit] Werner Almesberger: cntr/README: cntr -r always returns an error, so we cannot use it with && http://qi-hw.com/p/ben-wpan/43f0bce