**** BEGIN LOGGING AT Mon Jan 25 02:59:58 2016 Jan 25 03:21:42 zmatt: i'm getting a printf("Could not get PHY for %s: addr %d\n", bus->name, addr); in the u-boot phy driver phy.c on u-boot start on our custom board: http://ur1.ca/og6f8 -> http://paste.fedoraproject.org/314332/69204114 Jan 25 03:22:56 let me back up: i'm not getting a eth0 connection on my custom board using this image. Jan 25 03:23:07 exact same image runs fine on the bbb Jan 25 03:23:28 this is like the 3rd line out the debug serial port on boot. Jan 25 03:23:42 "Could not get PHY for cpsw: addr 0" Jan 25 03:23:59 any ideas? Jan 25 03:24:39 this smells like we have a hardware problem.. Jan 25 03:25:08 the eth/phy interface was supposed copied verbatim from the bbb Jan 25 03:25:56 that's unfortunate since the BBB's phy is pretty flaky Jan 25 03:26:18 how so? Jan 25 03:26:19 it seems to be very fickle w.r.t. power and reset timing Jan 25 03:27:16 hmm Jan 25 03:27:16 in particular, if forced to use this phy, I would never have tied its reset to the processor reset but used a GPIO instead Jan 25 03:28:52 does the phy behave normally? (its leds initially off, turning on with some auto-negotiation delay when plugging in) Jan 25 03:29:15 does the remote end see link up? Jan 25 03:30:00 lemme take a look Jan 25 03:32:36 the PGOOD output of the pmic (I'm assuming you've also copied that piece of shit tps65217) is not really suitable for resetting the phy, it doesn't remain asserted long enough. that's presumably why they've put such an absurdly large capacitor on nRESET on the bbb Jan 25 03:33:03 (the cap also completely muffles nRESET assertion by the cpu on warm reset) Jan 25 03:34:43 ok i don't see any indication on my router side when i plug in the board Jan 25 03:35:21 try resetting your board (not power cycle, reset) Jan 25 03:35:41 (or more specifically the PHY, but you probably can't do that without resetting the whole board) Jan 25 03:37:02 hang on Jan 25 03:40:43 nothing Jan 25 03:40:53 no lights, no indication whatsoever on the router side Jan 25 03:41:07 same router port/network cable works on the bbb Jan 25 03:42:05 to give an impression, here's a powerup sequence of a BBB: https://goo.gl/photos/iyJ7UZKiH3WWTUGU7 yellow = power consumption (shows spikes when caps are charged). the first part shows the sequenced power-up: ddr, 1v8 (blue line), some delay, 3v3 (cyan line), core and mpu, about 20 ms delay, nPOR-release (green) and nRESET-release (orange/brown) Jan 25 03:42:10 yup, just verified the light on the router for that port went on when i plugged in the bbb Jan 25 03:43:02 perhaps i should check the big things first, like power to the phy? Jan 25 03:44:40 might be useful. another tip is: ground EMU0 (on jtag) while powering up, that will keep the CPU in wait-in-reset mode (all I/Os in default state) and lets you measure the PHY with less risk of shorting things, also lets you verify whether all strapping options are pulled correctly Jan 25 03:45:10 never mind that second part, that requires keeping the phy in reset Jan 25 03:46:03 actually, that's not a bad idea either: tie reset to ground, then both CPU and PHY have most of their lines high-Z and you can verify the strapping options of the PHY Jan 25 03:46:28 what do you mean "the strapping options of the PHY"? Jan 25 03:46:57 the pull-up/pull-down resistors on many of the phy's pins that are used to configure it Jan 25 03:48:15 a bunch of them (4 pulldowns and 3 pullups) shown in the topright corner of page 9 of the BBB schematic Jan 25 03:49:56 I think all 10K resistors on that page are strapping Jan 25 03:52:34 also beware of resistors marked DNI, there are quite a few there Jan 25 03:55:22 is the "link up" light on the router essentially the state of p5-9 (LED1/REGOFF on the PHY)? Jan 25 03:56:24 it's both a strapping option (REGOFF) and the link/activity led (LED1) Jan 25 03:56:51 see phy datasheet Jan 25 03:58:02 REGOFF is an unusual strapping option in that it's only sampled at power-up, not at reset Jan 25 03:58:40 (it determines whether it uses an internal regulator for its core supply or whether an external supply is provided) Jan 25 03:59:57 there is no strapping resistor on that line on the bbb schematic - just runs straight to the rj45 connector Jan 25 04:00:10 it has internal pull-down in the phy Jan 25 04:00:26 i.e. it defaults to enabling the internal regulator Jan 25 04:00:38 verify by measuring VDDCR (pin 6) Jan 25 04:00:38 ah Jan 25 04:01:58 ok, let me save your information - i want to check a few more things out first. thanks matt Jan 25 04:02:05 yw Jan 25 04:03:34 and my condolences on having copied those specific parts of the BBB schematic (pmic and ethernet)... Jan 25 04:03:43 :P Jan 25 04:05:14 be careful in handling ethernet, it seems the phy might be a bit ESD-sensitive, causing its core logic to lock up Jan 25 04:13:34 heh. Jan 25 04:16:25 are these eth connectors largely the same? i see the pins are a through-hole staggered pattern Jan 25 04:16:52 the suspicious thing is that pin 1 on the bbb connector is in a different place than pin 1 on our breadboard Jan 25 04:17:52 wait, no, that's not true. Jan 25 04:32:55 note that it's not a mere connector but has integrated magnetics (and leds obviously)... no idea if there's any sort of "standard" footprint for these things Jan 25 04:33:35 doh! Jan 25 04:33:47 i didn't realize there were leds on that side (the bbb) Jan 25 04:33:54 are those what you wanted me to look at? Jan 25 04:34:02 you can get all kinds of rj45 .. with/without magnetics and leds Jan 25 04:34:05 yah Jan 25 04:34:06 all sorts of sizes Jan 25 04:34:19 so I bet there's probabl a hundred or so footprints Jan 25 04:34:24 veremit: well, except "small" and "with magnetics" probably doesn't combine ;) Jan 25 04:34:28 10/100 .. 10/100/1000 Jan 25 04:34:35 zmatt indeed Jan 25 04:35:06 ok I really should Zzz .. cya tomorra/aka Later I-) Jan 25 04:35:15 lol Jan 25 04:35:18 good morning to you too Jan 25 04:35:53 yates: yeah if the phy is confused then e.g. the link led might stay on while there's no cable inserted or stuff like that Jan 25 04:36:31 neither led comes on. dead as a doornail. tried power on and reset. Jan 25 04:36:42 measured vddcr ? Jan 25 04:36:43 with the cable inserted Jan 25 04:36:57 ewe - hardware? Jan 25 04:36:58 :) Jan 25 04:37:04 lol Jan 25 04:37:14 no. not yet.. Jan 25 04:37:38 i see, thanks veremit Jan 25 04:37:41 good morning. Jan 25 04:37:50 where are you? what country? Jan 25 04:37:55 i'm usa. Jan 25 04:38:21 veremit is from UK, so it's way past bedtime ;) Jan 25 04:38:33 rather, U.S.M. - United States of Mexico. Jan 25 04:39:09 that was probably politically incorrect... Jan 25 04:39:22 I used to be a software guy too... well, still am, but I have no issue grabbing a scope when needed ( http://gerbil.xs4all.nl/bbb-pmic-testing.jpg ) Jan 25 04:39:45 showoff Jan 25 04:39:48 4-channel too. Jan 25 04:39:49 ;) Jan 25 04:40:01 yeah unfortunately only 4 channels Jan 25 04:40:11 how do you get those pics uploaded so fast? Jan 25 04:40:20 gerbil? Jan 25 04:40:26 it was already there Jan 25 04:40:50 and that's my machine here at home Jan 25 04:45:45 don't throw-up, i'm a pig: http://www.digitalsignallabs.com/lab.png Jan 25 04:46:11 hehe Jan 25 04:46:41 the board just in front of the PS is our custom board Jan 25 04:50:55 I'm still a bit fascinated by this... https://goo.gl/photos/i9cemUHz2v9H5Z6R7 when the BAT and BATMON terminals of the pmic aren't connected together it can't really detect the (absent) battery's voltage, and somehow manages to draw current from it anyway Jan 25 04:51:06 resulting in BAT dropping below 0V and staying there Jan 25 04:55:46 what is VDDCR supposed to be? Jan 25 04:56:55 ehh, 1.1 ? 1.2 ? I think something like that, check datasheet to be sure Jan 25 04:57:23 yeah, it's at 1.2V Jan 25 04:58:29 would an incorrectly-connected connector possibly cause the mmii itnerface not to reset Jan 25 04:59:03 "Could not get PHY for cpsw: addr 0" Jan 25 04:59:53 I wouldn't expect trouble on the analog side to cause the phy to become unresponsive on mdio Jan 25 05:01:59 so are you saying the nRST into the PHY should be delayed some from the SYS_RESETn input, ideally? Jan 25 05:03:52 perhaps our crystal isn't firing.. Jan 25 05:05:32 just throwing out ideas. Jan 25 05:10:10 going bed-time bye. Jan 25 05:10:28 you could also just extend SYS_RESETn... though personally I wouldn't connect them at all but use the datasheet-suggested circuit to reset at power on and/or use a gpio to reset the phy in u-boot Jan 25 05:11:01 but an improperly reset phy should still show activity on leds Jan 25 05:11:14 no led activity at all means something worse is going on Jan 25 05:13:35 my bet is on a wrong footprint for the connector. Jan 25 05:14:13 none, zero, zilch, nada. Jan 25 05:43:05 zmatt: does uboot deal with the device tree in any way? Jan 25 05:43:34 it loads it, makes minor modifications (e.g. ram size), and passes it to the kernel Jan 25 05:44:23 i've noticed that the bbb's "link up" lights are on at uboot (pressed a space). Jan 25 05:44:37 so this probably can't have anything to do with the device tree, can it? Jan 25 05:45:00 s/probably/problem/ Jan 25 05:45:10 s/problem/probably/ Jan 25 05:46:16 zmatt: by "loads it", i think you just mean load the structures into memory without acting on it further, right? Jan 25 05:46:34 weren't you going to bed? :P Jan 25 05:46:39 * zmatt is a bit support-tired Jan 25 05:46:56 actually i was in bed and got up to ask you this! Jan 25 05:47:22 oh, is that a hint (re: support-tired). Jan 25 05:47:29 ? Jan 25 05:47:39 yes :P Jan 25 05:47:52 never mind then. Jan 25 05:47:53 analyze led behaviour in more detail.. normally a phy comes up without needing any software configuration Jan 25 05:48:02 (as soon as it's released from reset) Jan 25 07:42:34 Hi Jan 25 07:42:45 I am getting error while connecting to cloude Jan 25 07:43:29 I don't have not connected any sensors. Just wanted to send some mock data Jan 25 07:44:01 The tutorial I used is http://www.instructables.com/id/Connect-Beaglebone-to-the-Cloud-and-Visualize-Your/?ALLSTEPS#step1 Jan 25 07:44:54 On https://s2c.io/ it never showed connected. Jan 25 07:45:09 hm Jan 25 07:45:46 * tbr has no idea about this s2c thing Jan 25 07:45:52 ok Jan 25 07:46:13 Any other cloud connection that you might have tried? Jan 25 07:46:31 I just want to get a feel of it. Jan 25 07:47:34 From the tutorial it looked like quite easy though. Jan 25 07:48:11 the cloud aspect seems to be fairly generic and not related to the BBB Jan 25 11:10:54 hi all Jan 25 11:11:07 i have a issue with my beagle bone Jan 25 11:11:11 any expert here Jan 25 11:11:12 ?? Jan 25 11:11:20 i am noob actually Jan 25 11:15:37 well what _is_ your issue? Jan 25 11:15:47 don't expect answers before you actually explain it Jan 25 11:15:52 LordSAK: tip: phrasing things this way makes it sound like you're seeking a personal tutor and will therefore greatly diminish your chance of getting help Jan 25 11:16:37 well. sorry for incovnience guys Jan 25 11:16:55 as tbr said, just ask your question and be patient... plenty of knowledgable people here but they're not continuously staring at IRC eagerly waiting for someone with an issue they can help with Jan 25 11:17:56 no need to apologize, it's just an easily overlooked cultural difference between IRC help channels and the Real World™ Jan 25 11:20:44 issue is i was trying to use SD Card memory for my BBB which already had Debian. for that i used Disk Utility and was formatting my SD card. but think i accidently formatted something else. we tried to connect board via USB and only Power LED was on, rest was off. we tried to write new image and boot it, but this time only USER0 and USER1 LEDs turend on solid. no heartbeat pattern for USER0. CPU and eMMC lights are off. we tried to Jan 25 11:21:05 out. We are out of ideas and google is not helpful too. Jan 25 11:21:27 Please let me know any furthur details you guys might need. Thanks Jan 25 11:21:32 your line got cut off... "CPU and eMMC lights are off. we tried to" Jan 25 11:21:59 we tried to connect it via ssh, but it timed out Jan 25 11:22:12 if it doesn't boot then ssh obviously won't work Jan 25 11:22:35 only power led on is typical for not-booting Jan 25 11:22:44 ok Jan 25 11:22:55 only usr0 and usr1 on is however... odd.. Jan 25 11:22:59 for the future, consider buying a "3.3V ftdi cable" to connect to the UART port Jan 25 11:23:13 ok Jan 25 11:23:22 are you holding down S2 when powering up the board? Jan 25 11:23:23 tbr: 5V is fine too actually, the uart buffer acts as a level shifter Jan 25 11:23:37 k Jan 25 11:23:52 tbr: though 3.3V is a safer choice with modern electronics Jan 25 11:24:17 yes we are holding s2 button Jan 25 11:24:56 it's important that you hold it down before you connect USB or power to the board Jan 25 11:25:04 only in that case USER0 and USER1 lit ip Jan 25 11:25:15 (and you can release it once the power led goes on) Jan 25 11:25:27 yes we are following that procedure Jan 25 11:25:27 ok, sounds like it's getting stuck somewhere. probably in U-boot Jan 25 11:25:36 what image did you write to the card? Jan 25 11:25:43 ok, assuming the u-boot script hasn't changed much, usr0 is set very early in u-boot and basically just means "hi! u-boot here!" Jan 25 11:26:42 well debian 7.9 image we downloaded from beagleboard(dot)org Jan 25 11:27:19 I'd recommend something more recent like http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_lxqt Jan 25 11:27:23 ok. so seems like it is stuck at U-boot Jan 25 11:27:41 ok zmatt Jan 25 11:27:57 we will be back again. let me try using this image Jan 25 11:28:00 thanks Jan 25 11:28:02 (if you have rev C you can use either the 4gb one or the 2gb one to install less crud and have more free space, if you have older than rev C you need the 2gb one) Jan 25 11:28:03 make sure your card is large enough for it Jan 25 11:28:07 be sure to download the flasher Jan 25 11:28:11 that too Jan 25 11:28:30 yes i will keep that in mind Jan 25 11:28:59 usr1 is set when it has detected the card presence Jan 25 11:30:28 hello Jan 25 11:30:30 usr2 is set when it has loaded either /uEnv.txt or /boot/uEnv.txt Jan 25 11:30:33 ple, urgent helpȘ Jan 25 11:30:50 so it's failing quite early and quite badly Jan 25 11:30:52 i have a BBB and i need to disable g_multi and enable gadgetfs Jan 25 11:31:06 in order to have dev type gadgetfs Jan 25 11:31:13 anyway, I'm afk Jan 25 11:32:11 i don;t need usb eth or mass storage device, anything like that. i'm using spi0, 2 uart and i need usb to work in proxy mode Jan 25 11:32:31 and for that, i;m using dominicgs project USBproxy Jan 25 11:33:02 it was compiled succesfully but when i'm starting it, it says that i don't have gadgetfs tpe Jan 25 11:33:23 whem i type lsmod, i see i have it Jan 25 11:33:51 i type modprobe gadgetfs, i don;t receive any errors, but i doesn;t do anything Jan 25 11:34:08 and i read somewhere that is because g_multi is enabled Jan 25 11:34:17 so, please help.... Jan 25 11:34:58 anyone ? Jan 25 11:38:41 up Jan 25 11:38:44 anyone ? Jan 25 11:40:25 help ? :( Jan 25 11:47:05 costin_: didn't I tell you the other day to look at the scripts in /opt? Jan 25 11:48:03 nope, i must have been afk... i posted the question an didn;t receive the answer for almost an hour and got off the keyboard Jan 25 11:48:07 sorry Jan 25 11:48:52 yes, i know about /opt/scripts/boot section Jan 25 11:49:07 but i don;t know what and how to modify it to bring gadgetfs online Jan 25 11:49:36 i comment the line with g_multi Jan 25 11:49:47 but how can i enable gadgetfs ? Jan 25 12:29:01 hi @all Jan 25 12:30:38 http://www.catb.org/esr/faqs/smart-questions.html Jan 25 12:30:51 maybe someone can help me with a tiny gpio problem... i'm writing a kernel module, but i did not get access to the gpio...i already get "Device or resource busy" (latest debian image 4.1.12-ti-r29, BBB) Jan 25 12:34:22 i also tried to unexport the specific gpio, but there i get a "write error: Invalid argument" (echo 45 > /sys/class/gpio/unexport) Jan 25 12:35:18 do someone have an idea, where i did something wrong? Jan 25 12:36:08 it failed at: gpio_request_one(_pin, GPIOF_OUT_INIT_HIGH, "mymodule"); Jan 25 12:44:46 are you sure that the gpio pin is properly muxed through a device tree entry? Jan 25 12:51:10 it should, but i'm not sure ;-) Jan 25 12:53:33 well to me it looks like the pin is already in use, so you chould check in the devicetree if pin 0x834 (0x34 without the new AM36XX_IOPAD macro) is used by something else or not set to MODE7 Jan 25 13:12:27 hi people. I have some questions about bbandroid. is here the right place to ask? I want to change the start logo while we power on beaglebone black. besides I want to change UI of bbbandroid. I ma not sure where I should make these changes? in bbbandroid source code? Jan 25 13:13:01 not many people here bother with android, no Jan 25 13:13:18 replacing the startup animation on android is a well documented procedure Jan 25 13:13:47 also creating a custom launcher or customizing the default launcher is probably somewhat documented Jan 25 13:19:51 tbr: yes I found the documentation for logo changing. but did not find documents for changing User Interface Jan 25 13:21:01 look for "custom launcher". I'm sure you'll find something. Jan 25 13:21:28 Also I have a hunch, that your questions will get much more attention if you chose the right section of the XDA ph0rumz. Jan 25 13:38:00 Question, how do I/(can I) enable a serial TTY debugging over USB for the BBB? Rather than the USB network on the OTG. Jan 25 13:40:33 the default images expose a network interface, a tty, and a mass storage device over USB Jan 25 14:24:16 hello. since which version gpioN became gpioN-1 in the dts files? Jan 25 14:24:47 gpios used to be 1-based? eww Jan 25 14:25:19 I mean the GPIO banks Jan 25 14:26:46 yeah, annoyingly TI sometimes uses 1-based numbering for some stuff (but inconsistently so) Jan 25 14:30:21 woohoo! my code managed to trigger an internal compiler error in gcc Jan 25 14:43:52 zmatt: i actually managed to get the simple-audio-card to work, but i still had to use the spdif transmitter codec, because the buildin dummy codec has no dt bindings Jan 25 14:44:31 but for anithing more advanced you probably want to write your own driver anyway Jan 25 14:44:47 thats porbably the reason why its called "simple" :D Jan 25 14:45:05 tbr: I'm well aware about that. I'm just trying to figure out if it's _possible_ to expose it as a Serial device. Jan 25 14:45:30 Spidler: what do you want to expose? Jan 25 14:45:44 filt3r: well I am writing my own driver indeed... in userspace, via uio, so I can toss that whole ASoC crap in the trash Jan 25 14:46:01 I want the usb OTG port to act as a serial device with a serial console to the end user Jan 25 14:46:23 or want. "I would like" Jan 25 14:46:36 If it's not possible it isn't possible and I'll have to figure out another way. Jan 25 14:46:45 the usb ports can also actually be configured as uarts (D+/D- being rxd/txd or other way around) Jan 25 14:47:44 oh, fancy. would require some cabling work and a local USB->serial device to interact, but could work. Jan 25 14:48:11 zmatt: so you are not using alsa at all, or have you written an userpace alsa plugin to interface with the hardware (i've actually never heard of uio) Jan 25 14:48:28 filt3r: it would entirely bypass alsa Jan 25 14:48:46 ahh ok Jan 25 14:49:18 (I already similarly bypass the kernel for gpio, pwm, adc, and so on) Jan 25 14:52:58 thats an interesting approach, i actually never used uio, but it might come in handy sometime in the future Jan 25 14:53:29 yeah most of my code still uses /dev/mem actually, but I'm trying to slowly migrate to uio Jan 25 14:53:40 avoids the need for root perms, slightly safer, and allows irq delivery Jan 25 15:29:37 Hi - anyone familiar with the ti ezsdk? Jan 25 15:40:06 when I boot my BB Black without a mirco SD card, I get an Angstrom login prompt, then this error: tilcdc 4830e000.fb: timeout waiting for framedone Jan 25 16:07:08 has anyone ever answered a question here? Jan 25 16:11:49 i think you can ignore this error, at least i always ignored it :D Jan 25 16:16:22 twoten: yes. Jan 25 16:26:25 I'm going through the very difficult install of the ironically named ezsdk, and I don't have a serial uart cable yet. Do I really need one? Jan 25 16:28:31 i never used the ezsdk, but i strongly recommend having a serial connection for debugging, etc. Jan 25 16:30:34 I like qt creator myself but I need to use the pru on my project and the sdk offers that. Should I just find a pru addon and use that? Jan 25 16:56:57 Anything new about the X15? Jan 25 17:27:31 Spidler: something about pcb requiring tweaks due to failing FCC tests Jan 25 17:27:50 Okay. Jan 25 17:32:42 Meh meh and double meh. Jan 25 17:32:56 Okay, Enough whining, I'm off for the day. HAve a great night! Jan 25 18:13:18 huh. with a usb-powered esata adapter, u-boot is able to see the eSATA on the beagle-x15 ... but mainline linux is still having issues Jan 25 18:39:17 zmatt, did I tell you I sorted out my booting? Jan 25 19:44:54 rcn-ee: I need your help with adc Jan 25 19:45:52 i don't know a whole lot about the adc.. (besides enable/disable) Jan 25 19:46:02 I am using your lxde image with 4.1.13-ti-r35 Jan 25 19:46:14 right, I need to enable it Jan 25 19:47:06 I do not understand how to use config-pin to enable the adc? Jan 25 19:47:07 citylight2, sudo sh -c "echo 'BB-ADC' > /sys/devices/platform/bone_capemgr/slots" Jan 25 19:47:15 should be all you need.. Jan 25 19:47:36 sh: echo: I/O error Jan 25 19:47:46 citylight2, "dmesg | grep bone" Jan 25 19:47:59 dmesg | grep bone | pastebinit ;) Jan 25 19:48:10 [ 7128.429743] bone_capemgr bone_capemgr: slot #5: BB-ADC conflict P9.31 (#4:univ-emmc) Jan 25 19:48:10 [ 7128.463113] bone_capemgr bone_capemgr: slot #5: Failed verification Jan 25 19:48:37 citylight2, ah.. /boot/uEnv.txt remove "cape_universal=enable" text... Jan 25 19:49:00 (and reboot to clear it out) Jan 25 19:49:49 rcn-ee, what dtb do I need to enable HDMI on a BBB? Jan 25 19:50:09 Jonnyw2k, it's enabled by default in 4.1.x/4.4.x Jan 25 19:50:29 (aka use the default one) Jan 25 19:51:07 maybe my hdmi is broken, although I had issues getting it to boot with the new image (had to manually add the UUID to uEnv.txt) Jan 25 19:51:42 Jonnyw2k, ah that's something different.. Usually just a ground path issues to your monitor.. Jan 25 19:51:53 grep cape_universal /boot/uEnv.txt is empty Jan 25 19:51:55 (aka hardware issue, board vs cable vs tv) Jan 25 19:52:17 let me upgrade Jan 25 19:52:18 rcn-ee, got a BBB running an old image, and it displays ok using same cable and monitor Jan 25 19:52:32 so I thought I had isolated it to this BBB Jan 25 19:52:58 citylight2, just cd /opt/scripts ; git pull Jan 25 19:53:25 citylight2, cape-universal only gets enabled when the cmdline has: cape_universal=enable in /boot/uEnv.txt Jan 25 19:55:20 ok, let me try to reboot, I also had to modprobe ti_am335x_adc Jan 25 19:55:41 Jonnyw2k, back in 3.8.x somethings where run out of spec.. give sudo apt-get install linux-image-4.1.15-ti-rt-r43 a try, as ti pushed a big change last week..http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=commit;h=5e1dfcc82e4708846e91f6206b454746be1074e9 Jan 25 19:55:58 citylight2, when you echo that cape, it'll load up that module.. Jan 25 19:57:06 o Jan 25 19:57:16 Linux beaglebone 4.1.15-ti-rt-r41 #1 SMP PREEMPT RT Thu Jan 14 20:33:29 UTC 2016 armv7l GNU/Linux Jan 25 19:57:23 is on the BBB without HDMI Jan 25 19:57:32 Jonnyw2k, that was the week prior... Jan 25 19:58:04 ahh ok Jan 25 19:59:18 I'm not too worried, it's my a Rev A5A with missing uSD slot, so aslong as I can SSH to it I am happy Jan 25 20:12:53 since the cape mgr seems to change quickly, can someone point me to the latest docs? i'm running 4.4.0-bone2 Jan 25 20:13:17 Hey guys, I have a board that is loading a saved uboot environment from somewhere. This is really confusing to me, as I just re-imaged the device. So, it shouldn't have anywhere to load saved values from. Jan 25 20:13:52 abferm: probably from your on-board emmc. did you hold the boot button while booting? Jan 25 20:15:51 the emmc is what I just over-wrote, there is no SD card present, and I am flashing over USB using a method I have used on numerous occasions. Jan 25 20:19:54 yates, everything above v4.0.x is the same. ;) v4.0.x -> v4.5.x the only difference more things work on later kernels i backport things too.. Jan 25 20:21:05 I haven't flashed this particular board in a while, and I'm assuming someone(probably me) executed saveenv without knowing what they were doing. Where exactly does the environment get saved/loaded from? Jan 25 20:21:30 saveenv is disabled on factory boards... Jan 25 20:21:52 (breaks the beaglebone white, when it tries to read the non-existent eMMC) Jan 25 20:27:50 rcn-ee: I build my own uboot, and it isn't disabled on my build, I guess I'm just going to dig into the source code Jan 25 20:30:43 abferm, u-boot upstream sticks it on eMMC by default.. Jan 25 20:32:54 I'm going to write the latest Debian image onto my microSD, should I erase and format it first? Will the image create the partition? Jan 25 20:37:21 rcn-ee: do you know what address? Jan 25 20:37:53 twoten, no reason too.. Jan 25 20:38:36 ok Jan 25 20:40:01 abferm, right here: http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;h=6ebe0b3866f9b137472cc080c9eb8f1e38233186;hb=HEAD#l461 Jan 25 20:41:52 abferm: env is stored in one of the two semi-hidden boot partitions of eMMC Jan 25 20:48:24 rcn-ee: after upgrade the adc loads ok Jan 25 20:49:55 rcn-ee: is there a place in the ee-wiki for the page in http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User's_Guide Jan 25 20:50:24 I mean , I was looking for info on ADC on the newer kernel, and barly found info Jan 25 20:52:00 citylight2, i've been shoving examples in the bb.org-overlays repo: https://github.com/beagleboard/bb.org-overlays/tree/master/examples Jan 25 20:52:26 if you want to create a BB-ADC with atleast a readme.md doc pointing to ti's page, or even a basic shell script.. Jan 25 20:52:50 for w1, i threw together a really simple example: https://github.com/beagleboard/bb.org-overlays/blob/master/examples/BB-W1-P9.12/example.sh Jan 25 20:52:51 yes, I will start using it and post back Jan 25 20:53:48 did the x15 take all your focus lately? Jan 25 20:54:58 citylight2, actually last week most of my focus was on unifying all my "4.4.x + 4.5.x" tree's on the exact same overlay patchset ;) Jan 25 20:55:26 I see Jan 25 20:55:53 right now i'm playing with rs232, trying to get rts/cts to work with the new patches that hit linux-omap last week.. Jan 25 20:55:54 wish someone would interview you and post a beaglebone status newsletter Jan 25 20:56:16 jason does at some point.. ;) Jan 25 21:05:59 rcn-ee: hmm, since you include uio by default maybe I should make an ADC example The UIO Way™ :) Jan 25 21:08:51 zmatt, did the ti tilcd merge last week fix your lcd? Jan 25 21:09:51 zmatt, here's the ti commit compare: https://github.com/RobertCNelson/ti-linux-kernel/compare/e1b000ce0138a66f23815d819ef4fc79be49f503...5e1dfcc82e4708846e91f6206b454746be1074e9 Jan 25 21:12:56 i'm looking just for an example of accessing main memory from the PRU Jan 25 21:13:28 just a few commits there .. Jan 25 21:13:33 hello every one, this is vignesh from india Jan 25 21:13:49 hi vignesh Jan 25 21:13:56 rcn-ee: I don't think that compare worked well (github often seems to have trouble with those) Jan 25 21:14:16 but I don't have any functional setup with lcd right now, so I can't test right away Jan 25 21:14:27 zmatt: do those point to specific locations on /dev/mmcblk0, or are they separate entities? I've been writing my images over mmcblk0, and they should cover the entire disk(leaving no-where for the environment to hide). Jan 25 21:14:38 zmatt, yeah it's the raw compare, just the edma, tilcd, omapdss, that's all ti pushed last week.. Jan 25 21:14:39 zmatt: time to sponsor you another BBB ... :p Jan 25 21:15:00 abferm: mmcblk0 is just the main partition Jan 25 21:15:09 mmcblk0boot* live outside it Jan 25 21:15:20 I thought that was p0 Jan 25 21:15:37 ... long story Jan 25 21:15:46 are block* ever used zmatt? Jan 25 21:15:52 boot*** Jan 25 21:15:59 maybe there should be a wiki page explaining MMC partitions Jan 25 21:16:17 yes really .. and the whole mmcblk0/1 issue Jan 25 21:16:20 veremit: yes, uboot grabs its env there :P which is not what they were meant for Jan 25 21:16:26 zmatt: nice. Jan 25 21:16:48 someone please help me out on "how to start with kernels" Jan 25 21:16:52 they were meant to allow ROM to easily load the secondary bootloader and to allow it to be updated atomically Jan 25 21:17:10 http://elinux.org/BeagleBoardNAND Jan 25 21:17:24 since there are two partitions, and you can toggle a single bit to indicate which one will be served using the boot protocol Jan 25 21:17:28 perhaps not completely current, but not bad info Jan 25 21:17:52 wmat: that's raw nand, not emmc Jan 25 21:18:00 wmat+ Jan 25 21:18:12 wmat: i.e. not remotely applicable Jan 25 21:18:17 vignesh: you want to get into kernel programming or what? Jan 25 21:18:41 zmatt: yes, but it it's helpful-ish Jan 25 21:18:56 yes @tbr Jan 25 21:19:08 we can't have #exactsteps for everything, can we? Jan 25 21:19:09 vignesh: look at the eudyptula challenge Jan 25 21:19:22 veremit: unfortunately the AM335x ROM doesn't use the boot protocol at all Jan 25 21:19:31 even though it's much easier than normal MMC access Jan 25 21:19:47 zmatt: why do things the *correct* way :P Jan 25 21:19:50 (boot protocol = hold cmd low, start clocking and after a bit data blocks get sent your way) Jan 25 21:20:01 FARRR too simple Jan 25 21:20:18 rcn-ee: ok, thanks for the clarifications. Jan 25 21:20:30 yes, and atomic upgrades are far too convenient for reliability Jan 25 21:21:27 is that a competition @tbr Jan 25 21:21:31 ?? Jan 25 21:21:55 vignesh: no, it's a set of challenges to support your learning process Jan 25 21:22:27 thats awesome thank you @tbr Jan 25 21:22:41 let me check it out !! Jan 25 21:25:47 http://eudyptula-challenge.org/ <--- this doesnt work please help me out @tbr Jan 25 21:26:56 zmatt: Any way I can over-write that from linux? I just tried to zero it with dd, but I got an error: "dd: error writing '/dev/mmcblk0boot1': Operation not permitted" Jan 25 21:27:37 vignesh: try this http://web.archive.org/web/20160121200018/http://eudyptula-challenge.org/ Jan 25 21:28:24 rcn-ee: so, interestingly enough, using an eSATA adapter that pulls power from a USB port, u-boot recognizes the eSATA. but using one that's only powered off of eSATA, u-boot doesn't recognize it Jan 25 21:28:41 rcn-ee: but neither work with mainline linux Jan 25 21:29:06 abferm: there's a bit you need to flip in sysfs to unprotect it Jan 25 21:29:13 zmatt: I just answered my own question... https://www.kernel.org/doc/Documentation/mmc/mmc-dev-parts.txt Jan 25 21:29:43 yeah that Jan 25 21:30:26 vagrantc, did you run "usb scan/init" before "scsi scan/init" usb turns on the power rail for the esata connector ;) Jan 25 21:30:55 rcn-ee: i didn't, and neither did the normal boot process Jan 25 21:31:29 seems like it would be worth reordering that... Jan 25 21:31:46 i had that enabled about a month ago, but usb "3.0" broke with that (usb 2.0 was fine).. Jan 25 21:31:59 (now usb/scsi i leave disabled in u-boot) Jan 25 21:31:59 rcn-ee: but which kernel(s) has this been applied to? Jan 25 21:32:00 fix one thing, break another... Jan 25 21:32:09 rcn-ee: (so I know which one to test when I have a moment) Jan 25 21:32:10 zmatt, since last week.. Jan 25 21:32:16 r43.. Jan 25 21:32:19 rcn-ee: which branch? Jan 25 21:32:25 4.4-ti ? Jan 25 21:32:37 4.1.x-ti/4.1.x-rt-ti Jan 25 21:32:43 check Jan 25 21:33:15 thanks bro i got it @ tbr Jan 25 21:33:40 trying to use USB from u-boot causes an instant system reset for me ... but who knows, i'm using 2016.01 with ti-u-boot patches from 2015.07 or something Jan 25 21:34:00 vagrantc, some boards where doing that too.. Jan 25 21:34:59 rcn-ee: I noticed that in 4.4 edma finally has the ability to reserve EDMA slots via DT, I hope that's in 4.1 now also since that's going to be quite important for me when I start using McASP from userspace Jan 25 21:35:23 zmatt, yeap, that got merged back to 4.1.x last week too .;) Jan 25 21:35:32 w00t Jan 25 21:38:18 although at low channel count the cpu *ought* to be able to manage on the McASP's fifo + irqs alone, certainly on an RT kernel, but I'd rather not take chances Jan 25 21:38:33 audio is rather unforgiving w.r.t. being slightly late Jan 25 21:39:55 I'm also still investigating the best way to patch the kernel to make /dev/mem and uio use "Device"-type mappings for peripherals and "Normal uncacheable" for memory, instead of using performance-killing Strongly-ordered for everything Jan 25 21:40:31 if I run /sbin/modprobe uio_pruss extram_pool_sz=SOMENUMBER, how do I know what address to write to in the PRU? Jan 25 21:54:57 when will i get the reply from little@eudyptula-challenge.org ?? @tbr Jan 25 21:55:35 does anyone know a tolerable interface to google groups? Jan 25 21:55:41 I *hate* them .. lol Jan 25 21:55:41 vignesh: no clue. I am not affiliated with this service in any way. Jan 25 21:55:49 veremit: email? Jan 25 21:55:57 tbr: ffs this is the 21stC Jan 25 21:56:15 * tbr always subscribes to google groups using his email... Jan 25 21:56:59 And no, I'm not an emacs/vi user. Sod that and all its crap lol Jan 25 21:57:12 veremit, mutt! Jan 25 21:57:23 rcn-ee: I'll let mutt fly ... :P Jan 25 21:57:50 but I do use nano/minicom regularly .. so .. Jan 25 21:57:58 what does it mean I see /sys/class/gpio/gpio2 does not exist? Jan 25 21:58:12 echo 2 >/sys/class/gpio/export ? Jan 25 21:58:20 veremit: well the main google groups interface is tolerable compared to the icky embedded one on the beagleboard.org website Jan 25 21:58:30 zmatt: omg, there's WORSE?! Jan 25 21:58:37 * veremit stabs himself with a rusty nail Jan 25 21:58:40 http://beagleboard.org/Community/Forums Jan 25 21:59:16 and as tbr pointed out you can use email Jan 25 21:59:24 veremit, this used to exist afer booting Jan 25 21:59:27 odd Jan 25 21:59:52 citylight2: something didn't load right, then Jan 25 22:18:26 bbl, train Jan 25 22:19:30 rcn-ee: seems I can load the adc but the cape-universala is not loaded on boot Jan 25 22:19:58 so I can not run /usr/local/bin/config-pin P8_43 in_pu to use the on board button Jan 25 22:20:22 can't I run the universal cape and the adc overlay? Jan 25 22:22:17 you can, if you disable the adc pins in cape universal, or load cape universal and then use config-pin for the adc's.. Jan 25 22:22:28 i just assumed you wanted to use the adc and that was it.. Jan 25 22:27:30 doesnt the cape universal allow me to use the adc pins as adc? Jan 25 22:27:57 what to do now to get cape universal and adc at the same time? Jan 25 22:51:22 hi: i need to use 4 serializers of mcasp with 4 channels on each... i configured tdm-slots=<4> adn added 4 active serializers, but arecord command only let me record 4 channels... am i doing it all right? Jan 25 22:52:59 rcn-ee: how do you submit a proposal for a x15 project - can't find any web pages/ posts anywhere? Jan 25 22:53:30 PF: just out if curiosity can you poste the mcasp part of your device tree Jan 25 22:53:52 yes... wait a sec Jan 25 22:54:26 &mcasp0 { pinctrl-names = "default"; pinctrl-0 = <&mcasp0_pins>; status = "okay"; op-mode = <0>; /* MCASP_TDM_MODE */ tdm-slots = <4>; num-serializer = <16>; serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */ 1 1 2 2 0 0 0 0 0 0 0 0 0 0 0 0 >; tx-num-evt = <1>; rx-num-evt = <1>; }; Jan 25 22:54:40 mmm... should i post line by line? Jan 25 22:55:03 ? Jan 25 22:55:18 veremit, https://groups.google.com/d/msg/beagleboard-x15/mqAF6V5fVWs/142Dze21CQAJ Jan 25 22:55:32 rcn-ee: tyvm Jan 25 22:56:56 nah its fine, ok so with this config you should be able to play 8 and record 8 channels, can you check the channels_max properties in your platform driver, your codec and the davinci-mcasp.c (older versions of the mcasp drivers used a lower channes_max value as far as i know) Jan 25 22:59:24 filt3r: Thanks for answering. I've checked that, in my version channel_max is 32 Jan 25 22:59:57 filt3r: if i use tdm-slots=<8> it let me arecord more channels Jan 25 23:00:13 huh thats interesting Jan 25 23:00:19 but that would mean 8 tdm-slots on each serializer... i need 4 on each Jan 25 23:01:59 hmm ok, i've never used more than one input and one ouput serializer, so i have no idea how this would work together with alsa Jan 25 23:04:37 oh... ok, thanks anyway! any idea where could i ask this? perhaps is not supported? alsa mailist wont answer, neither #alsa irc channel Jan 25 23:12:00 whats the "arduino" dtb ? Jan 25 23:23:07 Jonnyw2k, google "arudino tre" lots of info, hasn't been officially released.. Jan 25 23:25:34 I feel it should have more beagle branding :P Jan 25 23:41:58 hmm no PF is gone . . . Jan 25 23:57:52 in bb-kernel/KERNEL/arch/arm/boot/dts/am335x-bone-common.dtsi, i assume the "baseboard_eeprom" used by the kernel to read the baseboard eeprom. we have removed the baseboard eeprom on our custom board, so should this dtsi node be removed? Jan 25 23:58:41 what i don't understand is the interface between the kernel and the device tree - i.e., if it expects a certain named device (e.g., baseboard_eeprom) to be there and it's not, what does the kernel do? Jan 26 00:01:31 i.e., are there other changes to the kernel code itself required to properly excise this function? Jan 26 00:02:49 the kernel probably doesn't care about it at all, the DT node just declares the existence of that EEPROM on the specified i2c bus and lets the kernel know which driver to use for it Jan 26 00:03:17 if you leave it you'll probably just get an error somewhere in your kernel log Jan 26 00:04:12 I would excise it though, along with capemgr Jan 26 00:04:26 so where is the code that actually uses it? Jan 26 00:05:02 since the node is labeled it's possible there are references to it elsewhere in the DT, you might want to do a quick search for those Jan 26 00:06:02 the code that "uses" it is the driver that declared it can support "at,24c256" devices Jan 26 00:06:12 if some driver/module requires the baseboard_eeprom it will reference it in its own dt node, so in that case if you would remove the baseboard_eeprom node and another DT node would require it (which seems not to be the case) you would get an error while compiling the devicetree anyways, and what the kernel does when the baseboard_eeprom is there but the actual hardware is not there depends on the driver, because the kernel will probe the driver Jan 26 00:06:13 but the driver will not find the device since its not attached, and the driver will probably give an error if its written nicely, also what zmatt said Jan 26 00:07:37 the driver will handle it gracefully, since just below it there are similar declarations for eeproms at all four possible addresses for CAPE eeproms Jan 26 00:07:51 and obviously the kernel works fine without 4 eeproms attached Jan 26 00:13:59 in the case of the eeprom driver it just assumes the devices are there but if you try to read from nonexistend eeprom devices it just times out because the hardware is obviously not there Jan 26 00:14:06 *at24 driver Jan 26 00:18:49 is "Bad to the Bone" recommended? Jan 26 00:20:48 nix that. Jan 26 00:21:45 i'm trying to digest what ya'll have said. there still seems to be something lacking in how all this hangs together, but i'm too ignorant to ask the right questions. Jan 26 00:23:06 woohoo, my first McASP-from-userspace test... three error irqs and an assertion failed \o/ Jan 26 00:23:48 e.g., capemgr obviosly depends on cape_eepromX, 0 <= X <= 3, but i see no connection in the .dtsi Jan 26 00:23:54 the streams are still running though, presumably all zeros Jan 26 00:25:16 bone_capemgr, that is. Jan 26 00:26:32 ah, i see it now. Jan 26 00:26:39 cape0_data, ... Jan 26 00:26:50 this seems really twisted.. Jan 26 00:28:20 also, should i modify (patch) the dtsi files themselves in the kernel, or use the overlay shadowing method you mentioned sometime ago, zmatt Jan 26 00:28:47 remove or modify a node via an overlay, that is. Jan 26 00:29:05 create a new dts, reuse the parts that are still relevant Jan 26 00:29:29 take example of the existing files, since they already cover multiple boards by factoring out common parts into dtsi files Jan 26 00:29:57 you can also include a dtsi and override parts of it, including removing properties or nodes Jan 26 00:30:08 whichever is more convenient Jan 26 00:30:52 don't use overlays, using them to change properties or remove nodes rarely if ever works. overlays should at best be considered a development tool, not something for production code Jan 26 00:32:03 "which files" is also confusing to me. the kernel build produces dtb for all these: http://paste.fedoraproject.org/314712/45376827 Jan 26 00:32:12 well from a semantics point of view it would even make sens to create a new devicetree file(s) based on the bbb DT files since i think you have a completle different board probably with a different name Jan 26 00:32:14 which ones are relevent to the BBB? Jan 26 00:32:28 am335x-boneblack.dtb Jan 26 00:32:55 filt3r: all the others are not used for the bbb build? Jan 26 00:33:03 s/all the others/none of the others/ Jan 26 00:33:10 no Jan 26 00:33:21 ok, thanks - that helps alot. Jan 26 00:33:26 step 1a, sort of thing... Jan 26 00:33:33 yates: there are a few variants e.g. for people who don't need eMMC and want to free up those pins for other uses Jan 26 00:34:18 i see Jan 26 00:38:57 yates: just out of curiosity, which kernel are you using? Jan 26 00:39:04 4.4.0-bone2 Jan 26 00:39:51 using this as a guide: https://eewiki.net/display/linuxonarm/BeagleBone+Black Jan 26 00:40:22 i've essentially encapsulted this guide into gnumake files Jan 26 00:41:58 what you say about a new board name etc. would probably be more slick/ideal, but we're pretty close to a bbb and it seems the shorted path to working system is to be a bbb Jan 26 00:42:03 emulate a bbb, that is Jan 26 00:42:27 we are removing the board ID EEPROM and the HDMI chip. Jan 26 00:42:58 s/shorted/shortest/ Jan 26 00:44:07 we're repurposing uart0, adding uart1/2, and adding an i2c, in addition Jan 26 00:44:16 that's about it. Jan 26 00:44:28 I'd have kept the EEPROM (or at least some form of it) ... they cost next to nothing and it's rather convenient to have a place to store board identification and serial number Jan 26 00:44:46 yeah, i've been rolling that same thought over in my mind. Jan 26 00:44:55 we do need a way to identify boards uniquely. Jan 26 00:45:25 well you can use the MAC address Jan 26 00:45:38 does the PHY provide that? Jan 26 00:45:51 the am335x Jan 26 00:46:00 uniquely? Jan 26 00:46:16 it has 3 MAC addresses allocated from TI's range Jan 26 00:46:27 that's in the board eeprom, right? i saw it Jan 26 00:46:31 no Jan 26 00:46:43 burned into eFUSE in the processor itself Jan 26 00:46:54 MAC[HDR_NUM_MAC_ADDR][MAC_ALEN] or somesuch Jan 26 00:47:06 the board data isn't used? i noticed it was blank. Jan 26 00:47:27 the eFUSE? hadn't notcied that yet.. Jan 26 00:47:39 for reasons that elude me there are ways to override the MAC address, but normally that's never used Jan 26 00:48:21 the primary location is in the control module, which has two fields containing the start and end of the MAC address range for the processor Jan 26 00:48:57 this comes preset from the factory (TI)? Jan 26 00:49:13 that would be a good choice for an id, yes. Jan 26 00:49:27 https://github.com/dutchanddutch/jbang/blob/master/include/ti/subarctic/ctrl.h#L415 Jan 26 01:55:03 My beagle bone isnt connecting to my computer anymore Jan 26 01:55:49 I need help Jan 26 01:56:00 My beaglebone isnt connecting to m computer anymore Jan 26 01:56:32 I have all the needed files downloaded..its not that thats the problem its not even blinking when I connect it via usb Jan 26 01:58:50 What can i do to fix it?? Jan 26 01:58:54 ; Jan 26 02:14:10 Sara... Jan 26 02:19:01 well if you won't stick around Jan 26 02:36:47 * ayjay is back Jan 26 02:40:47 evening all. just got my BB Black and was trying to update the firmware. found the special instruction to make this change in the uEnv.txt file. #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh I cant find that command line to remove the comment statement from. Any clue? did the rules change? Jan 26 02:42:50 if you can't find it, add it Jan 26 02:43:23 it's just a command line to launch the emmc flasher to install the image from the SD card to the emmc Jan 26 02:43:35 :) if all else fails cheat? add to the front or back of the text file? **** ENDING LOGGING AT Tue Jan 26 02:59:58 2016