**** BEGIN LOGGING AT Wed Jul 22 02:59:59 2015 Jul 22 04:45:10 omg anybody here to help me LOL Jul 22 04:45:33 *waits for his ports to be scanned* Jul 22 04:47:31 ooh baby, I'll syn your socket Jul 22 04:49:10 in cloud9 how to you run a console command like a simple 'ls' automation? in bonescript? Jul 22 04:49:38 Basically making a .js .bat file here yeah Jul 22 04:50:18 trying to make this autorun.js run my wifiturnon.sh and other things Jul 22 04:51:32 I can make it control an army of darpa dogs, but I cant make it run a shell command :/ Jul 22 04:54:25 Huh. I know some of these words. Jul 22 04:54:52 More of a solder guy myself, but definitely idle for a while and someone with more clue might be around. Jul 22 04:55:23 there's also a #cloud9ide on this net, you might try Jul 22 04:55:58 thx Jul 22 05:24:16 anybody know the bonescript lines needed to run console commands like a script would? Jul 22 05:25:39 I am trying to automate console shell commands from the beaglebone .js Jul 22 05:43:50 anybody know how to bonescript a command line execution? .js version of the .sh / .bat file? I can find writing to files and pins but not to console. Jul 22 05:45:15 I need a console.log.then.hit.enter.and.execute("ls"); command pls Jul 22 05:46:51 All the available data is based on certain assumptions that leave me with no answers. Jul 22 07:06:37 wow I figured it out Jul 22 07:06:44 party on Jul 22 08:57:22 where can i find the overlays for the different beagle capes? Jul 22 08:57:30 there doesn't seem to be a central repository Jul 22 09:03:54 seems like this is the answer: Jul 22 09:03:56 https://github.com/beagleboard/bb.org-overlays Jul 22 11:30:11 hmm, anyone experience with using the SGX stuff bypassing fbdev? (building with FBDEV=no and omitting fb support entirely from the kernel) I'm wondering about the pros and cons Jul 22 11:34:36 I'd hope less layers of overhead hence better performance, and possibly even better stability.... lcdc would probably need manual config, but it will need that anyway when we get the lcd screen (currently using hdmi for testing) Jul 22 11:36:09 (and yes I can discover these things by Try It And See, and suspect that's the only way to find out, but maybe someone already tried it and can report there's nothing down this road but despair) Jul 22 11:42:18 hello Jul 22 11:43:34 I'm brand new to beaglebone and yocto. I'm confused. I pulled via git the three downloads for yocto: build system, tools and beaglebone bsp. Jul 22 11:44:04 I did the qemu build and ran it for intel. I now want to build a beagle image and run on real hardware. Jul 22 11:44:40 am I supposed to move the bsp I downloaded to a subdir under poky and replace/supplement the dirs there? Jul 22 11:47:34 I think asking on #oe or #yocto might be better Jul 22 11:47:51 hello tbr Jul 22 11:47:54 tbr: many thanks Jul 22 12:06:25 Hi, I have some problems with cloud9 and the new firmware (2015-07-06) of the BBB. Someone can help me? Jul 22 12:08:57 not, unless you state what your problem is Jul 22 12:11:39 I am not able to program the board using cloud9. If I try to load the blink program from cloud9 nothing happens, but with the demo directly from http://192.168.7.2/ on the browser it works Jul 22 12:11:53 KotH: c'mon, you haven't even given telepathy a serious try have you? ;-) Jul 22 12:14:59 so? Jul 22 12:15:18 Mr Telepathy? Jul 22 12:16:33 divide by 137 Jul 22 12:18:07 nice trolling channel Jul 22 12:18:32 * KotH has no idea Jul 22 12:18:38 never used cloud9 Jul 22 12:18:45 i'd say look into the logs Jul 22 12:18:54 see what happens.. or doesnt Jul 22 12:19:04 are yu now trying the telepathy thing ? Jul 22 12:19:20 (he left) Jul 22 12:19:21 nah.. general unixoid debugging technques Jul 22 12:19:28 oh... Jul 22 12:19:29 well Jul 22 12:19:38 his bad Jul 22 12:20:04 * KotH does not provide rainbows and unicorn farts Jul 22 12:21:05 farting a unicorn sounds like an unpleasant affair Jul 22 12:21:54 depends on the direction in which it comes out Jul 22 12:22:28 there are no good options there... just bad and worse Jul 22 12:22:46 you surely dont want the worse one Jul 22 12:24:03 wtf were those imgtec people thinking when they made this directory structure.... GFX_Linux_SDK/OGLES2/SDKPackage/Demos/MagicLantern/OGLES2/Build/LinuxGeneric/ like seriously? Jul 22 12:24:33 (that's the dir where you perform "make" ... the output appears elsewhere of course) Jul 22 12:33:53 zmatt: welcom to comercial software projects Jul 22 12:40:33 could be worse ... Jul 22 12:40:41 they could have coded in chinese or greek Jul 22 13:08:57 is there any way to enable pwm in 3.14 kernel , We tried the link https://cmumrsdproject.wikispaces.com/Beaglebone+Black+Kernel+3.14+Hardware+Encoders+and+PWM Jul 22 13:12:40 but the dmesg error shows that "failed to get clock" . Please help me to solve this issue Jul 22 13:15:38 check your DT Jul 22 13:15:45 the fault is mostlikely there Jul 22 13:16:08 be aware that DT changed a few times in the past, so you need to adapt it to your kernel version Jul 22 13:36:35 what is exactly the hash in /etc/machine-id? what generates it, and when? Jul 22 13:38:27 root@beaglebone:/etc# grep machine-id * -R Jul 22 13:38:27 init.d/dbus: # Create machine-id file Jul 22 13:38:58 tbr: my bad. i tried the same, but in the /opt/ dir Jul 22 13:39:13 that's what I tried at first too :) Jul 22 13:39:38 next would have been /var Jul 22 13:39:42 then, is there a way to find the bbb hardware revision via bash? Jul 22 13:40:23 you could check for the size of eMMC, that way you can tell >RevB <=RevB Jul 22 13:40:38 also IIRC there is an eeprom, not sure what's in it Jul 22 13:41:05 i barely remember something about an eeprom value, too Jul 22 13:41:09 will investigate, thanks Jul 22 14:05:56 seems like using hexdump -C /sys/bus/i2c/devices/i2c-0/0-0050/eeprom is showing something interesting, but still need to understand the format (i'm looking in the srm right now) Jul 22 14:56:23 samael: first four bytes is just a signature to recognize a valid eeeprom Jul 22 14:56:26 *eeprom Jul 22 14:57:05 A335 cpu Jul 22 14:57:16 BNLT board (= beaglebone black) Jul 22 14:57:22 00C0 revision Jul 22 14:58:59 zmatt: yep, found it in the srm. thanks Jul 22 14:59:32 ah, it's in the SRM? good to know Jul 22 15:03:39 zmatt: §6.4, pg. 63 Jul 22 15:14:04 maybe I should bother at least *browsing* it cover to cover to check it for worthwhile content... Jul 22 15:15:05 pg 64, at least in rev C.1 .. is there newer? git pull says up-to-date Jul 22 15:22:14 Hi - I tried searching and I am not sure if it's possible to write directly to mode pin registers from my code instead of having to load device tree overlays. What if I want to use 2 modes on the same pin in the same program one after the other? Do I just issue shell command to load another overlay? Jul 22 15:23:08 samael: in practice at offset 0x50 there seems to be the identifying info also found on the printed label, or something related to it in format anyway Jul 22 15:23:34 adibis: it is definitely possible, in more than one way Jul 22 15:24:51 you absolutely can go ahead and change things behind the kernel's back, though I expect to get a dirty look from some people for saying that Jul 22 15:25:05 you can also unload one overlay and load another I think Jul 22 15:26:42 zmatt: I don't really mean behind kernel's back. Are there system calls to load the overlays from my program? The only way I found was to echo the dtbo in the slots and then echo - to remove it Jul 22 15:28:26 like everything in sysfs, that *is* the API... just open, read/write, close Jul 22 15:29:50 (with a few subtle points, e.g. when reading you can get a "fresh reading" by seeking to 0, and in some cases you can get notifications using poll() or select() or similar, e.g. to get notified of GPIO changes) Jul 22 15:30:42 I think there's also a new overlay management thing via configfs but I haven't taken a look yet, no idea what it looks like Jul 22 15:30:54 (in the 4.x kernels) Jul 22 15:31:01 Is there an example of how to do that? I've looked at the lwn articles, articles from adafruit, Derek Molloy and other sources I could find. Jul 22 15:31:14 what prog language? Jul 22 15:31:18 C Jul 22 15:31:30 I mean, it's exactly the same as writing a text file Jul 22 15:31:41 probably in any C tutorial book Jul 22 15:31:49 do I directly write to the slots file? Jul 22 15:31:59 you can mmap() the gpio registers and read/write directly to them, bypassing sysfs Jul 22 15:32:05 endoped: correct Jul 22 15:32:42 endoped: though you'll still want to export them (or use the new gpio_helper in device tree) to ensure the GPIO module is clocked Jul 22 15:33:08 endoped: and sysfs is still the easiest way to get events Jul 22 15:33:23 good point Jul 22 15:33:24 adibis: yep, just pretend you're overwriting it Jul 22 15:34:01 Okay - that is what is confusing to me. I see there is content in the file and overwriting should not add a new line but - well - overwrite the whole thing. Jul 22 15:34:20 adibis: that's however also exactly what "echo blah >file" would do if you point it to a regular file Jul 22 15:34:47 sysfs is however a magical place Jul 22 15:35:58 it plays by its own rules Jul 22 15:36:30 true :) going from 8 bit micro to Linux is - hard. I keep going back to writing registers directly and then people shout Jul 22 15:36:47 adibis: oh ignore those people Jul 22 15:36:56 I keep ditching kernel drivers more and more Jul 22 15:37:14 actually made a library which lets me use my baremetal headers in userspace without modification Jul 22 15:37:53 (some linker magic which mmap()s the peripherals I reference, and only those, into the process memory space during initialization before main() is invoked) Jul 22 15:38:13 more elegant is using uio Jul 22 15:38:17 the pinctrl confused me. I was looking at the kernel doc for that and I thought I would be able to use the 'runtime config' APIs to write to the pinmux register for each pin Jul 22 15:38:23 and I still intend to move towards it Jul 22 15:39:26 with uio you can declare in device tree that some peripheral to be accessible from userspace Jul 22 15:40:02 it appears as some /dev/uio which is like a tiny chunk of /dev/mem .. just the region declared in device tree Jul 22 15:40:03 right but that will allow me to access the periph from userspace. Not the pinmux that controls it. Jul 22 15:40:34 as in - if, example - GPIO 0/1 is I2C. I can allow I2C access from DTE to userspace. Jul 22 15:40:51 no, you'd put the pinmux in the same place where you put the uio declaration -- in device tree, or an overlay thereof Jul 22 15:41:01 But if I want to set mode back to GPIO 0/1 then I need to remove last overlay and add new overlay to chage the mode. Correct? Jul 22 15:41:42 that would be Appropriate Way™ afaik yes Jul 22 15:43:05 okay Jul 22 15:43:22 I doubt I will ever need it but it's one of the things that keeps bugging you. Jul 22 15:44:40 like you said, it's rare to need such a thing Jul 22 15:46:03 it's rather unusual for an I2C bus to be attached to or detached from pins at runtime Jul 22 15:46:16 Right - I work in verification and I was working on pinmux verification for a chip. The drivers we wrote are nothing like they use in SW and we would switch the mode runtime and make sure there were no collision. Jul 22 15:46:56 So I just wanted to see how that works in practice. If I have USB and DDR on the same physical pin - how does it switch at runtime when both are in use. Jul 22 15:47:41 poor example since USB and DDR both have dedicated pins Jul 22 15:47:45 well we that that problem in our design :) Jul 22 15:47:45 (since they not normal CMOS I/O) Jul 22 15:48:23 one detail btw about the overlay loading is that iirc you can only unload them in reverse order you loaded them Jul 22 15:48:27 i.e. it's like a stack Jul 22 15:48:38 you can't remove an overlay from the middle of the stack Jul 22 15:49:25 okay - I tried it on the 3.8 kernel and it crashed on me. I just updated to debian testing with 4.x kernel. Will try on that. Jul 22 15:49:45 it = loading one and removing it. Not from middle of stack. Jul 22 15:51:19 I've heard it can be slightly tricky sometimes Jul 22 15:51:56 again, going behind the kernel's back is absolutely possible, but that can be tricky too Jul 22 15:52:49 you need to be sure no kernel driver is making use of those pins Jul 22 15:53:21 (even that rule can probably be sometimes violated, but then you'd really really better know what you're doing) Jul 22 15:54:38 the peripheral you're muxing to needs its clock active... if the kernel thinks the peripheral is unused, you'll need to do that manually Jul 22 15:56:30 I actually have examples of all of that here -> https://github.com/dutchanddutch/jbang Jul 22 15:57:46 it manipulates the input-enable bit of the pinmux registers of the JTAG pins to make the processor *think* they are toggling Jul 22 15:58:12 :) Jul 22 15:59:11 and manually enables the clock to the debug subsystem Jul 22 16:00:30 (this still predates my magic library so it explicitly maps the peripherals needed) Jul 22 16:01:13 okay - last thing. boneScript has a way to change GPIO pull using pinmode. Searching in the bonescript source does not show much. But do they use mmap for that? Becaus sysfs doesn't have GPIO pull. Jul 22 16:01:43 control module has one extra gotcha: it requires kernel-mode (privileged) writes, direct usermode writes are ignored Jul 22 16:02:25 checking the github repo. Thanks. Jul 22 16:02:43 I deal with that in kmemcpy.h Jul 22 16:02:51 though I have a nicer way nowadays Jul 22 16:03:57 http://gerbil.xs4all.nl/privileged.h Jul 22 16:04:10 uses the same defs.h and die.h found in jbang Jul 22 16:04:12 usage: Jul 22 16:04:31 privileged( blah ) = value; Jul 22 16:04:57 makes the write to blah (being something located somewhere in device memory) a privileged write Jul 22 16:05:44 value = privileged( blah ); would likewise do a privileged read, if you need it for some reason (control module only fusses about writes, it's okay with unprivileged reads) Jul 22 16:05:58 yo rcn-ee Jul 22 16:06:23 adibis: pull isn't part of gpio but of pinmux Jul 22 16:06:30 hey zmatt Jul 22 16:07:06 rcn-ee: got a few questions for you... though looking at the clock I think I should first try to get myself out to the door for some shopping... Jul 22 16:07:15 zmatt: always check your priviledges! Jul 22 16:07:27 zmatt, beer comes first. ;) Jul 22 16:07:39 rcn-ee: nope, chocolate. nothing comes before chocolate! Jul 22 16:08:06 zmatt: yeah but bonescript can control it so is it doing it by /dev/mem or dte? Jul 22 16:08:15 KotH, chocolate stout ;) Jul 22 16:08:26 indeed, why not both? Jul 22 16:08:29 ugh... Jul 22 16:08:33 adibis: btw, as usual for C++ library code (e.g. the STL), much of this code is best used without looking at how exactly it is implemented Jul 22 16:08:33 waste of good chocolte Jul 22 16:08:43 but you'd probably use hersheys anways, so no problem there Jul 22 16:09:00 adibis: ;-) Jul 22 16:09:18 adibis: I have no idea what bonescript does, I've never looked at it Jul 22 16:09:40 bonescript usually loads custom *.dtbo's... all compiled at call time.. Jul 22 16:11:03 using /dev/mem intuitively sounded implausible for something like bonescript Jul 22 16:11:26 it would absolutely be what I'd do if I had a need to toggle pull-up/down at runtime Jul 22 16:11:32 but then that's me Jul 22 16:11:42 rcn-ee: aha - so what we were discussing for the C side. If needed - load the DTO an then run it. Jul 22 16:12:12 rcn-ee: so then it must also regularly unload them to accomodate changes right? adibis' first attempt at unloading one resulted in crash Jul 22 16:12:18 unless it's 4.1, then use the "config-pin" interface from cape-manager.. ;) Jul 22 16:12:27 (it's what machinekit's been doing since 3.8.x) Jul 22 16:12:37 ETOOMANYINTERFACES Jul 22 16:13:03 well, it doesn't require a reboot to load/unload -> load/unload... we just tweak the pinmux... Jul 22 16:13:07 is that in any way related to the DT overlay configfs yada I've seen mentioned in my kernel config? Jul 22 16:13:53 what is this config-pin now :-| Jul 22 16:14:17 Yeap.. DT overalys -> load cape-universal (which enables every perhperal), then use config-pin to wire up the gpio to pherpieral.. Jul 22 16:14:57 The machinekit guys use it exclusivly for their cnc/3d printer controls: https://github.com/cdsteinkuehler/beaglebone-universal-io Jul 22 16:15:09 rcn-ee: I've been catching glimpses of the infra but the big picture is still far from clear Jul 22 16:16:10 it's really nice for dynmaicly configuring i/o from userspace.. Jul 22 16:16:23 (without going thru /dev/mem) Jul 22 16:17:13 well if you want to use kernel drivers, going through /dev/mem isn't an option anyway Jul 22 16:17:15 if you want to use P9.24/P9.26 as can: config-pin P9.24 can ; config-pin P9.26 can Jul 22 16:17:39 then if you want to then use usart (for some odd bad reason) Jul 22 16:17:49 config-pin P9.24 uart ; config-pin P9.26 uart Jul 22 16:17:59 no reboots.. ;) Jul 22 16:18:31 rcn-ee: in theory this would have been possible already by unloading the CAN overlay and loading the UART overlay right? Jul 22 16:18:40 provided the kernel doesn't panic in the process Jul 22 16:19:19 zmatt, correct.. "provided the kernel doesn't burn down"... in this case we are only touching the gpio-pinmux, so the can module is still running happily... (doesn't know it's been disconnected) Jul 22 16:19:46 rcn-ee: ... that sounds slightly hazardous Jul 22 16:19:56 (also, waste of resources) Jul 22 16:20:00 good evening Jul 22 16:20:01 wait - if /dev/mem is not allowed while using kernel drivers. What is? sysfs? Jul 22 16:20:03 so all peripherals are being clocked? Jul 22 16:20:04 (and power) Jul 22 16:21:00 adibis: point is that changing the pinmux via /dev/mem (or this config-pin thing apparently) doesn't load/unload kernel drivers for the associated peripherals Jul 22 16:21:21 if neither the old nor new mux uses a kernel driver, then there's no problem Jul 22 16:22:00 e.g. I currently bypass the kernel for: gpio, pwmss, adc (including DMA) Jul 22 16:22:28 nice. So, as per the config-pin, if I change a pin from GPIO to I2C then kernel would know about it? Since it's writing to the sysfs node for that pin in /ocp*// Jul 22 16:22:38 soon adding SPI to the list since I've had it with that piece of shit kernel driver Jul 22 16:22:48 adibis, correct.. Jul 22 16:22:51 can someone please tell me where i find the packages for a BeagleBoneBlack Rev. C ? Jul 22 16:23:12 inoson, "packages" ? Jul 22 16:23:20 rcn-ee: but the I2C driver would already have been loaded anyway? Jul 22 16:23:21 i mean the xdc-packages Jul 22 16:23:31 rcn-ee: it's just suddenly seeing the bus Jul 22 16:23:41 Can't find the platform package 'ti.platforms.beaglebone' is the error-message Jul 22 16:23:58 zmatt: conceptual question again - pretty sure I would never have to mess around with this. Jul 22 16:24:08 zmatt, yeah you'd still have to "add" the i2c device, but atleast the bus is now avaialble on that pin.. Jul 22 16:24:27 rcn-ee: so... what does a peripheral see when nothing it muxed to it? Jul 22 16:24:45 I suspect logic 1, but I can't say I'm sure Jul 22 16:24:55 zmatt, essientially nothing... (just floating lines) Jul 22 16:25:09 unless pulled, right? Jul 22 16:25:16 you can't see a floating line, and you can be 100% sure they're not left floating internally Jul 22 16:25:25 well the config-pin controls the pull up too.. Jul 22 16:25:31 that's the outside Jul 22 16:25:36 I'm talking about the inside Jul 22 16:25:46 the peripheral's view Jul 22 16:26:03 won't the peripheral have a default weak-pull to avoid floating? Jul 22 16:26:48 adibis, P9_17: Mode 7, Pull-Up, RxActive Jul 22 16:26:55 https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universal-00A0.dts#L461 Jul 22 16:27:27 adibis: afaik it's very unusual to use tristated lines internally in ICs Jul 22 16:27:42 adibis, when setup for i2c, config-pin will change it to: "Mode 2, Pull-Up, RxActive" Jul 22 16:29:56 adibis: I suspect, in case of a peripheral that has multiple mux options, the peripheral's input signal is (RX_0 | ~EN_0) & (RX_1 | ~EN_1) & ... Jul 22 16:30:31 hence logic high when all mux options are disabled Jul 22 16:31:07 but I've never checked this, it's just based on the problems some people had with peripherals accidently muxed to multiple pins Jul 22 16:31:13 i only want get a tirtos running nothing else, is it so hard? Jul 22 16:31:39 in case there's only one mux option, the peripheral may also receive the signal unconditionally Jul 22 16:31:42 <_av500_> inoson: few people here use TI RTOS Jul 22 16:31:55 <_av500_> inoson: most people here run linux Jul 22 16:32:11 e.g. iirc you can view the pin levels via GPIO even if pins aren't muxed to GPIO Jul 22 16:32:27 <_av500_> inoson: so asking at TI e2e might give you more help Jul 22 16:33:03 ok thx for the answer and perhaps we see us later. Jul 22 16:33:15 I do know disabling the receiver causes the internal level to be viewed as 0 Jul 22 16:34:05 (even works for nRESET, which for reasons that elude me also has a pinmux register) Jul 22 16:34:20 jatag resets could be muxed on it? Jul 22 16:34:31 Or might just be part of the padring - copy paste :D Jul 22 16:34:49 yeah they made a register for each pin, even where it makes no sense Jul 22 16:35:02 the big winner being PORz Jul 22 16:35:47 could it be for DFT and boundary scanning? Jul 22 16:35:49 rxenable for that one actually doesn't work Jul 22 16:35:51 no Jul 22 16:36:00 JTAG isn't in the boundary scan chain :) Jul 22 16:36:10 but does have pinmux regs Jul 22 16:36:20 hmm Jul 22 16:36:26 which do in fact work, that's exactly how jbang works Jul 22 16:36:58 to be honest, a lot of the am335x looks like it was done Jul 22 16:37:04 1. by an intern, or Jul 22 16:37:13 2. by someone who was drunk Jul 22 16:37:18 3. really really in a hurry Jul 22 16:37:26 possibly all of the above Jul 22 16:38:42 haha - hurry/cost saving might be it. You write a script to generate RTL from a spreadsheet that has all pins Jul 22 16:38:47 a pinmux is added everywhere Jul 22 16:38:56 they don't want to hack it and remove for unwanted pins Jul 22 16:39:23 time to leave for work = where they disabled freenode :( thanks for the help. Jul 22 16:39:36 reused existing 811x design, couple of changes (possibly copy-pasted from Aegis), backspaced whole bunch of modules Jul 22 16:39:54 though removing their target agents and clock lines was too much hassle so those were left in Jul 22 16:40:22 PRCM stuff shoveled into a register file in random order Jul 22 16:40:28 ta-da, ready to roll Jul 22 16:41:12 c'ya adibis Jul 22 16:48:50 * zmatt notes the casual use of terms like DFT, boundary scan, padring, and RTL, and sticks a "clueful" label onto adibis Jul 22 16:49:49 oh wait, I was on my way to do shopping Jul 22 16:59:08 <_av500_> shopping is hard, lets do electronics Jul 22 16:59:10 rcn-ee: ahh, so that's the clue of bone-pinmux-helper... it just creates a sysfs entry to allow runtime switching between pinmux options Jul 22 17:00:53 why does *it* get to have its node name actually visible in sysfs while gpio_helper actually makes me specify the name of a pin twice (once as node name and once as property) yet doesn't let me actually find/access the gpio by that name :/ Jul 22 17:01:44 zmatt, i think gpio "name" was just posted on lkml last week .;) Jul 22 17:02:44 as a patch? ooh, me wantz, have a link? Jul 22 17:03:00 I also had to do a hideous hack to make decent symlinks for uio devices Jul 22 17:04:05 some here: https://lwn.net/Articles/651500/ Jul 22 17:07:51 rcn-ee: that's kinda cool. Jul 22 17:08:26 jkridner, more like... about time. ;) i don't want to remember "gpio 48" .. eMMC reset ;) Jul 22 17:09:50 I also realized those of_node symlinks are relatively new and mean I can get rid of the horrid hack I previously had to give uio devices sensible names Jul 22 17:12:16 now it's just Jul 22 17:12:17 SUBSYSTEM=="uio", SYMLINK+="uio/%s{device/of_node/uio,name}" Jul 22 17:13:11 (yes yes inappropriate use of the semantics of the comma, I'll fix... some day) Jul 22 17:13:49 now really afk Jul 22 18:17:21 rcn-ee: hehe, the current gpio interface is not getting a lot of love... Jul 22 18:17:34 "I must say I like this series. Because it makes the GPIO sysfs ABI *less* insane." Jul 22 18:19:52 sounds like the series (possibly minus one) is going to make it Jul 22 18:29:18 it's kinda funny that "basic" stuff like this is still actively being sorted out as we speak... but I guess it's only recent that the microcontrollers where people want to fiddle with gpios and such and the processors where you'd run a "normal" linux system have only recently come to overlap Jul 22 18:48:26 and its not a particularly happy marriage for the hobbyist Jul 22 18:53:00 <_av500_> shotgun wedding Jul 22 18:53:48 heh _av500_ Jul 22 19:12:07 stt_michael: indeed Jul 22 19:14:49 stt_michael: I was actually happier on the baremetal, but the relative comfort and wealth of tools available in linux userspace is too great to reject for most Jul 22 19:19:01 I really wish TI had done some things differently... like making the Cortex-M3 an L3 initiator instead just the L4WKUP would have made a big difference Jul 22 19:21:25 so you'd actually have a microcontroller for realtime stuff and the cortex-a8 as comfy chair Jul 22 19:22:36 or even simpler change: just let the A8 boot in secure mode on GP devices damnit Jul 22 19:23:08 then you can run an RTOS (in secure world) and linux (in public world) in parallel Jul 22 19:24:06 instead, on GP devices bootrom just renders secure world unusable Jul 22 19:26:17 reserving a bunch of random resources along the way, like FIQ, the ability to use EDMA's memory protection to prevent different EDMA users from accidently messing up each other's data, etc Jul 22 19:52:36 * _av500_ cries over the lost FIQ Jul 22 19:52:38 <_av500_> seriously Jul 22 19:56:41 ? Jul 22 19:58:02 nm, read backscroll... Jul 22 19:59:32 not a TI product but that sounds like udoo Jul 22 20:02:13 i.MX6 plus SAM3 Jul 22 20:03:46 _av500_: since on the DM814x the "secure" rom hadn't been secured, I've also seen what the secmon FIQ-handler (which is where FIQ gets redirected to) looks like Jul 22 20:04:49 ooo ooo oo more imx6 ... Jul 22 20:06:02 SATA on the new Duals :D Jul 22 20:06:37 well ok .. was prob. on original dual .. but the duallite is used on the wand-dual :/ Jul 22 20:06:48 I don't fancy resoldering :/ but its probably possible ... Jul 22 20:09:39 <_av500_> zmatt: I like FIQ for "poor man's RTOS" stuff Jul 22 20:18:57 _av500_: http://gerbil.xs4all.nl/gp-mon.s.html Jul 22 20:19:25 _av500_: the last vector is the excellent purpose for which secrom chose to reserve FIQ Jul 22 20:21:02 (I included the smc handler code mainly for its beauty) Jul 22 20:24:03 _av500_: really fun if you don't know this and accidently configure an interrupt to be directed to FIQ Jul 22 20:25:15 system goes dead, JTAG can't tell you why since the debugger lost access, have fun Jul 22 20:27:17 _av500_: not sure what you mean by "poor man's RTOS" though... FIQ isn't quite as useful on a cortex-a8 as it was on smaller ARMs Jul 22 20:28:49 considering interrupt latency, and the new srs/rfe instructions which make interrupt nesting a lot saner Jul 22 20:29:35 (you actually don't have to spend more than two or three instructions in any mode other than supervisor or user/system) Jul 22 20:51:25 <_av500_> zmatt: I used it last on ARM9 :) Jul 22 20:51:41 <_av500_> wanted to play with it in BBB but it was fubar Jul 22 20:52:55 _av500_: yeah, the ARM9 was its home Jul 22 20:54:13 the name "FIQ" is a bit of a misnomer on the cortex-a8 anyway given that entry would be >13 cycles Jul 22 20:56:23 but if you really want it back, I still know of a potential way to grab hold of secure world on (GP) am335x devices, haven't had time to explore it Jul 22 20:59:20 (previous vuln just resulted in a pissed-off Secure State Machine hitting the "mpu security violation" reset button, but this one would act during very early boot before the SSM is in shoot-first-ask-questions-later-mode) Jul 22 21:02:42 <_av500_> nah Jul 22 21:05:01 trustzone would be very nice to have though... basically hardware VM support but hardcoded for two VMs, so switching between them is just a matter of flipping a bit that selects between banked registers Jul 22 21:06:06 you could probably actually manage hard real-time stuff in sec world while linux runs in pub world Jul 22 22:37:56 Hello all, I am having trouble flashing my beaglebone black. I hold down the S2 button but it still just launches into the existing image Jul 22 22:46:02 Also I looked to flash the eMMC and I do not have a eEnv.txt file in boot Jul 22 22:46:31 have you tried re-creating your micro-SD card? Jul 22 22:46:52 yes I have I tried with an 8GB one and a 64GB sd card Jul 22 22:51:25 do you have any smaller ones, in case its a size issue .. Jul 22 22:51:35 actually .. 8 should work.. Jul 22 22:55:09 yeah I am having no luck... I have a 2 but its not big enough Jul 22 23:24:34 holding down the SD button during power on (note: mere reset does not suffice) *will* force the BBB to boot from SD, or at least something other than eMMC Jul 22 23:26:29 you should be able to verify that by power on with the button pressed but no SD card, it should fail to boot at all. if you then insert the SD card it should boot from it (may take a few seconds before the bootloader tries again) Jul 22 23:28:07 (unless connected via USB to a PC actually) Jul 22 23:29:27 however I recall I've seen it happen that the bootloader on the SD card subsequently happily boots the eMMC linux system Jul 22 23:30:07 though I'll admit this was very long ago, back in the age of Angström Jul 22 23:30:19 haven't used SD-boot since then Jul 22 23:30:50 what sd image are you using? Jul 22 23:32:32 that is a very irritating feature of u-boot Jul 22 23:32:54 yeah there are many fascinating ways in which this can go wrong Jul 22 23:33:12 MLO can load the wrong u-boot Jul 22 23:33:18 u-boot can load the wrong kernel Jul 22 23:33:51 most versions of U-boot I see will try to load a kernel off the SD card first Jul 22 23:33:53 and if it passes the wrong options, the kernel can use the wrong rootfs Jul 22 23:34:05 the u-boot script is horrible Jul 22 23:34:23 indeed Jul 22 23:34:38 it should expect the bootable system from one place and only one place: the one it came from itself Jul 22 23:34:46 really need to find time to get u-boot to read config from the i2c rom Jul 22 23:35:04 why i2c? Jul 22 23:35:31 no other easy to use flash Jul 22 23:35:43 eMMC depends on how it is formated. same with sd Jul 22 23:35:47 if I understand correctly, by default it tries to load its uenv from one of the boot partitions of eMMC Jul 22 23:36:03 boot1 I think Jul 22 23:36:16 that makes assumptions on the eMMC Jul 22 23:36:37 zmatt: is the 3V3B stuff sorted out for your stuff? Jul 22 23:37:13 is that bad? the boot partitions are generally overlooked (e.g. when using BBBlfs or uboot's "ums" to expose the eMMC you can't even access them) Jul 22 23:38:41 removing the regulator and tying 3v3b to 3v3a seems to work fine Jul 22 23:40:28 I hadn't gotten around to trying linux on my BatBeagle though, other stuff had priority and the test won't mean much unless it's with whatever type of battery we are intending to use, but a certain coworker keeps forgetting to order one Jul 22 23:40:38 the boot partitions get treated in a special way by the eMMC Jul 22 23:40:55 zmatt: but PM works? nothing frys? Jul 22 23:42:04 ds2: eMMC has two boot partitions that are totally separate from the "user partition" ... it's the user eMMC-partition that actually gets subsequently fdisk-formatted (or gdisk if you prefer) Jul 22 23:43:55 how could anything fry? the worst that could happen is insufficient power being supplied, but that's mostly a constraint on external hardware... the bbb should definitely have enough for itself Jul 22 23:46:04 also, why the fuss about assumptions about eMMC ? given that that's where u-boot itself would be coming from ? Jul 22 23:46:29 I'd be more interested in an u-boot compiled with a sane built-in script Jul 22 23:46:58 (or possibly an alternative to u-boot) Jul 22 23:47:30 dd if=/dev/zero you'll stop the emmc booting :) Jul 22 23:48:05 yes, it's pretty idiotic rom doesn't use the eMMC boot partitions for their intended purpose Jul 22 23:48:18 especially given that it's actually easier to boot from those than from the main partition Jul 22 23:48:44 but maybe they're too new or something Jul 22 23:50:47 zmatt: fry was for the 3V3B/3V3A stuff not the eMMC stuff Jul 22 23:51:22 my only objection to the boot stuff is that the eMMC treats it differently Jul 22 23:51:42 it is higher in reliability then the rest but might not be rated for as may cycles Jul 22 23:52:43 how often do you plan to save your boot env exactly? Jul 22 23:53:04 and I understood the fry was about the 3v3, and replied based on that Jul 22 23:53:09 more often then I'd like during development Jul 22 23:53:28 huh, what for? Jul 22 23:53:39 zmatt: something from the orig. 3V3B rail spiking the 3V3A stuff Jul 22 23:53:56 I wind up changing bootcmd often during dev. Jul 22 23:54:04 I mean, the normal u-boot doesn't even have a saveenv command Jul 22 23:54:23 hmmm? Jul 22 23:54:35 the one from current debian images Jul 22 23:54:42 you mean normal for beagles? Jul 22 23:54:45 yes Jul 22 23:54:50 ah Jul 22 23:54:55 I use other boards that do implement it Jul 22 23:55:11 yeah, I admit it is a bit odd not to support it. Jul 22 23:55:15 but it does read uEnv.txt and you can execute commands based on that Jul 22 23:55:28 not sure if u-boot knows how to write to mmcblk0bootX Jul 22 23:55:43 uEnv.txt is cumbersome enough that i find it easier to rebuild the kernel with a hard coded cmdline Jul 22 23:55:45 jkridner: well if it can read it, it can write it Jul 22 23:55:49 Ok I think I got it, now its booting to the Debian os but in the files I see a beaglebone SD card icon there even though there is no sd card installed. Any ideas why its there? Jul 22 23:55:55 zmatt: not sure if it can read it. Jul 22 23:56:48 jkridner: yep, someone was here a while ago who was driven close to madness because no matter how well he thought he wiped his BBB, the damned config he once did gets coming back at him Jul 22 23:57:08 *kept Jul 22 23:57:24 since it was read from one of the eMMC boot partitions, which he overlooked Jul 22 23:59:45 ds2: if I'd be regularly changing bootloader, its config, or kernel, I'd personally switch to netbooting Jul 23 00:01:05 zmatt: that assumes you have a working ethernet Jul 23 00:01:13 i want to get rid of the ethernet Jul 23 00:03:09 right, you mentioned that once... Jul 23 00:03:15 ehm, uart booting then? ;-) Jul 23 00:03:46 quicker to sneakernet uSD Jul 23 00:04:36 now I remember what I forgot to check... JTAG connectors Jul 23 00:05:19 hah, I wouldn't be surprised if uart-booting is faster than upload via JTAG Jul 23 00:05:38 well okay that's not fair Jul 23 00:06:22 jtag should be more reliable Jul 23 00:06:26 o.O Jul 23 00:06:31 jtag has no error checking whatsoever Jul 23 00:06:35 not even a parity bit Jul 23 00:06:57 any glitch can make one of those writes land anywhere Jul 23 00:07:04 yes but i don't see as many issues on jtag for memory dumps Jul 23 00:07:16 seems serial is glitchier but it could be the lengths of cable Jul 23 00:09:35 I see no reason one or the other would be more or less reliable at the same cable length and bitrate Jul 23 00:10:45 except that with jtag if your cable is shitty enough to cause any significant amount of glitches, probably stuff will end up confused enough for the debugger to notice Jul 23 00:11:33 only thing to worry about when dumping lots of data via the uart is the too-many-posted-writes-bug Jul 23 00:12:06 most uart code appears to be too inefficient to hit that bug though, alternatively using DMA also avoids it Jul 23 00:18:53 no wait, there are actually good reasons for async serial to be tricker than jtag at same bitrate... though that manifests itself mostly in the fact that serial ports normally can't be configured at jtag-like bitrates at all Jul 23 00:32:56 (the PRU-UART being an exception with its max 12 MHz) Jul 23 00:54:02 Hello, does anyone know what the height is for the beaglebone black? Jul 23 00:58:30 Tesla: spec sheet says .187" max Jul 23 00:59:15 for the height? .187 seems kind of thin Jul 23 01:01:49 yeah, oops Jul 23 01:02:01 I measure about 19 mm Jul 23 01:02:03 i have no idea what that spec is for... pcb? Jul 23 01:03:44 yeah, got about 19mm as well Jul 23 01:03:57 ok, thanks! Jul 23 01:05:11 should be in the SRM Jul 23 01:40:47 Hello, I have a question about the camera cap, as my understanding, the camera cap and emmc booting can not be used as the same time because some of GPMC signals are used on the black board. is my understanding right? thanks a lot! Jul 23 01:59:24 if the cap use the pins of the emmc... Jul 23 02:06:23 @nyo, thank you. yes, the cap uses the pin shared with emmc on the connector 8. **** ENDING LOGGING AT Thu Jul 23 02:59:59 2015