**** BEGIN LOGGING AT Thu Apr 09 02:59:58 2015 Apr 09 04:09:09 does qt5.4 work on beagle without x (framebuffer?) Apr 09 04:09:19 running debian Apr 09 06:59:48 is there anyone on here right now that can give me a tip on how to use interrupts with the BBB programmed in C? Apr 09 07:00:25 I can set the gpio ports to be edge triggered as needed but i'm at a loss as to how to actually use them Apr 09 07:00:40 google is letting me down :( Apr 09 07:08:44 Anyone here familiar with regex got some time? I'm reading live data streams from stdout using pexpect, and I'm looking to capture a line with a specific character sequence. Apr 09 07:21:35 hello my name april Apr 09 07:21:49 i want to ask you about beaglebone Apr 09 07:22:28 can you help me ? Apr 09 07:23:14 just ask Apr 09 07:25:09 why my beaglebone nothing dpkg ? Apr 09 07:26:18 my promblem b-process /usr/bin/dpkg returned an error code (1) Apr 09 07:26:52 my problem -process /usr/bin/dpkg returned an error code (1) Apr 09 07:29:23 april_ please pastebin the whole output Apr 09 07:29:30 pastebin.com Apr 09 07:31:34 anyone have any info on how to actually use the interrupts after setting a gpio port to trigger on both rising and falling edge? I'm at a loss... Apr 09 07:33:23 hi shoragan Apr 09 07:33:38 what your means ? Apr 09 07:33:53 #woglinde Apr 09 07:35:25 april - i think he wants you to stick the entire output of your program onto pastebin.com and then link it here for him to see. Apr 09 07:35:56 april_ your error msg is not enough to see the problem Apr 09 07:37:55 ok thanks #bunny and wogline Apr 09 07:44:19 hi woglinde Apr 09 08:18:46 is anyone here able to help me understand how to use interrupts on the BBB? My google-fu is failing me and my project is due in a few hours :( Apr 09 08:25:53 Bunny_: usually, you write a kernel driver Apr 09 08:32:30 do you have a link or anythuing on how to do that? Apr 09 08:33:05 is it possible to do in C code? Apr 09 08:33:26 uh... Apr 09 08:33:29 I'm trying to use them to decode a quadrature encode Apr 09 08:34:02 for reference - i have very little knowledge of linux/debian/etc Apr 09 08:34:08 not even sure what a kernel is :$ Apr 09 08:34:09 buy this book and read it: http://www.amazon.com/Linux-Device-Drivers-Jonathan-Corbet/dp/0596005903 Apr 09 08:34:18 my project is due is 6 hours... Apr 09 08:34:23 *in Apr 09 08:34:25 but you know what interrupts are? Apr 09 08:34:47 yeah Apr 09 08:34:53 you will also need http://www.amazon.com/Understanding-Linux-Kernel-Third-Daniel/dp/0596005652 and http://www.amazon.com/Linux-Dummies-9th-Richard-Blum/dp/0470467010/ Apr 09 08:37:40 i just dont know how to go from setting the gpio port with echo "both" > edge to actually haveing something happen in my c code based on that Apr 09 08:38:41 is there not something simple i can do to be able to trigger my c code based on the interrupts? Apr 09 08:38:42 "To get events, just do a blocking read to the value file, and the read will block until the event occurs." Apr 09 08:39:55 wouldnt that just permanently pause my code...? Apr 09 08:40:21 it would pause your code until the edge triggers, yes Apr 09 08:40:33 i need my code to run until the edge triggers. Apr 09 08:40:41 its for motor control Apr 09 08:40:48 but i need to read the encoder values Apr 09 08:41:04 asynchronous I/O would probably be your friend Apr 09 08:41:06 or maybe threads, but probably asynchronous I/O Apr 09 08:41:32 I hear good things about libuv, but I've never used it Apr 09 08:45:56 thanks guys, I'll take a look at the things you linked/mentioned Apr 09 08:46:08 i may be back in a few hours... :P Apr 09 08:46:25 * KotH wonders what Bunny_ has been doing the last couple of months, if his project is due in 9h Apr 09 08:46:51 yeah I'm wondering that too.... <.< Apr 09 08:47:19 i didnt have the electronics portion of it available until about a week ago unfortunately... Apr 09 08:48:05 Bunny_: which school are you in? Apr 09 08:48:15 Simon fraser Apr 09 08:49:09 * KotH makes a note not to hire anyone from there Apr 09 08:49:10 ;-> Apr 09 09:30:49 Hi everybody Apr 09 09:31:31 I am using beaglebone black Revision B. I have 4D touch screen. I tried to all of the pre-built images. But I can not boot anyone. There is notihing on the screen. I tried to boot on LCD screen via HDMI. I am writing image to sdcard with ./mkmmc-android.sh /dev/sdb I don't know where the wrong is? Do you have any information about this? Apr 09 09:32:00 have you connected a serial cable to the debug port? Apr 09 09:33:05 I connected via hdmi cable and touch screen Apr 09 09:33:18 How can I debug port? Apr 09 09:33:57 http://bit.ly/1GrYKwA Apr 09 09:35:40 No. I didn't connect a serial cable Apr 09 09:37:05 I tried the android 4.0.3 pre-built image. It boot firstly. But I tried to again, there is nothing on the screen. Apr 09 09:37:26 Did you boot the pre-built image on beaglebone black? Apr 09 09:37:38 I hope I have problem about hardware Apr 09 09:38:02 Because it is pre-built image Apr 09 09:39:10 I don' t need to do anything else. Only I am writing it to sd card via ./mkmmc-android.sh /dev/sdb Apr 09 09:39:43 Otherwise, I tried to boot bbbbandroid on same beagleboneblack, it runs very well Apr 09 09:50:34 muzeyyen: your problem can be equally well a software issue Apr 09 09:51:11 muzeyyen: do you know whether you have the driver for the lcd installed? whether it has been initialized correctly? whether the display settings are right,.... etc pp Apr 09 09:51:26 muzeyyen: that's why you connect a serial cable and see what the BBB does Apr 09 09:53:45 No. I didn' t install driver for lcd Apr 09 09:54:29 Bbbnadroid has been initialized correctly with same beaglebone and same lcd screen Apr 09 09:55:33 Is there other display settings for Texas pre-built images? Apr 09 09:56:00 I saw someone boot with touch screen like me. Apr 09 09:56:28 What must I do? I don't know Apr 09 09:56:40 I lost a lot of time for this Apr 09 10:02:31 * KotH has no idea Apr 09 10:02:38 hardly anyone uses android on the BBB Apr 09 11:27:38 Hellow.. Apr 09 11:28:01 Hi, I notice in the current distro, mmcblk0p1 is mounted to /media/BEAGLEBONE rather than /boot. I'm looking to either remove the automount (if it isn't required) or make it mount RO. However, it's not in fstab, so does anyone know how it's being mounted? Apr 09 11:48:48 automounting to /media sounds like something udisks does Apr 09 13:00:36 has anyone used ds18s20 ? Apr 09 13:01:56 https://www.google.com/search?q=ds18s20+beaglebone Apr 09 13:04:04 yeah, I asked if anyone HERE used it Apr 09 13:04:06 :) Apr 09 13:04:54 let'sa assume somebody said "yes" Apr 09 13:05:19 I did a lot of googling and in short this thing seems to require an external psu Apr 09 13:05:26 on the beagleboard Apr 09 13:05:32 seems to work on pi and avr Apr 09 13:05:49 http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/ I followed this one Apr 09 13:06:31 I am just not sure what to do about +5V and gnd Apr 09 13:06:37 if it can't draw it all from the beagleboard Apr 09 13:08:26 Ad0: get a bus pirate :) Apr 09 13:08:38 hehe Apr 09 13:08:41 what does that mean? Apr 09 13:11:39 is it possible to get from the +5V straight off the barrell connector Apr 09 13:12:04 Ad0: Yes, check the srm Apr 09 13:12:17 Ad0: also the sensor has Vdd from 3 to 5V Apr 09 13:12:53 hm Apr 09 13:13:24 yes Apr 09 13:14:02 but seems like it should be beaglebone +3.3 v -> 4.7k ohm -> W1 -> PIN 11 Apr 09 13:14:13 iirc P9 has two 5V Pins, one is directly connected to the input voltage Apr 09 13:14:13 and that vdd and gnd is something external Apr 09 13:14:20 right Apr 09 13:14:26 does that go for +3.3V? Apr 09 13:15:02 is it VDD_5V or SYS_5V? Apr 09 13:15:37 uhm you do want to connect to 3.3V, not 5V Apr 09 13:15:58 if you want to connect the datapin to beagle Apr 09 13:16:02 yes but I already connect to VDD_3.3V Apr 09 13:16:29 and? Apr 09 13:16:40 and the reading is 85000 which is max Apr 09 13:16:55 so clearly it doesnt output correctly Apr 09 13:17:02 Hi, I'm reading through the beagleboard repo on github but I'm just wondering: what patches do I need on top of mainline for the BBB rev C? Apr 09 13:17:13 root@beaglebone:~# cat /sys/devices/w1_bus_master1/28-000006a0cbd5/w1_slave Apr 09 13:17:13 50 05 4b 46 7f ff 0c 10 1c : crc=1c YES Apr 09 13:17:13 50 05 4b 46 7f ff 0c 10 1c t=85000 Apr 09 13:17:34 (I want to build from a upstream source) Apr 09 13:19:14 you dont need the 4.7k Apr 09 13:19:19 only for multiple sensors Apr 09 13:19:20 http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/ - I guess the DTS part is necessary Apr 09 13:19:40 av500: I thought I needed it for one or multiple, kust that you don't need more than one for multiple Apr 09 13:19:46 just* Apr 09 13:20:03 I feel rotten having 0 resistance from vdd to gpio Apr 09 13:21:28 "You will need to connect a 4.7k resistor between the data wire and 3V wire. This diagram shows 5V, but we can still have it work using 3V. You only need one if you are using multiple sensors. More on this below." Apr 09 13:22:42 Ad0: the dts on this page is using an internal pullup it seems Apr 09 13:24:07 then it should have been 0 in value in that case Apr 09 13:24:40 I ordered the DS18B20+PAR which looks like a half circle, not the DS18B20+ which looks flat Apr 09 13:25:12 but the data sheet on that +PAR page links to the normal DS18B20 datasheet Apr 09 13:25:15 I dunno what to believe Apr 09 13:25:29 Ad0: Have you trible checked the correct bbb pin? Apr 09 13:25:40 yes Apr 09 13:25:48 checked 1000 times Apr 09 13:25:55 like, the device shows up Apr 09 13:25:57 Ad0: what happens when you put +3/gnd on this pin? Apr 09 13:25:58 Ad0: NOOO Apr 09 13:26:00 not 0ohm Apr 09 13:26:04 just remove it Apr 09 13:26:09 ok Apr 09 13:26:12 what would happen Apr 09 13:26:12 connect GND to GND Apr 09 13:26:16 VCC to VCC Apr 09 13:26:23 and BBB GPIO to DQ Apr 09 13:26:31 its really that simple Apr 09 13:26:58 still gives the saem reading lol Apr 09 13:27:25 let me take a picture Apr 09 13:33:23 http://i.imgur.com/G86VON9.jpg Apr 09 13:36:29 *twisting face* Apr 09 13:37:41 http://datasheets.maximintegrated.com/en/ds/DS18B20.pdf page 6 Apr 09 13:38:03 I am using figure 5 Apr 09 13:38:05 right Apr 09 13:38:27 wtf is vpu Apr 09 13:42:07 maybe the DTS was fucked? Apr 09 15:23:40 Hi, I'm trying to get a LCD 7'' working on the beaglebone. I have produce an image using Yocto daisy. Now the HDMI is well working. I suppose I have some instruction to add to the uEnv.txt but after having test some options I'm still no able to get it works Apr 09 15:25:01 erakis, is daisy using ti's v3.14.x ? Apr 09 15:29:00 rcn-ee : Yes 3.14 Ti Apr 09 15:29:24 rcn-ee : I'm not really sure but almost Apr 09 15:29:31 grab my dtb-rebuilder (3.14-ti) branch: https://github.com/RobertCNelson/dtb-rebuilder/tree/3.14-ti Apr 09 15:29:44 build and copy *.dtb you need for your device-cape.dtb Apr 09 15:32:05 rcn-ee : Ok, I was thinking that we have to add options to the uEnv.txt ? Apr 09 15:33:20 i don't think 'yocto' has that out of box option yet... Apr 09 15:33:29 (haven't seen anyone work on it) Apr 09 15:36:56 rcn-ee : So, if I well understand, Yocto is using the default dts (arch/arm/boot/dts/am335x-boneblack.dts). This one probably doest not activate the LCD ? So I have to build a new one that is conform to my need ? Apr 09 15:37:45 erakis, correct... Apr 09 15:39:14 rcn-ee : As an exemple I could use this one (am335x-bone-4dcape-70t.dts) to build my configuration ? And no changes necessary on the uEnv.txt ? Is the HDMI will still working ? Apr 09 15:41:06 erakis, yeap start with: https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-4dcape-70t.dtsi it's a bunch of *includes* but i'll get you a pincfg that work.. Apr 09 15:41:31 btw all the "P8_27_pinmux" Apr 09 15:41:53 's for a custom driver that isn't in the yocto branch, so just ignore that and make user you use the standard pin settings for dtb's.. Apr 09 15:47:55 rcn-ee : Thank :) Apr 09 17:23:21 Is there any way to easily enable UART3 on boot like you can do with the others? Adding BB-UART3 to capemgr.enable_partno in uEnv.txt doesn't do it. I have a very IO intensive application and need to save as many pins as possible; for serial I only need TX so UART3 seems like the logical choice. Apr 09 17:24:42 egan, http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Loading_custom_capes Apr 09 18:13:54 i wonder, there is no delay function ? Apr 09 18:35:41 Has anyone found the Adafruit_BBIO.UART.setup() function to be extremely slow? I've traced a slow down in my code to that function, which takes 60.3s to complete. Is there any way to mitigate this? Apr 09 18:38:47 lol? 60s? Apr 09 18:40:25 that sounds more like a 60-second timeout on something expiring (+ 0.3 s for the actual work) Apr 09 18:41:34 rcn-ee: this patch may be interesting -> http://e2e.ti.com/support/arm/sitara_arm/f/791/p/411763/1473184#1473184 Apr 09 18:41:48 rcn-ee: it makes the omap-sham *not* corrupt memory Apr 09 18:48:43 thanks zmatt, found it on lkml. ;) Apr 09 18:48:46 adding to queue Apr 09 18:49:24 ah ok, I wasn't sure how quickly patches that show up on e2e propagate to the big outside world Apr 09 18:50:56 it's funny, v2 was emailed on April 2nd to lkml, the issue on e2e with the patch was on April 8th. ;) Apr 09 18:51:38 I guess my expectations are still a bit skewed by hanging out in the dm814x forum, where no TI-supplied patches show up at all, and customer-supplied patches for known long-standing issues never get committed to any git repository whatsoever Apr 09 18:52:33 just gota ping tony on those now? he seemed to be pushing the dm814x stuff mainline one subsystem at a time.. Apr 09 18:52:49 he's currently still focussing on dm816x Apr 09 18:53:14 <_av500_> dm81xx is still a thing? Apr 09 18:53:21 and most of the patches will be irrelevant -- the official dm814x kernel is ... old Apr 09 18:53:48 _av500_: the dm814x is a really cool processor, if only TI cared to support it Apr 09 18:54:26 <_av500_> zmatt: I know, I have been using TI SoCs for >10ys Apr 09 18:54:26 the c6a811x is possibly even cooler for many applications, if only TI cared to even admit its existence (outside of automotive applications( Apr 09 18:56:27 (c6a811x is like a cross between the dm814x and am335x... so you get cortex-a8 + DSP + dual cortex-m3 + pruss + I think 3x pwmss, etc) Apr 09 18:57:24 this is the most informative TI product page available for it -> http://www.ti.com/product/dra626 Apr 09 18:59:34 _av500_: we designed a board around the dm814x before the support situation became apparent... :( Apr 09 19:01:18 rcn-ee: current dm81xx kernel is (heavily patched) 2.6.37 Apr 09 19:02:21 iirc Apr 09 19:04:25 yup Apr 09 19:05:40 _av500_: but it's "still a thing" in the sense that it's officially supported in the context of the ipnc-rdk and dvr-rdk Apr 09 19:05:56 outside of those applications, you're on your own Apr 09 19:07:17 the newer dm38x went straight to those applications, there's not even a public TRM for it Apr 09 19:07:51 and the dm814x is also the automotive dra65x, about which you won't find anything either of course Apr 09 19:14:12 rcn-ee: but I'm sporadically active on the linux-omap list now to occasionally give input where I think it may be useful Apr 09 19:16:11 _av500_: what's your feeling about the am572x getting branded Sitara ? it kinda seems like a death sentence for the DaVinci brand altogether Apr 09 19:35:29 <_av500_> zmatt: I have no idea about sitara vs davinci Apr 09 19:35:49 <_av500_> and I'm pretty used to using TI stuff without much support Apr 09 19:36:11 <_av500_> we used to release products on engineering samples while TI was still qualifying :) Apr 09 19:39:19 hehe Apr 09 19:40:23 well, they sometimes to take their time with qualifying... Apr 09 19:41:31 (about smartreflex on dm814x): dec 6, 2011 "It is being characterized & not completed yet.", May 29, 2012 "Unfortunately, We do not support SmartReflex yet. Once we do, we will put in our SDK release." Feb 18, 2013 "Sorry but the SmartReflex is not going to support on DM8148." Apr 09 19:41:53 <_av500_> heh Apr 09 19:42:53 smartreflex.... we still don't have 'full' support for the omap3630/dm3730. ;) Apr 09 19:44:35 lack of docs can be annoying too... especially since I was interested in the crypto accelerators (i.e. the Security Subsystem on the dm814x) Apr 09 19:45:14 you'd think those would be close to the am335'x... Apr 09 19:45:26 yes and no Apr 09 19:45:41 the components are the same (though fewer on the am335x) Apr 09 19:45:42 yay, for random generation changes. ;) Apr 09 19:45:54 but am335x just have them as separate peripherals Apr 09 19:47:29 dm814x has a subsystem with 2x AES, 2x Hash, DES, PKA, RNG, a DMA engine (DMA4 aka SDMA), 128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit, weirdass irq routing, and an elaborate L3 firewall instance covering both external and internal access Apr 09 19:50:09 so that's a bit more than a "random change" Apr 09 19:50:34 (for random changes, see the ethernet switch subsystem.... ARGH) Apr 09 19:55:05 rcn-ee: also, it's not like they are documented for the am335x either ;) Apr 09 19:55:34 true! Apr 09 19:56:33 though they *are* in the Tiva "Snowflake" TM4C129x (props to Cameron Moree for finding that), at least the AES, Hash, and DES modules Apr 09 19:57:24 the docs are somewhat vague or incorrect here and there, but so far the gaps have been easy to fill in with some empirical science Apr 09 20:01:47 rcn-ee: the AES module on the am335x is _fast_ btw, clocked at L3F (200 MHz) which yields >90 MB/s throughput for all AES-128 modes (except CCM) Apr 09 20:04:13 so if it were well-managed by the drivers to avoid overhead, you could basically encrypt both eMMC and all ethernet traffic "for free" Apr 09 21:07:32 Hello everyone Apr 09 21:08:22 forgot no spaces in irc lol Apr 09 21:35:30 rcn-ee: btw, how was the sporadic ethernet failure (due to PHY reset timing issue) ultimately solved in software? Apr 09 21:35:41 (if you happen to know) Apr 09 21:37:47 zmatt, which of the recent sporadic ethernet failures? ;) this is the last one i worked on: http://bugs.elinux.org/issues/137 Apr 09 21:38:53 well apparently due to power/reset timing the phy can mis-sample its strapping options, causing it to end up in an unusable state. one issue was that it could end up at a different phy address, which was solved by simply scanning for it Apr 09 21:39:10 but if I understand correctly, it could also end up in a state where it just doesn't work, even if you can find it Apr 09 21:42:10 ah that one.. essentially, we ignore the pin value in the dts, and just 'find' the phy.. (hasn't hit mainline yet) Apr 09 21:42:36 https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.0/patches/beaglebone/phy/0003-cpsw-search-for-phy.patch Apr 09 21:42:54 yes, I mentioned that part, but also that apparently the phy address isn't the only thing that can get borked Apr 09 21:43:35 that must be even a smaller %, haven't had any bug me more about it. ;) Apr 09 21:43:41 hmm Apr 09 21:45:07 I did notice that the pins have internal pull-downs on the am335x but 10K pull-ups at the PHY... feels like a potentially dangerous dependency on the (possibly quite variable) values of the am335x internal pull resistors Apr 09 21:47:03 From what gerald was saying, it happens more often when you boot from the microsd card.. Apr 09 21:47:52 could be timing, or could be extra drain on 3v3b Apr 09 21:50:08 ehh... pulldown current at 3.3V is specified 110 uA nom, 210 uA max Apr 09 21:50:19 10K external pull-up resistor to 3.3V .. Apr 09 21:50:51 that's 1.1 - 2.1V Apr 09 21:52:02 and the strapping-option pins have smith-triggers Apr 09 21:52:58 up-going threshold (@ 3.3V supply) ... 1.65 nominal, 1.90 V max Apr 09 21:53:11 that sounds like a recipe for non-deterministic behaviour indeed Apr 09 21:54:17 s/smith/schmitt/ .. sorry, not that awake yet Apr 09 21:54:30 and if you power it via usb. ;) Apr 09 21:55:42 good to know, I think I want to try to replicate the problem to see what happens exactly Apr 09 21:57:02 afaict all strapping options can be overriden by software (once you've found the phy), though this does require writing the phy-specific "special modes register" Apr 09 21:57:18 also lets you reset the phy address, so if done in u-boot, the kernel no longer needs to search for the phy Apr 09 21:58:26 that would be a nice fix. ;) Apr 09 21:58:52 searching for the phy is of course particularly easy since the MDIO controller already does that on its own Apr 09 21:59:18 (whether you want it to or not -- it continuously scans all 32 phy addresses) Apr 09 21:59:56 the kernel phy search is more to make the device tree node happy ;) Apr 09 22:00:32 it also annoys me that the phy is getting repeatedly reset (thus also restarting auto-negotiation) Apr 09 22:01:02 just pointlessly slows down time till link up, and probably even risks confusing the link partner Apr 09 22:01:03 oh in 3.8.x it's terrible... in 3.14.x/mainline it's not 'as' bad.. Apr 09 22:01:25 still slow as crap, as it waits between resets.. Apr 09 22:01:45 I'm using your latest 4.0 dev Apr 09 22:01:52 (but with custom kernel config) Apr 09 22:02:25 if you also consider, u-boot is reseting/fireing up the phy too, it might as well make it easier for the kernel.. Apr 09 22:02:52 disabling crap I don't need (e.g. usb, everything related to video/graphics) did in fact speed up boot Apr 09 22:02:59 I know it does, and that's bogus too Apr 09 22:03:52 normally a phy begins auto-negotiation at power-up... resetting it just interrupts that pointlessly interrupts that process Apr 09 22:04:01 i was benching u-boot the other day for CircuitCo, u-boot 2015.01 is 2 seconds slower then 2014.04: https://gist.github.com/RobertCNelson/a6692778790581cbac6a Apr 09 22:04:04 eh, sentence fail Apr 09 22:04:33 yeah, taking a good look at u-boot is also high on my to-do list Apr 09 22:04:48 or possibly making a small custom bootloader Apr 09 22:05:28 no need, use the newer 'spl' falcon mode... essentially MLO -> Kernel Apr 09 22:05:38 u-boot is so big, bloated, and hard to follow that the second option might actually be less work than slimming down u-boot Apr 09 22:05:39 just got to compile in all your uEnv.txt ;) Apr 09 22:06:07 details? I mean, I'm mind-boggled that they couldn't fit u-boot in the 97 KB available for MLO Apr 09 22:06:20 you can fit a whole fucking multitasking OS in there Apr 09 22:06:34 http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.falcon;hb=HEAD Apr 09 22:06:45 check, will read, thanks Apr 09 22:06:47 the am335x was one of the cores used to setup/design ^ Apr 09 22:10:45 on dm814x I have a baremetal app that includes a somewhat fancy-ish Forth system (compiler/interpreter), a8 setup including mmu and cache, interrupt support code, verbose fault reporting (u-boot's "something went wrong, so now we'll just reboot" pisses me off), raw nand flash driver, audio setup code including loading the DSP application, ethernet switch setup Apr 09 22:10:54 the whole thing was iirc 53 KB, including the DSP application Apr 09 22:11:25 ddr3 init code was included, but I usually left it disabled since I had no use yet for that much memory Apr 09 22:12:18 (to be fair, the dm814x has quite a bit more on-chip SRAM than the am335x) Apr 09 22:15:17 oh, and most of that code was from my Forth's deeply stupid code generator... I never dared to look at the disassembly, I'd probably be too embarrassed. might actually be worse than -O0 Apr 09 23:08:57 Hey guys, I have a Rev C BBB and I am trying to find out if I can disable the 4 UART ports by default until my Ubuntu boots up. I am receiving garbage on them during boot and it is making some devices connected to it go haywire. Apr 09 23:09:06 Thanks in advance :) Apr 09 23:30:03 yeah for some reason the serial ports show up even if not declared in devicetree Apr 09 23:30:27 I solved it by adding the kernel parameter 8250.nr_uarts=1 Apr 09 23:30:41 but I don't think you can increase that at runtime Apr 09 23:31:06 oh I misread your question Apr 09 23:31:07 hm Apr 09 23:32:19 they shouldn't spew anything if setup properly, though it's possible systemd might decide to spawn a getty on them that sends a login prompt, not sure how/where that decision is made Apr 09 23:48:56 Doesn't that ussually happen if it receives a line terminator? I use to login to my linux box via serial and I remember it wouldn't send a prompt unless certain conditions were met. I think you have to set the handshaking response in one of the config files. It's been a while :) Apr 09 23:52:09 tbh it shouldn't start a getty on serial ports other than the console at all by default Apr 09 23:52:53 but I also don't really understand why /dev/ttyS1-S5 show up even if disabled or entirely absent in device tree Apr 09 23:56:09 Poltergoose! (sorry young ones twitch). I think those are the default terminal login 'devices' and I'm not sure either. I actually use to have a VT220 that I used for 'salvaging' my machine. Apr 09 23:56:57 but without device tree it shouldn't even know where to find them Apr 09 23:57:07 it means those addresses are still hardcoded somewhere in the kernel Apr 09 23:58:28 That is kind of what I'm thinking. What the connect to however is likely another matter. It may take some wading through the kernel code. I know that you had to specifically configure something to be logged into as root on a serial port however a regular user I don't believe had that restriction. Apr 09 23:59:17 /etc/securetty, but that's of course unrelated to all this Apr 09 23:59:51 inittab used to control the spawning of getty, but that was pre-systemd Apr 10 00:00:59 for now I've just used the 8250.nr_uarts=1 kernel parameter to make the bogus serial devices go away since I'm currently not using any (other than ttyS0), but I still intend to dig into this Apr 10 00:01:42 So that happens on an ARM machine as well? Apr 10 00:06:42 That is a bit strange then. I've always worried about no access on machines (heh). Apr 10 02:54:43 HI all, trying to design a BBB cape. Does the BBB have an equivalent of an external interript line? **** ENDING LOGGING AT Fri Apr 10 02:59:59 2015