<hroth>
It's not all zeros - it just cannot access the bus.
Noskcaj has quit [Ping timeout: 256 seconds]
Noskcaj has joined #imx6-dongle
<hroth>
Also - question about the governor. When I run cpufreq-info it says "no or unknown cpufreq driver is active on this CPU". Do I need to compile a specific module?
<hroth>
Sure. Right now as I compile the kernel it gets too hot (even with the case on). Is there a simple hardcoded way to throttle the cpu?
<hroth>
Thanks, I'll grab that kernel.
<abrasive>
there should be a cur_freq entry in sysfs
<abrasive>
that is writable within a range
<abrasive>
have a find.
<hroth>
Thanks
<hroth>
You must be write about a dodgy kernel. find /sys -name cur_freq doesn't turn up anything.
<hroth>
+right
<abrasive>
i'd look for *cur_freq* actually
<abrasive>
pretty sure it's not calle that.
<abrasive>
also check /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor and /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
<hroth>
Hmmm.. nothing. I'm not the only one it seems. My console is crying "cooling: cpu cur freq is 0" "thermal_notify: trip_hot reached!" and "cooling: can't get cpufreq current operating point!"
<abrasive>
yuck
<abrasive>
get a real kernel.
<hroth>
Yup.
<abrasive>
i think jas built his kernels without cpufreq for a while, maybe he still does
<abrasive>
cpufreq is unstable on vendor u-boots with bad DRAM configuration at boot, but we fixed that in ours months ago
<hroth>
Was hoping to compile my own but I'm having to hit Ctrl-Z.
<hroth>
Yes, this the latest jas kernel from his blog post yesterday.
<hroth>
Whew - has come down from 92 to 66.
<hroth>
Time to "fg" again...
<hroth>
Oops. Have to go - but that kernel you mentioned at neuro.axdf - I'm having trouble with the modules. What is the uname -r for that version of the kernel?
Noskcaj has quit [Ping timeout: 264 seconds]
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Ping timeout: 252 seconds]
Noskcaj has joined #imx6-dongle
<abrasive>
hroth: i'm sorry, i don't recall
<abrasive>
i think it had all the needful compiled in though
<abrasive>
you can't get it to boot?
Noskcaj has quit [Ping timeout: 260 seconds]
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Ping timeout: 264 seconds]
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Ping timeout: 246 seconds]
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Ping timeout: 264 seconds]
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Ping timeout: 256 seconds]
Noskcaj has joined #imx6-dongle
<hroth>
No, couldn't get it to boot properly. It's working now with jas's earlier kernel with cpufreq off his blog. (hosted at miniand).
<abrasive>
fair enough.
<abrasive>
it might have a baked-in commandline that doesn't suit your setup
<hroth>
Still struggling with kernel compilation. I hadn't realized it could throttle the CPU *that* much... dmesg says: "cooling: cpu cur freq is 792 000 000; cooling: cpu max freq set to 792 000" That's a lot lower! Time to cross-compile...
<abrasive>
crossing should be fairly easy. what is your host OS?
<hroth>
Yes should be fine. VMWare Player on an Ubuntu 10.04 (also have a 12.04) server.
<hroth>
One thing is interesting - all these kernels and none of them can read from EDID.
<abrasive>
my $2 is still on the hardware.
<abrasive>
different, if not broken
<hroth>
Yes. I was looking at the Freescale HDMI ref design (which may or may not be the same) and for the HDMI I2C connection it looks like they use the GPIOs. I wonder if I need to enable I2C via GPIO in the kernel... As you said, maybe they moved it onto a different I2C bus.
<abrasive>
i highly doubt it
<abrasive>
only one of the i2c ports supports HDCP, as far as i know
<abrasive>
and on my board, that's the port they used (I2C2 on the chip, which is i2c-1 under linux)
<hroth>
EDID is DRM protected?
<abrasive>
no, but HDCP depends on the DDC link
<abrasive>
the HDCP engine on the chip takes over the i2c link from the host controller
<hroth>
Hmmm. So my V2.4 brethren may have trouble if we actually used HDCP.
<abrasive>
which we never will, so.
<abrasive>
that's assuming that they're using a different i2c port
<abrasive>
there may be some other explanation.
<abrasive>
it does suggest we'll have to figure out how to tell the difference between the revs from software, which doesn't strike me as fun.
<hroth>
I wonder if a better approach might be for me to load in the 1.65.4 Android firmware from Richtechie and look a bit closer at dmesg at boot.
<abrasive>
afaik, they ignore edid entirely
<abrasive>
and force either 720p or 1080p depending on user selection
<hroth>
Oh, interesting..
<hroth>
Well, if they didn't even design for it, I suppose I'll have to force things anyway.
<abrasive>
yes, well. unfortunately the kernel makes it hard to force a video mode that isn't supplied by EDID
<abrasive>
we might need to patch for that if we can't figure out how to get EDID up on your rev
<abrasive>
but if we can, there should be a more elegant solution.
<hroth>
(?) passing through the videomode from u-boot seemed to work fine for me.
<abrasive>
interesting. i've heard of problems.
<hroth>
My main problem was using that old u-boot that has nothing to do with the compiled one to pass through setenv's.
<abrasive>
CEA modes might work OK, there's a table of those in the kernel somewhere.
<hroth>
video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 worked well.
<hroth>
dmesg during boot responds: fbcvt: 1920x1080@60: CVT Name - 2.073M9
<abrasive>
oh, great.
<abrasive>
one more thing off the to-do list then!
<abrasive>
and there's a table of them in the kernel
<abrasive>
but there isn't an equivalent table for non-HDTV modes, even ones that are common in PC monitors like 1280x1024
<abrasive>
so to set those, you need EDID
<hroth>
Oh, I see.
<hroth>
Yes, I have a 16:9 monitor.
<abrasive>
i pushed a very similar patch to theirs to our tree ages ago
<hroth>
Thinking outside the box.. I don't suppose we could add some common VESA modes to mxc_edid.c?
<abrasive>
yes, but i'd still rather fix the problem at the source
Juggie has joined #imx6-dongle
<hroth>
Sure. I just find it rough when the designers themselves ignore EDID.
<abrasive>
it's a bit crap, but as far as whitebox designs go, it's reasonably solid.
<abrasive>
when I was working on linux for WM8505 based netbooks a few years ago, i found out that about half the machines in the wild had the SD card write protect line backwards relative to the other half
<hroth>
I just mean in some revision they could have taken over the i2c clk or data for some other purpose and they wouldn't care about it.
<hroth>
I think it's still a bargain for $69.
<abrasive>
yeah, i don't know what the reason for the engineering change might be. maybe they just left off the parts to save cash. you've still got 3 SOT23 transistors next to the HDMI connector, right?
<hroth>
Hold, please.
<abrasive>
it's a great deal. based on freescale is a great win. it's only the 3d/video support that's closed and consequently shitty
<hroth>
Those chips are very tiny. I'm assuming, yes.
<abrasive>
yeah, little 3-legged things
<hroth>
(Are they on the same side as the CPU?
<abrasive>
can't remember. probably.
<abrasive>
they're on top when the board is in its sled
<hroth>
Yep, 3x 3-legged things.
<abrasive>
so they haven't ditched the functionality.
<abrasive>
it's just not working!
<abrasive>
when you get a chance to get a scope on to them then can do some debugging.
<hroth>
Yes. After getting set up on the Bus Pirate first to look at the I2C I just realized it's the wrong i2c bus.
<abrasive>
?
<hroth>
Let me grab my scope.
hste has quit [Ping timeout: 240 seconds]
<hroth>
Alrighty.. All set. What do you suggest I capture with the scope.
<hroth>
Just curious. Is anyone working on integrating the on-board bluetooth/FM radio?
<abrasive>
BT works.
<abrasive>
or so i hear
<abrasive>
FM i'm not sure if the audio is wired in
<abrasive>
so, the USB connector shield is a good place for your ground clip
<abrasive>
i suggest looping some i2c access in the shell
<abrasive>
then probing around those transistors i mentioned
<abrasive>
the single transistor on one side translates SCL from 3.3 to 5 volts
<abrasive>
and the pair on the other side push SDA between 3.3 and 5 also
<hroth>
You just want to make sure they are level shifting properly?
<abrasive>
you should be able to see the bits coming past
<abrasive>
i doubt it's the shifting that's the issue, but either there's a signal integrity problem, or it's the plain old wrong bus
<hroth>
ok. how fast is this bus supposed to be?
<abrasive>
100khz
<hroth>
ok.. just perturb it with the i2cdump?
<abrasive>
yeah. i'd do something like
<abrasive>
while true; do echo Y | i2cdump...; done
<hroth>
hmm. no dice. It just streams "Error: Could not set address to 0x50: Device or resource busy" across the screen and there's nothing actually there.
<hroth>
They are all pretty much flat at ground.
<abrasive>
the "device or resource busy" comes from not getting an ACK from the device, i think
<abrasive>
hroth: is there any activity on the other pins on the serial header connector?
<abrasive>
i think a couple of them are attached to one of the i2c buses
<abrasive>
also, if you can try with the other numbered i2c buses, that'd be good.
<hroth>
Looked there too.. it says "I2C 3" on the cnx-software blog post but I don't see "3" on my available devices. I *can* i2cdump dev 2.
<hroth>
Boy, tried it on the header and there's nothing. I'll speak Bus Pirate to that exposed bus and see what it says.
<hroth>
Are there any headers or signatures for the EDID block?
<abrasive>
if it's not coming up on your scope, nothing's doing.
<abrasive>
um, probably.
<abrasive>
but i2c idles high
<abrasive>
so that suggests the pins are not being properly configured.
<abrasive>
which u-boot are you using? it shouldn't matter, but...
<hroth>
Right.. I'm using jas's u-boot_multiboot.imx. The Bus Pirate does speak i2c so I can inquire 0x50 but don't know if there's a fast way to see if EDID is read out there.
<abrasive>
do you have gpiodev on your system - is /sys/class/gpio present?
<hroth>
yes.
<abrasive>
okay. so, we can try and figure out which SoC pin those i2c lines are wired to.
<abrasive>
let me quickly clone the kernel source here so i can dig along
<hroth>
Right..
<abrasive>
so... candidates for I2C2 SCL are GPIO_2_30, and GPIO_4_12
<abrasive>
the latter is the default used by our kernel
<abrasive>
the kernel pin numbering is different to the SoC bank numbering (sigh) so the number is (2-1)*32 + 30
<abrasive>
which is 62 if today is a good day
<abrasive>
so echo 62 > /sys/class/gpio/export, echo out > /sys/class/gpio/gpio62/direction, and echo 1 > /sys/class/gpio/gpio62/value
<abrasive>
then if that was the right line the SCL output (single transistor side) will now be high.
hroth920 has joined #imx6-dongle
<hroth920>
Got it.
<abrasive>
and if that doesn't work... we might have to be a bit more creative
<hroth920>
Dumb question - how do you know it is I2C2 that is the bus (say, instead of I2C3)?
<abrasive>
i'm assuming that they're still using it because it's the only one that muxes with HDCP
<hroth920>
Got it, again.
<hroth920>
Give me a few minutes..
<abrasive>
no rush :)
<hroth920>
Actually, do you have the GPIO for I2C3 ? That's the one brought out on the serial header and I'd feel better with a known good to make sure my testing jig is working.
<hroth920>
Those three are all possibilities for I2C3 SCL?
<abrasive>
yep
Noskcaj has joined #imx6-dongle
<hroth920>
It's only $69 but any idea on where else I might be asserting high... ? :)
<abrasive>
if the iomux on those pins isn't configured for GPIO (which most are by default, i think, but not all), then that might not get you far
<abrasive>
you could use the method i used to find the wifi enable GPIO - just set every available GPIO to high, then if that gets you there, binary search for which one you're looking for
<abrasive>
for i in `seq 0 256`; do [set pin to output] [set pin to high]; done
<abrasive>
that's the easiest way to find if any of these pins are set to gpio...
<hroth920>
If I can echo the pin number to the console this might not require a binary search.
<hroth920>
Not sure I have the hang of the algorithm there, though.
<abrasive>
well, i did it with echoing and pausing between each pin
<abrasive>
but if you just want to know up front if this is going to work, just set them all high and figure it out later :)
hroth920 has quit [Quit: irc2go]
<hroth>
Hmmm... 3, 5, and 81 didn't make I2C3 SCL assert high.
<hroth>
Let me check them all... after I compile my kernel.
<hroth>
Perhaps I'm not doing something correctly... but nothing happened. gpio0, gpio32, gpio171, gpio224+ didn't write but the others did and no dice.
<abrasive>
then the muxes are set to something else.
<abrasive>
it could be that they *are* set to i2c and that something is wrong in its initialisation or similar
Noskcaj has quit [Ping timeout: 252 seconds]
<hroth>
Well, I'll have to pack it in - but just continue the IRC and I'll check tomorrow on any other ideas you may have.
<hroth>
From the IRC log
<abrasive>
thanks for the efforts, it's very illuminating
<abrasive>
i (and all other users of that revision!) appreciate it :)
<hroth>
Not a problem; you guys are doing a tremendous job of making a $69 SoC dev board.
<hroth>
PS: Are there any logs/posts on that Bluetooth working? I haven't seen it in any kernel I've looked at.
<abrasive>
um.
<abrasive>
you can get it chatting with hciattach
<abrasive>
i haven't actually gotten any further than that, but that does work
<abrasive>
it may be that we aren't configuring the pinmuxes though and that only worked with vendor u-boot, but that's highly unlikely
<abrasive>
i think it's on ttymxc1 if you want to give it a try
<hroth>
I'll try that.
<projectgus>
abrasive: do you need to compile a special hciattach with an 'rda' mode? I found a source download for that the other day
<abrasive>
you do if you want to go above 115200 baud
<projectgus>
but I haven't tried using it either in a generic mode or with the patched hciattach
<projectgus>
oic
<abrasive>
i *think* it works fine with generic
<abrasive>
it attached without error and read the BD addr
<abrasive>
i couldn't get it to see my stupid ipod though
<projectgus>
yay standards!
<abrasive>
bluetooth is such a dog.
<projectgus>
the more i learn about either bluetooth or usb the less i want to learn about them
<projectgus>
also, the more impressed I am that things mostly work most of the time
<abrasive>
yeah.
<abrasive>
i really like speaking native USB in devices though
<hroth>
abrasive: I could hciattach and read hci0 's address with hcitool ; but the Xubuntu Bluetooth Devices hasn't found a thing, including my mouse.
<abrasive>
hroth: then maybe we do need this RDA-patched tool
<abrasive>
or, there's some sort of GPIO enable we're missing
<projectgus>
datasheet doesn't seem to imply any hard rfkill type feature
<abrasive>
no, i don't see one on the pinout
<abrasive>
and the coex signals are probably not used
<abrasive>
given the wifi module doesn't bring them out
<abrasive>
any hints in the hciattach code about radio enables or anything?
<projectgus>
i haven't even unpacked the rar file yet
<abrasive>
or the LDO_ON pin...
<abrasive>
sorry for backseat driving here, i'm working on something totally unrelated :)
<projectgus>
I think the LDO is for the FM receiver but it's hard to be sure
<projectgus>
I'm just about to test run the graphical version of the debian installer
<projectgus>
then I was going to poke around with bluetooth a bit
<hroth>
On the Kconfig for tcc_bt_dev it states: tristate "TCC Bluetooth dev Control power"; if you say Y here, you can control the power of the BT H/W Module.
<projectgus>
their board might have a gpio used to power it on/off
<abrasive>
i might have a poke when i get home too
<projectgus>
awesome, their C file is commented in chinese, and less doesn't like that :)