**** BEGIN LOGGING AT Fri Oct 30 02:59:59 2015 Oct 30 03:23:52 I'm getting a lot of input/output errors on my beaglebone black Oct 30 03:23:56 [ 3262.057865] mmcblk0: error -110 sending status command, aborting Oct 30 03:24:01 [ 3262.064282] end_request: I/O error, dev mmcblk0, sector 797792 Oct 30 03:24:13 has anybody else encountered this problem? Oct 30 03:25:03 or is my disk dying Oct 30 03:34:45 looks like bad sd Oct 30 03:35:35 yeah unfortunately Oct 30 03:35:44 I've only had this one for 3 months... Oct 30 05:49:37 how to make beaglebone to appeare as usb composite device?? Oct 30 09:38:48 Hi Oct 30 09:39:16 did anyone get it working on a Mac OS x El Captian Oct 30 09:45:59 IT! Oct 30 10:03:39 he meant "did anyone build a kernel/image yet with CDC-EEM enabled instead of RNDIS?" Oct 30 10:24:45 zmatt: register interfaces are awesome at sucking donkeyballs Oct 30 10:57:03 hehe Oct 30 10:58:02 I really love it when they take an 8- or 16-bit interface and then wire it onto a 32-bit bus, turning the upper halves into unused zeros Oct 30 10:58:38 especially if the original interface contained 32-bit registers (now split into two halves across two 32-bit registers) and both original and new interface are fully byte-addressable Oct 30 10:58:45 -.- Oct 30 10:58:55 * zmatt pees on the I2C peripheral Oct 30 10:59:27 then again the I2C peripheral is special anyway (special in the "dropped on the head as a baby" sense of the word) Oct 30 10:59:46 <_av500_> bitbang i2c like normal people! Oct 30 11:00:29 _av500_: that's also not trivial to get genuinely right, but yes bitbanging is actually often a good alternative Oct 30 11:00:50 <_av500_> zmatt: everybody needs to run into i2c clockstretching once in his life Oct 30 11:01:19 preferably not on an rpi though, since its i2c controller causes random data corruption if a slave dares to use clock stretching Oct 30 11:01:25 <_av500_> lol Oct 30 11:01:42 <_av500_> zmatt: but thats the reason why one usually gives up on the builtin I2C Oct 30 11:02:01 is it really that bad? Oct 30 11:02:18 originally we had a board with a TI SoC on the main board and an STM uC on the aux board Oct 30 11:02:51 I2C connected across so both processors could access all peripherals (since both were multi-master capable) and in principle also communicate with each other Oct 30 11:03:41 I actually ended up writing an I2C debugger on the STM (using gpio) that used clock stretching to allow you to single-step through an I2C transaction bit by bit, so I could check wtf the TI I2C controller was doing Oct 30 11:04:32 eventually I asked the hw guys to cut the traces and have the TI and STM each manage their own peripherals only, since it became clear there was no way in hell multimaster operation was ever going to work reliable Oct 30 11:04:47 jacekowski: yes it is Oct 30 11:05:22 so, to sum it, up, USB is shit and I2C is shit? Oct 30 11:05:25 on rpi Oct 30 11:05:52 Also, most I2C controllers don't support DST on their clocks Oct 30 11:06:30 USB is shit in general, I2C could be okay (although there are some unsufficiently well-known caveats with multimaster operation) but fucking up I2C controllers appears to be a popular hobby of chip designers Oct 30 11:06:40 broadcom fucked it up bigtime Oct 30 11:06:44 STM's is buggy as shit Oct 30 11:06:48 TI's is buggy as shit Oct 30 11:07:05 == sh*t² Oct 30 11:07:28 basically, I2C is inherently very much asynchronous, and in chip design world that's a dirty word Oct 30 11:07:33 <_av500_> zmatt: I remember doing bitband on davinci/omap3 for some reasons Oct 30 11:07:39 <_av500_> bang* Oct 30 11:08:24 _av500_: the TI I2C controller can work okay in master mode, as long as keep it in reset until you need to perform a transaction and put it back into reset afterwards Oct 30 11:08:32 (needless to say, forget about multimaster) Oct 30 11:09:40 and you need some code that manually deals with a stuck bus Oct 30 11:09:58 e.g. after reset (when there are reset-insensitive devices on the bus, which is common) Oct 30 11:10:50 the behaviour of its registers and irqs is very underdocumented though Oct 30 11:11:08 in particular, its irq register look Highlander-compliant at first sight Oct 30 11:11:12 they aren't. Oct 30 11:13:13 in addition to the well known event/edge (requires manual clear, can be manually set) and level (no set/clear, directly corresponds to a status signal), it also invented: Oct 30 11:13:42 sticky level: like level, but needs manual clear anyway (but that's only possible once the level input has deasserted) Oct 30 11:14:17 event that is occasionally also cleared by the peripheral itself Oct 30 11:14:21 (but not always) Oct 30 11:15:08 some bits that are either event or level, depending on circumstances such as which transaction phase you're in Oct 30 11:15:49 and best of all, a level irq that also has a sticky version, and which one is visible in the irq status register depends on whether the irq is enabled or not Oct 30 11:17:08 so you need to clear those before enabling, even if they don't seem to be asserted, since upon enabling the sticky version will show up again which may in fact still be asserted otherwise Oct 30 11:17:20 nicely done Oct 30 11:18:22 anyway, afk for a bit, heading to work Oct 30 16:34:05 what sets the dvi mode, u-boot or the kernel? Oct 30 16:35:10 damjan, depends, are we talking an ancient board/image? u-boot... today, the kernel.. Oct 30 16:36:47 rcn-ee: beagleboard-xm, u-boot is uboot-beagleboard-2015.04-1 kernel is 4.2.5 Oct 30 16:37:44 damjan, that uses the kernel drm stack, so it reads the edid from the monitor.. Oct 30 16:38:09 if it "fails" screen is blank, look in /boot/uEnv.txt for a way to overide edid read failures.. Oct 30 16:38:23 rcn-ee: I did see drmfb mentioned in dmesg Oct 30 16:38:40 "omapdrm" Oct 30 16:38:43 my monitor complains about unsupported resolution Oct 30 16:39:03 damjan, so pick one to overide it.. /boot/uEnv.txt has an example.. Oct 30 16:39:48 dvimode=? Oct 30 16:40:08 damjan, nope... Oct 30 16:40:34 damjan, open /boot/uEnv.txt you'll see a note" in case of edid read failure do this..." Oct 30 16:42:51 rcn-ee: it's empy here by default https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/uboot-beagleboard/uEnv.txt Oct 30 16:43:25 damjan, ahh using arch... Oct 30 16:43:37 go ask them.. Oct 30 16:44:11 is there an upstream uenv.txt? Oct 30 16:44:24 i made this easy for ubuntu/debian users on elinux, you need to figure out what "arch" did in u-boot.. Oct 30 16:45:42 video=HDMI-A-1:1024x768@60e Oct 30 16:45:49 damjan, read https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/fb/modedb.txt Oct 30 16:46:15 I have [drm] Cannot find any crtc or sizes - going 1024x768 - which should be supported by the monitor :/ Oct 30 16:46:59 damjan, actually for the xm, it's dvi: so you need to pass: "video=DVI-D-1:1024x768@60e" Oct 30 16:47:34 lets see Oct 30 16:47:37 damjan, plug it into another systemd and type "xrandr" Oct 30 16:49:18 rcn-ee: I did http://vpaste.net/Bwzz3 Oct 30 16:50:35 damjan, and you have the "xm" so force "video=DVI-D-1:1024x768@60e" Oct 30 16:51:04 the xm's omap3xx was designed for 720p era displays.. Oct 30 16:52:02 rcn-ee: is this second video= different, I don't see the difference Oct 30 16:52:43 now there's a [drm] forcing DVI-D-1 connector ON [drm] Cannot find any crtc or sizes - going 1024x768 Oct 30 16:52:44 nope, just re-stating. Oct 30 16:53:24 still doesn't show up on the monitor Oct 30 16:53:35 cat /proc/cmdline Oct 30 16:54:39 yeah it's there console=ttyO2,115200n8 smsc95xx.macaddr=9b:03:cc:7e:2a:23 nfsroot=192.168.157.2:/home/nfs/archlinux-bbxm,vers=4.2 ip=:::::eth0:dhcp video=DVI-D-1:1024x768@60e root=/dev/nfs Oct 30 16:54:55 what's the 'e' in 60e ? Oct 30 16:55:34 aha, enabled Oct 30 16:56:06 try one of the other resolutions, your monit just might be lieing about support.. Oct 30 16:57:38 I wonder if » If 'R' is specified, do a 'reduced blanking' calculation for digital displays. « is relevant Oct 30 17:03:41 rcn-ee: interesting I've put video=DVI-D-1:800x600@60e (it's in /proc/cmdline) dmesg still says [drm] Cannot find any crtc or sizes - going 1024x768 Oct 30 17:08:02 damjan, double check dvi-d-1 exist's /sys/class/drm/ Oct 30 17:08:25 card0 card0-DVI-D-1 card0-Unknown-1 controlD64 version Oct 30 17:08:55 looks good (btw: unknown-1 is s-video)... Oct 30 17:23:23 there's not an omap thingy you have to force? Oct 30 17:23:36 or there was a force_video thingy once. Oct 30 17:24:32 what's the parameter to auto-calc timings .. it looks like its tryin to look up a resolutino entry in a table Oct 30 17:25:08 ie. hard-coded Oct 30 20:54:42 * zmatt takes a swing at plotting some I/V graphs from the am335x ibis data... https://goo.gl/KL4rxA **** ENDING LOGGING AT Sat Oct 31 02:59:59 2015