<lekernel>
introduced by commit 7c12ea66a7133c7631cb88de629b01217f4eca58
<lekernel>
also, moving the LUT results in #E Internal error in control.c:2513
rz2k has joined #qi-hardware
wej has quit [Ping timeout: 245 seconds]
jekhor has joined #qi-hardware
jekhor has quit [Ping timeout: 258 seconds]
<kuribas>
Are the pins of the jz4755 multiplexed? If they aren't, then I don't need to know the schematic of my device, right?
<kuribas>
If I know the chips used.
<larsc>
they are
<kuribas>
Hm...
<kuribas>
Is it safe to probe the circuit with a multimeter to test the connections?
<larsc>
well don't blame we if stuff explodes, but it should be ok
<larsc>
If you know how to get the device into usbboot mode you can dump the firmware and can try to run it in qemu
<larsc>
to see how it configures the pins
<kuribas>
I didn't try it yet, but there is a keypress/boot combination to get it into usbboot mode.
<kuribas>
You think that's easier than probing with a multimeter?
<larsc>
For some things it's pretty hard to probe with a multimeter
<larsc>
you can figure out stuff like buttons and leds
<larsc>
but e.g. figuring out how the display is wired up is going to be harder
<larsc>
I did this once for an e-book reader and started out with probing pins and toggeling the gpios, but later had to run things in qemu to find out everything
<kuribas>
Oh I see. I have no experience with running qemu, so I'll have to figure that out.
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
emeb has joined #qi-hardware
dandon_ has quit [Quit: .]
dandon has joined #qi-hardware
<larsc>
Do you know the feeling when after a major codechange everything just works and you think that you must have used an old binary?
jekhor has joined #qi-hardware
Calyp has quit [Ping timeout: 256 seconds]
<viric>
yes
emeb has quit [Quit: Leaving.]
emeb has joined #qi-hardware
jekhor has quit [Ping timeout: 255 seconds]
xdpirate has joined #qi-hardware
Calyp has joined #qi-hardware
<whitequark>
larsc: you know how underhanded c code contest exists?
<whitequark>
we could make a similar one for EE
<whitequark>
make an innocently looking device which will exhibit weirdest (not necessarily harmful) behavior when poked with common tools
<whitequark>
bonus points for actually occuring in production code :p
<larsc>
and the winning entry will be a xilinx fpga ;)
<whitequark>
hehe
<whitequark>
larsc: (major codechange) most often you DO use an old binary
<whitequark>
then you launch the new one and it leaves a 8 GB core dump
<whitequark>
(*something* actually leaves 8GB core dumps on my machine periodically... I think they would be larger but it ENOSPC's before it ENOMEM's
<larsc>
in this case it worked fine. I rewrote the jz4740 dma/audio pcm code. 12 files changed, 670 insertions(+), 715 deletions(-)
<larsc>
and I was quite puzzeld when it worked on first try
<whitequark>
neat
<whitequark>
why do you work on that code? free time? university project? self-education?
<larsc>
I wanted a non ARM architecture that uses the new ASoC dmaengine PCM driver
<pcercuei>
< larsc> in this case it worked fine. I rewrote the jz4740 dma/audio pcm code.
<pcercuei>
WHOHOU!
<pcercuei>
mth, hear this?
<pcercuei>
maybe it'll fix the nasty sound bug we were having
<larsc>
and we now have the infrastrucutre to add dma support to the mmc driver
<pcercuei>
WHOHOU!
<pcercuei>
mth, hear that?
<larsc>
almost three years late, but better late than never
<pcercuei>
certainly
<pcercuei>
we have to deal with a crappy MMC driver for the jz4770
<pcercuei>
I hope in the future we can adapt yours
<larsc>
is it the same core?
<pcercuei>
it's an Xburst, yes
<larsc>
I mean the MMC IP core
<pcercuei>
I believe, yes
<pcercuei>
the main difference is that the jz4770 handles 3 MMCs slots
<larsc>
if it is three times the same core that shouldn't be much of a problem
<pcercuei>
well, when porting UBIBoot from the jz4740 to the jz4770, I didn't touch at all the MMC code
<pcercuei>
I mean, it even includes "jz4740.h" inconditionally
<pcercuei>
so I'm pretty sure it didn't changed
<pcercuei>
change*
freemor has joined #qi-hardware
<larsc>
btw. I pushed out a jz-3.9-rc8 earlier today
<larsc>
seems to work fine except for the usb gadget driver, which crashes
<larsc>
maybe that's a sign that we should bury it
<pcercuei>
why bury it?
<larsc>
and replace it with the musb gadget driver
<pcercuei>
ok
<Fallenou>
musb IP is an OTG ip core, right ?
<larsc>
yes
<larsc>
but the jz4740 only uses the gadget part
<larsc>
I think later versions like the jz4770 use both
<Fallenou>
the OMAP3630 has mUSB ip core as well
<Fallenou>
don't know if it's the same
<Fallenou>
but I can say that we had a lot of troubles with musb, used as Host
<Fallenou>
but it seems to works well as device
<Fallenou>
work*
<lekernel>
anyone looked at fpgatools close enough to know what the "S0N3" stuff is about?
* Fallenou
didn't look very close at fpgatools
jekhor has joined #qi-hardware
jekhor has quit [Ping timeout: 245 seconds]
emeb has quit [Quit: Leaving.]
<larsc>
pcercuei, mth: oh, and I dropped "cpufreq_stats: Support runtime changes to frequency table" from the 3.9 tree, because the patch is one big conflict and I have no idea how to fix it
<mth>
that patch is a pain; I always hope it merges without conflicts, but every now and then it doesn't
<mth>
unfortunately, the cpufreq driver for JZ4740 is pretty useless without it
<mth>
the cpufreq support in the mainline kernel assumes a fixed max clock and configurable dividers
<mth>
but what we do is change the PLL freq
<mth>
I'm in favor of switching over to musb
<mth>
that means less differences between 4740 and 4770
<mth>
and less code to maintain
<mth>
on 4770 the musb core indeed supports both host and device mode, as well as runtime switching between those modes
<larsc>
I just had a look and it seems that the driver currently doesn't support gadget only
<larsc>
but I think it should be possible to add that
<mth>
they removed support for that a few releases back
<mth>
but I think you can force it into device mode and just never used the host mode code (even though it will be compiled in)
<mth>
s/used/use/
<qi-bot>
mth meant: "but I think you can force it into device mode and just never use the host mode code (even though it will be compiled in)"
<wpwrak>
larsc: (udc crash) same thing here :-)
<wpwrak>
(i also tried to "modernize" the old driver for 3.9)
<larsc>
It didn't even compile for me without updating the interface
<mth>
I haven't tried 3.9 yet, but on 3.8 the 4770 glue for musb still works fine
<mth>
pcercuei: which audio bug are you referring to? being prone to underruns or the weird siren effect?
<pcercuei>
the siren effect, yes
<mth>
that's caused by the power up sequence, not by the delivered data
<mth>
so this rewrite won't fix that
<pcercuei>
:(
URUS has joined #qi-hardware
<mth>
the programming manual tell you how to avoid it, but that means adding a pretty complex state machine in the driver
<pcercuei>
yes
<wpwrak>
larsc: well, they changes the names of some operations ...
URUS has left #qi-hardware [#qi-hardware]
<wpwrak>
... and their parameters (and of course, what's going on inside. massively)
<wpwrak>
hmm, gadget->speed == 3, which would be USB_SPEED_WIRELESS. that sounds suspicious
<wpwrak>
ah no
<wpwrak>
SPEED_HIGH. all good.
<wpwrak>
who the heck puts two values in the same line in an enum ?
<wpwrak>
the problem seems to be max_speed
<wpwrak>
it's 0. this confuses gadget_is_dualspeed which in turn causes the hs_descriptor not to be copied
<larsc>
yea, just thought the same
<larsc>
or maybe not
<wpwrak>
let's see what happens :)
<wpwrak>
kernel looks happy
<wpwrak>
and lets me log in :)
<larsc>
good
<wpwrak>
fun fact: it works better if you set max_speed in udc_disable, not udc_enable :)
<larsc>
can't we set it in probe?
<wpwrak>
does udc_reinit sound like a fair compromise ?
<wpwrak>
and one of these days i have to teach my "fk" script to ignore ssh ...
<wpwrak>
there, done :)
<qi-bot>
[commit] Werner Almesberger: bin/fk: add option -u to force usbboot, even if SSH is/seems available (master) http://qi-hw.com/p/wernermisc/040911f
<larsc>
btw. with lzma compression the defconfig image easily fits into 1.5MB
<wpwrak>
don't we have some 2 MB in that partition ?
<wpwrak>
my image is now 1.7 MB (gzip), apparently without problems
<larsc>
but that's not defconfig
<larsc>
anyway, time to call it a night
dandon has quit [Quit: .]
<wpwrak>
ah, missed the defconfig. wow, that's pretty nice then
Jurting_pc2 has joined #qi-hardware
dandon has joined #qi-hardware
Jurting_pc2 has quit [Read error: Connection reset by peer]