**** BEGIN LOGGING AT Fri Mar 09 03:00:01 2018 Mar 09 03:11:30 All motors are a go...setting up service now Captain. Reboot! Mar 09 05:15:18 Did systemd change recently on our BBB distros? Mar 09 05:16:37 NetworkManager or systemd-networkd? Mar 09 05:21:12 I am asking b/c I used to be able to set up services and I am failing (as usual) now. Mar 09 05:26:37 Oh well...a night is a night. Later for now. Mar 09 06:50:48 hello Mar 09 06:51:15 rootfs not found to expand memory please help Mar 09 07:01:47 please provide more context Mar 09 07:01:53 what are you doing? Mar 09 07:11:03 i installed debian os and i tried to install open cv Mar 09 07:11:23 but in middle i found no space error Mar 09 07:11:50 and then i got to know about expanding the memory Mar 09 07:12:12 when i tried to expand usings commands Mar 09 07:12:40 i didnt see rootfs Mar 09 07:12:47 please help to move forward its urgent Mar 09 07:13:29 are you running from a SD card or from eMMC? Mar 09 07:18:15 running in sd card Mar 09 07:21:52 * somu123[m] uploaded an image: Capture.PNG (40KB) Mar 09 07:22:19 rootfs not found here please help its urgent Mar 09 07:34:35 please reply Mar 09 07:36:33 well, we're all volunteers here, we help each other, but in our free time Mar 09 07:37:15 also it says there are 1.5GB free on that rootfs Mar 09 07:37:21 so it's not full Mar 09 07:37:40 yes Mar 09 07:38:31 what is the size of the SD-card? Mar 09 07:38:47 16gb Mar 09 07:39:34 can you please use pastebin.mozilla.org to provide the output of "fdisk -l"? Mar 09 07:41:58 what is that link?? Mar 09 07:42:42 you copy the command output and paste it there Mar 09 07:44:46 after that what to do Mar 09 07:45:01 you paste the URL to that paste here Mar 09 07:45:18 https://pastebin.mozilla.org/9079466 Mar 09 07:45:25 it's just like with a screenshot, but much more friendly as you can actually access the text Mar 09 07:46:28 ok. what were you trying to do to resize the rootfs? Mar 09 07:47:18 i searched in internet and got one link and i tried that commands Mar 09 07:48:07 yeah, that was most likely outdated then Mar 09 07:48:28 look in /opt for a script called grow_partition.sh Mar 09 07:49:43 https://dev.iachieved.it/iachievedit/expanding-your-beaglebone-microsd-filesystem/ Mar 09 07:50:02 while trying these commands i didint find rootfs Mar 09 07:51:22 please run the script in opt, it's designed to do all this for you Mar 09 07:53:26 you can run this to locate the script: find /opt -iname 'grow_partition.sh' Mar 09 07:54:54 there is no script Mar 09 07:56:03 * somu123[m] uploaded an image: 2.PNG (43KB) Mar 09 07:59:43 i found script Mar 09 08:00:16 please do NOT use screenshots for text, use pastebin as explained earlier, thanks. Mar 09 08:00:35 also the command is "find /opt…" Mar 09 08:01:09 i found the script what should i do next Mar 09 08:01:16 run it Mar 09 08:01:28 next Mar 09 08:01:42 did you run the script? Mar 09 08:02:32 how to run .sh file Mar 09 08:02:50 you type its full path into the terminal Mar 09 08:03:03 did you EVER work with a command line before? Mar 09 08:03:26 yes Mar 09 08:03:34 I'd strongly suggest that you get yourself a book on Linux basics Mar 09 08:04:54 https://pastebin.mozilla.org/9079467 Mar 09 08:05:47 yes, do as it tells you. Reboot the device Mar 09 08:06:06 ok Mar 09 08:07:33 i rebooted next what to do Mar 09 08:07:53 take a wild guess Mar 09 08:08:30 rootfs not found Mar 09 08:09:10 https://pastebin.mozilla.org/9079469 Mar 09 08:10:39 so, everything is fine and dandy then. you're welcome. Mar 09 08:11:49 yes, gunny Mar 09 08:12:58 thank you so much Mar 09 09:02:34 Hi, does anyone know if its possible to improve the latency of the spidev driver? Im using the RT patch and getting 50 us delay between consecutive calls to ioctl. Is it possible to increase the priority of the spidev driver and its interrupts? Mar 09 09:29:21 have you tried a kernel without RT? Mar 09 09:36:26 yes, same issue Mar 09 09:36:31 but with more jitter Mar 09 09:37:37 as usual, RT does not mean fast. RT means reliable. Mar 09 09:39:04 yes. Looking at the source code of spidev it uses spi_async() and wait_for_completion(). For high priority handling it should simply use spi_sync_immediate() Mar 09 09:42:10 hey at least there is an actual improvement :D Mar 09 09:43:04 have never changes a module driver before, risky business? :O Mar 09 09:45:25 there's always a first time :) Mar 09 09:45:57 also it sounds like you have the right tools and enough understanding to have a good shot at it Mar 09 09:46:21 * tbr was less fortunate the first time around Mar 09 09:46:56 still fixed the driver race condition though. took a while and more than one brain to crack. Mar 09 10:33:16 join Mar 09 10:33:48 Whether Wilink 8 can be interfaced with Pocket beagle Mar 09 10:33:51 ??? Mar 09 10:57:38 zmatt: do you know what exactly happens when i reboot beaglebone black? will PMIC be aware of it or is it just the processor? Mar 09 11:00:51 pmic is not involved in reboot Mar 09 11:06:25 zmatt: sorry for bothering again but if i do a software shutdown, can i tell by monitoring RESET or PGOOD if the shutdown succeeded? or is there a known PMIC bug that keeps one of the signals regardless of the cpu power state? Mar 09 11:09:09 my intention is to monitor the system state of the beagle. power it on, -is it starting? -os up? -shutdown succeded? -reboot happening? Mar 09 11:51:46 hi Mar 09 12:13:59 microdevel: reboot (cpu reset) will revert all pin configuration to their defaults again, so that may be noticable Mar 09 12:14:25 it technically also briefly pulses the reset output low, but due to the big capacitance on reset this is completely invisible Mar 09 12:15:19 when shutting down, the very first thing that happens is that PGOOD goes low, which also means reset goes low Mar 09 12:16:54 then, bizarrely, the pmic unconditionally switches to battery power at the start of sequenced powerdown, regardless of the presence of a battery, so that effectively means the whole system is running on capacitors from that moment on Mar 09 12:18:28 this bizarre behavior happens during shutdown? what if Linux is delaying shutdown procedure for some reason? Mar 09 12:19:03 caps will discharge very fast so improper shutdown will be the consequence? Mar 09 12:19:26 linux is not relevant at this point anymore, this happens after linux has done its shutdown tasks and asks the pmic to power off the system Mar 09 12:19:48 Ahh Okay cause this would mean a major bug to me Mar 09 12:20:16 however, it does mean the sequenced poweroff is quite messy: https://photos.app.goo.gl/1jkt9ubbyBbK4csy2 Mar 09 12:21:21 here you see that at the start of the poweroff sequence, sys_5v is connected to BAT, causing it to shoot up to 5V (from that moment on BAT == SYS_5V) and start falling as the caps on SYS_5V discharge Mar 09 12:22:26 also visible is the 3V3B regulator bug: it remains on during the whole sequenced shutdown, instead of being disabled around the time 3V3A is disabled Mar 09 12:23:32 yeah I see Mar 09 12:23:56 also, if system power consumption is high during this time (for example if the HDMI framer is enabled, which has no reset input hence doesn't notice when poweroff is happening), SYS_5V may discharge fast enough that clean sequenced poweroff becomes impossible Mar 09 12:24:18 you can find some images of that at the bottom of https://elinux.org/BeagleBone_Power_Management Mar 09 12:24:58 yeah I have read your investigation on this yesterday Mar 09 12:25:51 but what's the effect of an incomplete sequenced power off Mar 09 12:26:11 it might not be harmful Mar 09 12:26:29 but in worst case? Mar 09 12:26:52 oO( the wurst case?!? ) Mar 09 12:27:20 Wurst case always happens when I design hardware Mar 09 12:28:10 extremely abrupt poweroff like in the last two images on that page violate the datasheet and might cause excessive current spikes and voltage differentials inside the AM335x Mar 09 12:28:36 possibly harming the SoC in the long run if this happens frequently Mar 09 12:29:26 note that the last two images are not from a clean shutdown at all but external power cut Mar 09 12:29:49 so a sudden power loss might cause less trouble than an incomplete sequenced shutdown? Mar 09 12:30:14 but due to the pmic's bizarre choice of cutting its own input power at the start of sequenced poweroff, a similar thing may happen if more stuff is connected to the beaglebone that draws power Mar 09 12:30:23 what? no? power cut is the worst case scenario Mar 09 12:31:37 ok so my choice will be not to power additional peripherals via beagle Mar 09 12:32:37 so you wouldn't recommend cutting power even if we have a readonly file system? Mar 09 12:32:39 actually that's not entirely true, the 3V3B regulator bug actually also makes it potentially harmful if sys_5v remains high during poweroff Mar 09 12:33:25 I would not assume that making the filesystem readonly suffices to protect the eMMC Mar 09 12:34:41 I would actually hope that the eMMC occasionally rewrites each sector even in the absence of any writes since the charge in each NAND cell decays over time. I don't actually know whether the cheap NAND flash used on the beaglebone is smart enough to do that Mar 09 12:35:24 you mean as an Emmc internal action Mar 09 12:35:50 yes Mar 09 12:36:10 hmm have to find out if this happens. I was hoping to be able to cut off Power at any time without causing trouble Mar 09 12:37:31 why is power cut the worst scenario to you? Mar 09 12:39:22 because the supply to the is cut while the system is still consuming full power, causing SYS_5V to plummet down really fast, and the 3V3 supplies have already lost regulation by the time the pmic notices Mar 09 12:40:31 so this might cause even more damage to am335x Mar 09 12:40:48 in the bottomleft image on the wiki page you see sys going from 5V to 2.8V in 1 ms Mar 09 12:41:05 even more than... ? Mar 09 12:42:28 incomplete sequenced power off Mar 09 12:45:32 not sure why you call it "incomplete", if anything it completes too fast ;) but like I said: the cleanness of the poweroff depends on how fast vsys drops, which depends on system power consumption. in case of a power cut, the system is consuming full power. in case of a requested shutdown, PGOOD is low which results in quite low power consumption Mar 09 12:46:08 power consumption by external hardware affects both cases as well Mar 09 12:46:57 got this. this is a big problem for my application, as power loss may occur at any time Mar 09 12:48:23 and even if you use a big cap or so, you still have to tell the system to immediately shut down Mar 09 12:49:02 and as I mentioned above, the 3V3B regulator bug is another potential issue if vsys actually drops very slowly, especially in the limit case where a battery is actually connected to the pmic (which causes vsys to remain at battery voltage when the system is powered off) Mar 09 12:49:44 yeah. note that these are both potential issues for long-term health, but I don't know how much of a problem it really is in practice Mar 09 12:50:20 won't be funny if it cracks up your am335x in 6 months Mar 09 12:50:25 a big cap on the input should actually help a lot, since it gives the pmic time to detect undervoltage on its input and begin poweroff Mar 09 12:50:55 correct. I hope it's not that bad, since our products also face unannounced power loss :) Mar 09 12:51:24 did you have any issues with that on your products? Mar 09 12:52:15 not so far, nor with filesystem corruption on our production beaglebones (which all have eMMC reconfigured into SLC mode with reliable writes enabled) Mar 09 12:52:45 yeah well definitely put them in slc mode Mar 09 12:53:44 ok but if pmic detects undervoltage, will it cause the cpu and OS to shut down properly? Mar 09 12:53:51 we did burn out the eMMC of a development beaglebone (with eMMC in default mode) as a result of a logging bug that caused 16 GB/hour of data to written to eMMC Mar 09 12:53:57 no Mar 09 12:54:24 it will cause relatively clean sequenced poweroff Mar 09 12:54:44 so it just truggers its own power down sequence? Mar 09 12:54:45 the system is still abruptly reset when PGOOD goes low at the start of it Mar 09 12:54:54 I see Mar 09 12:55:24 if you want a clean poweroff you'll need a battery or really big caps on the input power and a detection mechanism to notify the system Mar 09 12:55:46 but if you have a readonly filesystem, there's no reason to have linux do a clean shutdown Mar 09 12:56:18 well, unless it's managing external stuff that needs it I guess Mar 09 12:56:30 yeah then it's like a server and ups Mar 09 12:57:32 ok but putting a big cap on the supply might prevent me from breaking the board within months Mar 09 12:58:25 are you expecting power cuts that often? Mar 09 12:58:48 if you really want to know for sure, you should just make a test setup where the system is powered on and off once per minute or something Mar 09 12:58:53 on a motorbike, you never know what happens Mar 09 12:59:01 ah Mar 09 12:59:34 yes ok, that sounds like multiple times per day easily Mar 09 12:59:40 even the battery power gets cut off 30 seconds after you remove the key Mar 09 13:00:04 there's no 24h supply from battery unfortunately Mar 09 13:00:14 then you'll definitely want to invest some time in coping with power loss Mar 09 13:00:54 yeah but what I learned now, the slower the power drops, the better for the beagle Mar 09 13:00:59 we actually considered hooking up a li-ion battery to the pmic (since it has an integrated charger for it), but that requires patching the beaglebone to fix the 3V3B issue Mar 09 13:02:01 up to a certain point yes Mar 09 13:02:16 yeah and then you run into some other issues on a motorbike. 50 degrees sun heat won't be too good for the lipo on a long term perspective Mar 09 13:02:26 indeed Mar 09 13:03:16 I guess we start with that cape. Emmc corruption or problems with the os are tolerable, broken am335x is nightmare Mar 09 13:04:08 does undervoltage recognition work or is there also a hidden bug? Mar 09 13:04:49 the very bad thing is that all the information can't be found in an errata Mar 09 13:04:52 how is eMMC corruption tolerable? doesn't that yield a device that's just as dead from an end user perspective? Mar 09 13:05:10 what are you expecting in an errata? Mar 09 13:05:16 nothing discussed so far involves an erratum Mar 09 13:06:01 oh I was thinking so, all the unexpected behavior that differ from datasheet should be listed somehow? Mar 09 13:06:14 which unexpected behaviour? Mar 09 13:06:44 the pmic switching to battery power at the start of the powerdown sequence is its specified behaviour Mar 09 13:06:46 is the pmic behavior equal to the situation described on the datasheet? Mar 09 13:06:57 oh dear Mar 09 13:07:22 it is utterly bizarre, but it's specified Mar 09 13:07:32 so it's just a design issue Mar 09 13:07:39 note that it wouldn't help much in your case anyway Mar 09 13:07:50 since you're cutting input power Mar 09 13:08:24 the driver cuts input power unfortunately Mar 09 13:08:37 I would keep it on Mar 09 13:08:49 causing less headaches Mar 09 13:08:49 although, if it didn't happen, the 3V3B regulator issue of the beaglebone would almost certainly have been found and fixed Mar 09 13:09:30 Emmc corruption could easily be fixed in field Mar 09 13:10:07 I guess yeah, if you can boot from external media Mar 09 13:10:23 like ethernet 😁 Mar 09 13:12:00 ok, I think now I have a very good idea what I have to pay attention to Mar 09 13:18:17 zmatt thanks again for your very detailed info, wouldn't be much fun without you here Mar 09 14:27:18 +1 Mar 09 15:08:08 +1 Mar 09 15:12:01 +1 Mar 09 16:42:23 +0.5 Mar 09 17:11:50 Hi to all Mar 09 17:12:32 I have a problem with bbb, I don't have a ntpd servece, but my bbb cal 2.debian.pool.ntp.org Mar 09 17:12:47 hot to block this call? Mar 09 17:13:00 please help me Mar 09 17:13:57 I have this realease: Linux snmpv2c 4.1.12-ti-r29 #1 SMP PREEMPT Mon Nov 9 22:46:19 UTC 2015 armv7l GNU/Linux Mar 09 17:15:42 root@snmpv2c:/# service --status-all [ - ] alsa-utils [ + ] apache2 [ - ] avahi-daemon [ - ] bluetooth [ - ] bootlogs [ - ] bootmisc.sh [ - ] checkfs.sh [ - ] checkroot-bootclean.sh [ - ] checkroot.sh [ + ] cpufrequtils [ + ] cron [ + ] dbus [ + ] dnsmasq [ - ] hostname.sh [ - ] hwclock.sh [ - ] killprocs [ + ] kmod [ + ] lighttpd [ + ] loadcpufreq [ - ] motd [ - ] mountall-bootclean.sh [ - ] m Mar 09 17:15:55 this are my service, no NTP Mar 09 17:16:05 do not have NTPD Mar 09 17:16:52 who call 2.debian.pool.ntp.org? Mar 09 17:17:42 some idea? Mar 09 17:20:58 ? Mar 09 17:21:46 Linux version 4.1.12-ti-r29 (root@a5-imx6q-wandboard-2gb) (gcc version 4.9.2 (Debian 4.9.2-10) ) Mar 09 17:22:11 it might be ntpdate or systemd or anything else Mar 09 17:23:35 Hi tbr, I do not have ntpdate, installed Mar 09 17:24:01 maybe sysemd? Mar 09 17:24:15 sorry, systemd Mar 09 17:24:44 how to block? Mar 09 17:24:49 please Mar 09 17:25:33 https://wiki.archlinux.org/index.php/systemd-timesyncd Mar 09 17:27:21 thanks a lot Mar 09 17:28:25 first: timesyncd.conf -> /dev/null Mar 09 17:28:48 timedatectl set-ntp false Mar 09 17:28:55 very thanks Mar 09 17:29:25 tbr: bye Mar 09 17:30:01 fra125: uhh no need to mess with timesyncd.conf, just disable the service (systemctl disable systemd-timesyncd) Mar 09 17:55:17 lol, this morning I said we've not yet seen problems with any eMMC that has been reconfigured into SLC mode... and now I discover we have our first case thereof :/ Mar 09 18:07:04 any ideas why sometimes my bbb boots and can't use the SPI device? Mar 09 18:07:14 I'd say it was 1 in 10 Mar 09 18:07:19 reboot and it works again Mar 09 18:13:34 is there any chance it changes from /dev/spi0.0 to /dev/spi0.1 ? Mar 09 18:17:23 not really no Mar 09 18:17:34 certainly not the number after the dot, since that's the chip select Mar 09 18:17:59 probably I meand /dev/spi1 /dev/spi0 then Mar 09 18:18:09 yeah, it's weird. Mar 09 18:18:32 I've seen it quite a few times and it bugs me Mar 09 18:18:53 actually the device names are normally e.g. /dev/spidev0.0 Mar 09 18:19:20 yeah, sorry I've halted the bbb and just cleaning up before the weekend - going from memory. Mar 09 18:20:44 depending on whether your kernel has my spi device numbering patch or not, the first number either correctly reflects the spi peripheral number (0 for spi0 or 1 for spi1), or the spi devices the kernel encounters are numbered from 1 upwards in whatever order the kernel encounters them Mar 09 18:21:10 if you're using spi0 then it's easy to tell the difference Mar 09 18:21:25 still, I see no reason why it would be probabilistic Mar 09 18:22:38 I actually give names to spi devices in our device trees and have an udev rule create symlinks, so our software can just open e.g. /dev/spi/dsp or /dev/spi/flash without having to know or care about which chip select on which spi bus that might be :) Mar 09 18:22:55 and you've never seen this? Mar 09 18:23:13 I've never seen this, but I wouldn't notice if it did thanks to the above Mar 09 18:23:34 also I'm 100% sure the kernel I use *does* have my spi device numbering patch, so the numbering can't change anyhow Mar 09 18:24:01 but even if it did I wouldn't notice because I never access the devices by number Mar 09 18:24:08 I don't get how a udev rule could help Mar 09 18:25:21 because it gives the device a name based on a property set in the device tree Mar 09 18:25:50 right Mar 09 18:26:13 so if for whatever reason the kernel numbers them differently in /dev, the symlinks would still work Mar 09 18:26:26 yeah Mar 09 18:26:29 next time it happens I'll try the other device and see what haapens Mar 09 18:26:38 cheers dude. Mar 09 18:26:43 here's for example how I configure two spi devices in our DT: https://pastebin.com/raw/XAz1ukN7 Mar 09 18:27:26 and with my udev rule that results in: https://pastebin.com/raw/XBmzyCgk Mar 09 18:28:39 I'm just using the default spi setup Mar 09 18:28:44 I understand Mar 09 18:29:26 could I still use your udev idea but adapted to the default dt? Mar 09 18:31:54 you can use udev to assign symlinks, e.g. KERNEL=="spidev0.0", SYMLINK+="spi/thingy" Mar 09 18:32:21 but if for some reason the kernel reorders the spi device the link will be wrong Mar 09 18:32:37 that would help with making your software not care about such details (useful when it needs to be reusable on different hw variants which might want to connect the device to another chip select or to spi1) Mar 09 18:33:29 correct, but the kernel reordering them can only happen if it doesn't have my spi device numbering patch... in which case the question is why doesn't it? I thought rcn had applied it Mar 09 18:34:10 if you can verify that the device numbering is not stable, then that would be a very good argument to make rcn apply my patch to all kernels :) Mar 09 18:34:12 when was this? Mar 09 18:34:19 long ago Mar 09 18:34:33 ok. Mar 09 18:34:37 which kernel are you using? Mar 09 18:34:52 Mar 09 18:35:14 hmm, maybe rcn didn't apply my patch Mar 09 18:35:29 ok he definitely did in 4.9-bone Mar 09 18:35:34 https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.9/patches/drivers/ti/spi Mar 09 18:36:18 but the patch is missing in 4.14-bone ... hum Mar 09 18:36:41 Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l GNU/Linux Mar 09 18:37:17 patch is present in 4.9-ti Mar 09 18:37:40 patch is not present in 4.4-ti Mar 09 18:37:50 ok, so that's probaly it. Mar 09 18:38:00 yeah Mar 09 18:38:06 you could work around it in 4.4-ti with an udev rule Mar 09 18:38:18 maybe Mar 09 18:38:29 is that kernel recent enough to have of_node symlinks in /sys? Mar 09 18:38:55 e.g. /sys/bus/spi/devices/spi0.0/of_node Mar 09 18:39:08 actually that might not even be needed Mar 09 18:40:57 yes I've got stuff in /sys/bus/spi/devices/spi1.* Mar 09 18:41:30 Hi, anyone has had problem with the BBB having a self-assigned ip? Mar 09 18:42:39 For some reason my beaglebone black started having a self-assigned ip when it was working perfectly before. Now I can't access it through a terminal Mar 09 18:42:39 mattvenn_: udevadm info /dev/spidev1.0 presumably has a DEVPATH that would match */48030000.spi/* Mar 09 18:44:01 DEVPATH=/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.0/spidev/spidev1.0 Mar 09 18:44:19 oh you're actually using spi1 rather than spi0 ? Mar 09 18:44:44 wait, but it's not called spidev2.* then? Mar 09 18:45:19 no, the device is /dev/spidev1.0 Mar 09 18:45:31 do you even have any /dev/spidev2.* ? Mar 09 18:46:36 Hello... Mar 09 18:46:54 I got the .service file setup and the Motor Bridge Cape works on boot. Mar 09 18:47:00 nope Mar 09 18:47:02 I see mowing in my future. Mar 09 18:47:22 mattvenn_: well then it's not possible for the kernel to swap their numbering Mar 09 18:47:34 only the part before the . is variable Mar 09 18:47:41 after the . is always the chip select number Mar 09 18:48:35 dang Mar 09 18:48:48 OK, well I'll wait for it to happen again and then try and debug it Mar 09 18:48:58 normally I just reboot beacuse I'm working on something else Mar 09 18:49:19 it would still be advisable to not rely on the spi numbering if you're using a kernel where this isn't stable Mar 09 18:49:38 e.g. if you'd also enable spi0, then it would become spidev1 and your device on spi1 would become spidev2 Mar 09 18:49:38 ok Mar 09 18:49:54 ah, my patch is gone in 4.14 because it has been fixed upstream in mainline linux Mar 09 18:49:59 I think the lcd cape uses pins on the other spi channel Mar 09 18:51:39 at least you have the luck that both numbering schemes call it spidev1.* in your situation, so it won't break if you upgrade the kernel (4.4 is getting really old) Mar 09 18:54:05 ok thanks. maybe I'll upgrade the kernel and then if it happens again try and debug it here Mar 09 18:54:11 have a nice weekend! Mar 09 19:19:31 damn this eMMC is really dead... you can still read it just fine, but any attempt to write to it causes the eMMC to stop responding to any commands at all until it's power-cycled Mar 09 19:34:55 zmatt is d' house! Mar 09 19:35:03 Hello sir...guess what? Mar 09 19:35:09 ... Mar 09 19:35:21 I finally got all my issues resolved w/ that darn Motor Bridge Cape. Mar 09 19:35:39 Hey man...I just wanted to say thank you. So, thank you again for supporting things around here. Mar 09 19:38:00 My new year's resolution was to be less verbose Mar 09 19:41:37 Credit! Mar 09 19:50:52 zmatt: there was a talk on 34C3 about restoring eMMCs Mar 09 19:51:07 zmatt: take a look at it, it had something about samsung in the name too Mar 09 19:56:10 Marex: uhh, almost certainly this eMMC is dead because the total lifetime erase/program of the NAND flash has been exceeded Mar 09 19:56:17 *erase/program cycles Mar 09 19:58:09 Marex: that was something else Mar 09 19:58:10 the 34C3 talk still sounds interesting, but it's about fixing a firmware bug in some very old Samsung eMMCs Mar 09 19:58:34 Marex: it was about hacking the emmcs controller firmware through a vendor "backdoor" Mar 09 20:00:22 I think it was the Galaxy S3 mobile phone, so not that old I guess? Mar 09 20:00:34 2010~ era? Mar 09 20:00:47 well, for smartphones that's very old ;P Mar 09 20:00:50 +1 Mar 09 20:00:58 several generations Mar 09 20:01:19 thanks for the pointer though, I'm definitely going to watch this talk Mar 09 20:01:39 highly recommended. one of the more interesting talks this year Mar 09 20:03:43 that particular bug in the samsung emmc however... basically the firmware in the emmc was programmed to hang up the controller when a certain metadata corruption happened Mar 09 20:04:00 Is that a good thing? Mar 09 20:04:09 so in theory, your emmc could suffer from the same thing ;) Mar 09 20:04:53 yes, it changed the S3 bug from "boot loop" to "bricked phone" :-D Mar 09 20:05:03 it does look like the firmware controller either crashes or deadloops. I think if it were due to metadata corruption, it would also crash if you'd try to read eMMC Mar 09 20:07:07 so I'm more thinking something along the lines of assert( !( all spare blocks are marked "bad" ) ); /* FIXME: return a proper error response */ Mar 09 20:07:48 in the s3 case I think the error triggered a hardfault and the hardfault handler was just a "1: b 1b " :-) Mar 09 20:08:02 and yes, the emmc controller was a cortex-m0 or something Mar 09 20:08:13 m3 Mar 09 20:21:21 duncan^: and yes it was a good thing, since apparently it prevented disastrous metadata corruption Mar 09 20:21:34 turning "phone is bricked" into "phone sometimes randomly freezes" Mar 09 20:21:45 which is not great, but an improvement Mar 09 20:23:19 well it sort of froze many times a day for some people ... Mar 09 20:23:55 yeah it depends on how often the condition gets triggered Mar 09 20:25:32 lol, he was able to dump the fw because samsung accidently leaked the procedure for it Mar 09 21:57:15 Hi everyone, does someone has any experience running a real time operating system on the beaglebone black and/or beagleboard x15? Mar 09 21:58:42 I've played a little bit with an -rt linux kernel, does that count? ;) Mar 09 21:59:02 well.... i guess not that much :D Mar 09 21:59:32 and I've done some baremetal programming for the beaglebone Mar 09 22:00:30 Ok, that counts a little bit more Mar 09 22:00:35 ;) Mar 09 22:01:00 But no one tried to get free rtos running on a beagle? Mar 09 22:02:26 Ok... different question: Can the beagleboard x15 create 1080i output over hdmi or just 1080p? Mar 09 22:02:28 it seems more likely that there *are* people who have tried. it may just be that they don't come here, or are not here right now, or are here but asleep, busy, or otherwise not paying attention to irc Mar 09 22:03:16 ok, got that :) Mar 09 22:03:25 it supports 1080i Mar 09 22:03:27 tahnks, zmatt :) Mar 09 22:03:48 see section 11.3.1.2 of the trm Mar 09 22:03:57 will do Mar 09 22:05:21 kinda weird and annoying that the hdmi framer integrated in DSS is pretty much undocumented in the public trm Mar 09 22:07:11 huh, I just checked the NDA version of the omap5 trm (since am572x is omap5-derived) and it's actually the same there Mar 09 22:09:04 sorry to ask, but I can just find the SRM but not the TRM for X15. Can you help? Mar 09 22:10:14 I meant the am572x trm, http://www.ti.com/lit/pdf/spruhz6 Mar 09 22:11:36 Great, Thanks! Mar 09 22:11:40 other docs relevant for low-level programming include the errata and maybe some of the application notes, http://www.ti.com/product/am5728/technicaldocuments Mar 09 22:11:45 what about the beaglebone black? Mar 09 22:11:52 can it also do 1080i? Mar 09 22:12:45 I don't know if the hdmi framer supports it... but even if it does I don't see how you'd be able to keep field synchronization Mar 09 22:13:01 the beaglebone's display controller (lcdc) is really really basic and limited Mar 09 22:14:25 we are working on a project for livestream production and need to provide a signal for chroma keying. We want to do this with the BBB or the X15 depending on the exact requirements/budget. Mar 09 22:14:47 most of the productions are in 1080i Mar 09 22:15:00 at least most that we have to deal with... Mar 09 22:15:35 we already build a beta version on a raspberry pi but would like to switch to BBB and X15 Mar 09 22:15:58 raspberry pi can do 1080i Mar 09 22:16:01 the x15 has a lot of video capabilities, the beaglebone very little Mar 09 22:16:08 ok, got it Mar 09 22:16:25 the rpi has a fairly video-oriented SoC, from a family designed for e.g. set-top boxes Mar 09 22:16:41 the bbb has a SoC designed mainly for automotive and industrial control applications Mar 09 22:16:47 ok, i understand Mar 09 22:17:02 bjoern: based on the bitclock, BeagleBone Black can only do 24fps at 1080p resolution Mar 09 22:18:10 ok, got it. I guess we will use the X15 if we have to provide a signal for chroma keying Mar 09 22:18:30 we also thought about using the BBB to create the data and a raspberry pi to create the hdmi output Mar 09 22:18:59 that sounds like an odd arrangement, why not create the data on the rpi in that case? Mar 09 22:19:01 but if we can use the X15 for 1080i output, there is no benefit in the solution with two SoCs Mar 09 22:19:19 I didnt know if the X15 could create 1080i Mar 09 22:19:32 but zmatt told me, that it can Mar 09 22:19:33 note that I don't know if linux supports it Mar 09 22:19:45 I just checked that the hardware can do it Mar 09 22:20:19 mmh... ok. we can do 1080i with raspbian. so i guess it should be possible.... Mar 09 22:21:00 that doesn't mean the omapdrm driver supports it necessarily Mar 09 22:21:32 ok Mar 09 22:21:56 tomba: does the omap5 hdmi code support interlaced output? Mar 09 22:22:10 (no idea if he happens to see this, but worth a shot) Mar 09 22:23:16 ah it looks like it does! Mar 09 22:24:09 at least I see two tests for the DISPLAY_FLAGS_INTERLACED flag Mar 09 22:25:29 or maybe not Mar 09 22:25:49 do you think we can use this card with the X15? Mar 09 22:25:49 https://www.blackmagicdesign.com/products/decklink/techspecs/W-DLK-31 Mar 09 22:27:17 you realize that although the x15 has pcie lanes on one of its expansion connectors, it doesn't have an actual pcie slot? Mar 09 22:28:14 yes, I was looking for an adaptor or is that not possible at all? Mar 09 22:29:10 I'm not sure the power supply specs of pcie can be met, but other than that it should be possible to make such a thing... I don't know if anyone has Mar 09 22:29:48 I should also note that the expansion connectors include multiple digital video input and output interfaces already... I don't know what your needs are exactly Mar 09 22:30:03 at some point we might have to provide "key and fill" instead of a chroma keying signal. Mar 09 22:30:27 I don't know what you mean by that exactly Mar 09 22:30:55 mmh... chroma keying is this technique where you have a background in a certain color that gets replaced by something else Mar 09 22:30:58 like on the news Mar 09 22:31:13 but if you mean capture two or more video signals, process/combine in some way, and output it again then the x15 is definitely capable... it's just a matter of finding or making a suitable interface board (along with software) Mar 09 22:31:15 you cant were green (or whatever color they choose) because it will be tranparent Mar 09 22:31:39 yes... key and fill are 2 signals Mar 09 22:32:51 ok... so we have to find/build an adaptor that fits and also provides enough power Mar 09 22:33:25