**** BEGIN LOGGING AT Fri Oct 16 02:59:58 2015 Oct 16 06:38:19 hi Oct 16 06:39:01 http://www.catb.org/esr/faqs/smart-questions.html Oct 16 06:45:14 i have a problem with beagle bone black , i am running Angstrom linux in BBB , when i connect Ethernet cable to BBB and reboot ,BBB is going to sleep mode directly . Oct 16 06:45:46 what setting should i do to disable sleep mode? Oct 16 06:54:05 hi I have flashed linux in bbb but i am unable to open it. How can I open the linux Oct 16 07:20:28 .o0(use a can opener) Oct 16 08:05:39 hi I have installed linux on bbb but unable to run it. Oct 16 08:05:58 I have connected 5v adapter and lcd via hdmi. please help me out Oct 16 08:11:35 is anybody here? Oct 16 08:12:58 yes Oct 16 08:13:06 what lcd? Oct 16 08:13:17 how did you "install" it Oct 16 08:14:43 i have downloaded this file "BBB-eMMC-flasher-debian-7.8-console-armhf-2015-07-28-2gb" in micro sd card then flash it into bone black as mentioned in instructions Oct 16 08:14:54 ok Oct 16 08:15:01 now the problem is I want to run linux but cant run it Oct 16 08:15:08 it might already run Oct 16 08:15:11 just that you dont see it Oct 16 08:15:16 what lcd? Oct 16 08:15:27 yes exactly thats the problem. I mean monitor Oct 16 08:16:04 I plugged in the keyboard with bbb and it was working fine but I cant see anything Oct 16 08:17:43 I want to see GUI on lcd/monitor. How can i see it? Oct 16 08:18:35 I have connected bone with my laptop but cant see anything on my computer. as I can see it before Oct 16 08:18:56 but I checked from devices and printers and it shows me beagle bone there Oct 16 08:19:04 please help me out I have to cp Oct 16 08:19:21 *to complete my project on bbb this weekend Oct 16 08:21:27 adil: a) your deadlines are not our deadlines b) are you sure flashing completed successfully? Oct 16 08:21:45 yes all 4 leds were steady on Oct 16 08:21:55 as mentioned in instructions Oct 16 08:22:13 I am sure that linux is working but why I cant see it Oct 16 08:23:26 right, of course you can't, you flashed a console image. it probably doesn't show anything on HDMI Oct 16 08:23:56 so how can i see it? Oct 16 08:24:34 UART debug port and SSH. I'd expect Oct 16 08:25:03 if you want hdmi output, use a different flasher image Oct 16 08:25:30 do you have any idea which one I need to use? Oct 16 08:27:14 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBB_.28All_Revs.29_eMMC_Flashers - pick your poison Oct 16 09:18:35 tbr: actually I think the console image should still display a console on hdmi? Oct 16 09:19:45 zmatt: possibly, but I never tried it. Oct 16 09:19:58 also it sounded like he's after some graphical output Oct 16 09:20:57 you can cat /dev/urandom to the framebuffer, you'll get very graphical output Oct 16 09:22:24 :D Oct 16 09:22:37 I remember doing that a couple of times on archos gen6/7 Oct 16 09:25:22 a true classic, yes. Oct 16 10:14:56 what's the best programming langauge to interact with the I/O ( after C, C++ and C# )? Oct 16 10:24:05 as Oct 16 10:27:41 bash script. bang it like it's 1999! Oct 16 10:29:58 as as in assembler Oct 16 10:31:59 HELP Oct 16 10:32:19 i want some help to install Android on Beaglebon Black Oct 16 10:32:42 i am just new in this topic so i dont know anything about is so plz help me Oct 16 10:32:52 thanks in advance Oct 16 10:39:29 rrrrrriiiight Oct 16 10:39:43 Defiant: that would be more like 1988 ;) Oct 16 14:45:59 Hello Oct 16 14:47:17 Anyone use network manager on their bone? I can't get it to autoconnect the usb gadget. Oct 16 14:48:28 How to make the Debian on the BBB read only? I have found http://armsdr.blogspot.co.at/2014/11/beaglebone-debian-read-only-filesystem.html but the first command runs in "no such file" ... it's my first try to make a Linux Filesystem Read Only Oct 16 14:55:01 Cupro, check your options in /etc/fstab, use man fstab and man mount for more info Oct 16 14:55:25 Cupro: well, that blog post isn't meant as #exactsteps, you'll have to find your way by matching it to your reality Oct 16 14:55:54 :) so not easy for a beginner, I understand Oct 16 14:56:36 not copy/paste, no Oct 16 14:56:49 okay, than I will try to understand this manuals ;) Oct 16 15:06:49 okay ... I try another way, because my only problem seems to be, that I don't know what > sudo sed s:ext4\ \ noatime:ext4\ \ ro,noatime: /etc/fstab_ro is changing on UUID=3f0294ef-31ef-4687-927e-31b876b31f39 / ext4 noatime,errors=remount-ro 0 1 Oct 16 15:07:11 and please don't post how to find the manual of sed :/ Oct 16 15:14:01 Cupro, it is changing the options field from noatime to ro,noatime. So it is adding the read only flag. I wouldn't use that command though, as it will change any ext4 entries. I would manually add ro to the options list using vi/vim. Oct 16 15:14:57 Your new fstab entry should look something like this: UUID=3f0294ef-31ef-4687-927e-31b876b31f39 / ext4 ro,noatime 0 1 Oct 16 15:15:37 Cupro, how sure are you that you want a read only root filesystem? Oct 16 15:17:53 I will use vim :) Oct 16 15:18:43 very ... the BBB is for Use in a car with Python Programms > GPIO > Servos ... Boot on Ignition and Power Off with Carkey Oct 16 15:20:55 Cupro: cool, what are you using it for? Oct 16 15:30:06 and as I think I must also check where the BBB controls the GPIOs, so that the script can write to it Oct 16 15:30:37 stand up and lay down of a CB Antenna to drive in the Garage Oct 16 15:42:18 Thanks abferm :) it was a try, but It didn't work *g* Oct 16 15:46:01 What is your new fstab line? Oct 16 15:46:24 UUID=3f0294ef-31ef-4687-927e-31b876b31f39 / ext4 ro,nooatime,errors=remount-ro 0 1 debugfs /sys/kernel/debug debugfs defaults 0 0 tmpfs /tmp tmpfs nodev,nosuid,size=32M 0 0 tmpfs /srv tmpfs nodev,size=512K 0 0 tmpfs /var/log tmpfs defaults,noatime,size=1M 0 0 tmpfs /var/tmp tmpfs defaults,noatime,size=512K 0 0 tmpfs /var/run tmpfs defaults,noatime,size=512K 0 0 tmpfs /sys/class/gpio tmpfs defaults,noatime,size=512K 0 0 Oct 16 15:47:03 I hope that is more than one line, and I do see a typo... Oct 16 15:47:30 its a copy from the notes Oct 16 15:47:49 the format should be okay Oct 16 15:48:12 can you paste your entire file on pastebin and share a link? Check noatime in your first line... Oct 16 15:49:12 I am not able to connect to the BBB anymore :) It reacts on the Shutdown Button and Power Offs, but it gets no IP from the DHCP ... like the part where he wants to write that down is ... read only :) Oct 16 15:49:39 hmm, do you have an ftdi cable? Oct 16 15:51:31 Cupro, if you are just trying to control a couple motors you may be better off with a micro-controller, not a full linux machine. Oct 16 15:53:49 no I have ... yes before BBB I have used AVR ... a friend showed me that BBB is so much easier ... the same friend can now help me 😀 Oct 16 15:53:59 but thanks for trying Oct 16 16:11:37 he writes me a manual next week *g* so thanks and bye Oct 16 20:07:38 curious, I just noticed I can't poweroff a BBB if it's powered via the barrel jack *and* USB power is available Oct 16 20:07:50 it powers back on again after 1 second Oct 16 20:08:15 zmatt.. I thought you of all people would know that's not news ... Oct 16 20:08:27 veremit: funny enough, it is Oct 16 20:08:59 you cannot power it off _at all_ ? Oct 16 20:09:14 it powers off, but immediately back on again Oct 16 20:09:15 that is pretty dumb lol Oct 16 20:09:35 is usb trying to act as a 'power on' event I guess? Oct 16 20:09:43 zmatt, just put it in suspend with wakeup disabled ;) Oct 16 20:10:05 rcn-ee.. doubt that will work either .. if its the same trigger I suspect... Oct 16 20:10:16 veremit: it would work since "suspend" doesn't involve the pmic at all] Oct 16 20:10:23 ah Oct 16 20:10:25 all power supplies remain on Oct 16 20:10:36 oh .. well that ain't 'off' exactly then .. Oct 16 20:10:50 and rcn-ee.. how do you get it back "on" again?! :P Oct 16 20:10:52 it's more like dead... powersycle to reboot it.. Oct 16 20:11:00 so like "off" .;) Oct 16 20:11:06 just takes power... Oct 16 20:11:09 but still drawing power. Oct 16 20:11:11 Fail. Oct 16 20:11:15 and Oct 16 20:11:24 unlike "off", you can't power it up using the power button Oct 16 20:11:30 right... Oct 16 20:11:34 since the pmic events can't be received by the wakeup-m3... nicely done! Oct 16 20:11:39 how can you 'disable' that behaviour .. Oct 16 20:12:22 the power button won't work since: 1. the system is already on as far as the pmic is concerned, so it just generates an event Oct 16 20:12:32 2. the pmic's irq line is connected to the "NMI" input of the cpu Oct 16 20:13:00 3. the "NMI" input is a perfectly normal maskable interrupt, but can only be received by the cortex-a8, not by the cortex-m3 responsible for power management Oct 16 20:13:04 4. the cortex-a8 is off Oct 16 20:13:35 lol Oct 16 20:14:14 if the pmic irq line had been connected to any pin of gpio bank 0 then there wouldn't have been any problem Oct 16 20:15:32 as for the bug I just noticed, it's news to me since normally we don't have BBBs connected via usb except as power source Oct 16 20:16:09 no doubt a spurious (dis)connect event is logged in the pmic, causing it to power back on Oct 16 20:16:53 (yes, the pmic considers _disconnect_ of a power source to be an event worthy of powering up the system to notify it, assuming there's still any power to do so) Oct 16 20:17:04 (yes, the pmic is a moron) Oct 16 20:17:23 no .. there might be a use case where an external 'blob' of logic wants notification .. not the central cpu though .. Oct 16 20:17:48 this pmic is designed specifically for the am335x though afaik Oct 16 20:18:02 well yes .. but not solely for the am335x Oct 16 20:18:07 and "battery powered applications". ;) Oct 16 20:18:18 rcn-ee.. thats the scary bit lol Oct 16 20:18:23 rcn-ee: it definitely is... the pmic becomes much less buggy if you supply power via BAT Oct 16 20:18:42 i think the spec for the designers: [1] there will be a battery presetn... Oct 16 20:18:52 and then we came along. ;) Oct 16 20:18:57 I suspect the battery use case is much better defined Oct 16 20:19:11 non-battery operation seems to have been an afterthought yes Oct 16 20:19:36 and (1) we want it on if usb gets connected (2) anything else doesn't matter (3) it will always be On. (4) except if the battery dies. Oct 16 20:20:00 (note that you can safely supply the BBB with 5V on the battery terminals) Oct 16 20:20:14 wait Oct 16 20:20:18 zmatt.. I see no "battery" terminals on my beagle .. :p Oct 16 20:20:28 I keep forgetting that's only if you fix the 3v3b regulator bug first Oct 16 20:20:29 sorry Oct 16 20:20:51 (all BBBs on my desk have that patch) Oct 16 20:21:50 veremit: soldering a header onto TP5-TP8 is really easy, even I can do that Oct 16 20:22:51 zmatt.. well provided you have a beagle with P5-8 Oct 16 20:23:08 ah I must order another now my RS account is fixed... Oct 16 20:23:15 ??? I've never seen or heard of a BBB without them Oct 16 20:23:27 veremit, it's the 4 block next to the 5volt.. Oct 16 20:23:54 the 3v3b regulator bug is a bigger problem though Oct 16 20:24:08 and you can't use the battery terminals unless you fix that one first Oct 16 20:27:12 rcn-ee .. yeah I got it. Just my bbb is buried amongst wires Oct 16 20:27:24 zmatt.. ye,s where's your step-by-step guide ?! Oct 16 20:28:50 http://elinux.org/BeagleBone_Power_Management has a bit of background info\ Oct 16 20:29:13 this shows my fix for the 3v3b regulator bug -> https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/_oNSCta5WusJ Oct 16 20:31:45 without the patch, if you power via BAT then after shutdown it'll continue to draw about 35 mA assuming no external connections are present Oct 16 20:32:04 not that -wire- ?! Oct 16 20:32:51 if in this state you drive any processor I/O to 3v3b (which is the 3.3V on the P9 header) you may damage or destroy the cpu. This also happens if you have a serial console cable attached Oct 16 20:32:55 yes that wire :) Oct 16 20:33:10 ripped off the 3v3b regulator, tied 3v3b to 3v3a, problem solved Oct 16 20:34:01 zmatt: which may have been the sole purpose of u4 .. Oct 16 20:34:19 protecting the debug cable being attached Oct 16 20:34:40 did Gerald give any commentary to your findings? Oct 16 20:35:01 U15 you mean? Oct 16 20:35:03 nope Oct 16 20:35:11 and yes it was meant to protect the cpu Oct 16 20:35:18 which is why it should have been powered from 3v3a, not 3v3b Oct 16 20:36:42 hrm Oct 16 20:36:48 instead, it's an active menace to the UART0_RXD pin Oct 16 20:37:05 there must have been a reason for its inclusion originally .. but What Was IT ?! Oct 16 20:37:06 and multiple people have reported that pin becoming flaky on older BBBs Oct 16 20:37:13 powerdown isolation Oct 16 20:37:24 to prevent a console cable from driving into an unpowered cpu Oct 16 20:37:53 (it also happens to act as a level-shifter as side effect, so a 5V cable is safe) Oct 16 20:40:06 so... forgive me here .. what's the Right Solution to that issue? Oct 16 20:40:25 zmatt's ^ ;) Oct 16 20:40:31 see my link Oct 16 20:40:40 and follow-up posts Oct 16 20:40:53 eh google groups meh. Oct 16 20:41:09 for more details on what exactly the 3v3b regulator bug *is*, scroll to my first post in that thread Oct 16 20:41:33 mailing list would be easier than that mess. Oct 16 20:42:28 but tying 3v3b to 3v3a is the simplest solution, unless you need more power than the PMIC can deliver Oct 16 20:42:34 (on that supply) Oct 16 20:43:03 in which case you'd be using an external supply and buffers anyway? Oct 16 20:45:03 and if 3v3b is tied to 3v3a, then you can actually tell it's safe to drive processor I/Os whenever 3.3V is available on P9 Oct 16 20:45:19 (except for sysboot, need to wait till reset deassertion if you want to drive those) Oct 16 20:47:15 so debug connection is safe without U4, we're saying? Oct 16 20:48:52 ehh Oct 16 20:49:26 replacing U4 (the 3v3b regulator) by a wire makes 3v3b == 3v3a Oct 16 20:49:40 and the console isolation (U15) does its job properly if powered by the 3v3a Oct 16 20:50:05 also, tying 3v3b to 3v3a prevents the 3v3b regulator bug Oct 16 20:50:51 note that the U15 isn't the only danger to the am335x, but it's the only danger that's integrated on the BBB Oct 16 20:51:06 external CAPEs that drive the am335x have the same prob Oct 16 20:51:44 well, at present I'm not designing up a cape yet .. Oct 16 20:52:22 and surely there's no issue if you inject pwoer on the right 5v pins? Oct 16 20:52:37 there is, just of lesser magnitude Oct 16 20:53:27 there the issue is mitigated by another instance of idiotic behaviour of the PMIC: it cuts power to SYS_5V at the *start* of the powerdown sequence Oct 16 20:53:56 (strictly speaking it doesn't "cut" it, it unconditionally switches to battery power, regardless of whether one is present) Oct 16 20:54:57 this means that the 3v3b regulator is itself already running out of supply power before it can do damage, apparently Oct 16 20:57:05 however it also means the LDOs typically lose regulation before their sequenced powerdown, causing the pmic to briefly enter FAULT state on poweroff Oct 16 20:57:08 you usually don't notice this Oct 16 21:00:04 just checked btw, what reason the pmic reports for the powerup after powering off with both DC and USB power present: it reports an USB power (dis)connect event Oct 16 21:00:36 there's no difference between dis/connect ? Oct 16 21:00:54 no, there's just a status-change bit Oct 16 21:00:55 and how can it report an event when there's no 'event' .. Oct 16 21:01:09 -shrug- Oct 16 21:01:24 and you can see the current status of course Oct 16 21:01:43 so, at least in the PMIC's imagination, usb power was briefly interrupted Oct 16 21:02:21 yessss Oct 16 21:02:35 (the PMIC has a rich imagination) Oct 16 21:02:43 perhaps that's how it 'think's its powering down .. usb disconnect Oct 16 21:02:54 no Oct 16 21:03:09 internally I mean Oct 16 21:03:15 also, keep in mind that poweroff works fine when powered via usb alone Oct 16 21:03:40 so why is it crazy when dc attached also? Oct 16 21:04:05 what exact chain of events takes place .. Oct 16 21:04:08 welcome to the TPS65217 Oct 16 21:05:23 why does its state machine lock up if you ramp up its power supply too slowly? why does this only happen if no battery power is present (and in fact the lockup resolves if you introduce battery power) ? nobody knows Oct 16 21:07:46 why, if it's designed for battery-powered operation, are there no battery-related irqs at all (insertion, removal, charging status, etc) Oct 16 21:08:56 why the fuck does it reset all of its registers (including things like charger configuration) when performing a clean shutdown Oct 16 21:09:21 zmatt, i think they meant... "battery" always connected applications... Oct 16 21:09:22 I think the answer is: because the TPS65217 is a piece of shit PMIC Oct 16 21:09:31 thus no reason for insertion/removoal.. Oct 16 21:09:39 charging.. ah.. it's cheap. ;) Oct 16 21:09:42 rcn-ee: it has detection logic for it though Oct 16 21:09:46 just no event reporting Oct 16 21:10:22 and it's not cheap at all Oct 16 21:16:58 the TPS65217 is $3.45 (for large quantity), the TPS65910A31 is $2.75 for same quantity Oct 16 21:25:22 the 65217 is just a crock of misdesign Oct 16 21:32:10 65217? an SoC with a 6502 core? Oct 16 21:33:49 ? Oct 16 21:34:30 oh tps65217...n/m Oct 16 21:38:53 rcn-ee: so, the x15 is getting released with 1.1 silicon, no 2.0 yet... Oct 16 21:39:48 w? Oct 16 21:39:51 ? Oct 16 21:39:53 i belive so.. Oct 16 21:41:03 so only one gigabit eth port Oct 16 21:42:05 there should be two... the alpha board i have, only one worked.. Oct 16 21:42:21 i880 Ethernet RGMII2 Limited to 10/100 Mbps Oct 16 21:42:25 REVISIONS IMPACTED SR 1.1 Oct 16 21:43:06 (also, they sure had fun with reset on this chip...) Oct 16 21:43:45 zmatt, the reset is the whole reason it got delayed (doing math in head... 11 months)... Oct 16 21:44:26 10 months ago, i told gerald, umm... it doesn't software reset... Oct 16 21:44:39 then the guys at ti had a lot of fun... Oct 16 21:44:45 it still doesn't in SR 1.1 Oct 16 21:45:12 zmatt, sr 1.0 was even worse... "no reset"... so the one they fixed in sr 1.1 gets routed everywhere... Oct 16 21:45:24 i862 "Power-on-reset (porz device input signal) is the only 100% reliable reset type. If non-porz reset is used, there is a chance that the device may hang during boot after the reset source is deasserted." Oct 16 21:45:43 zmatt, sr 1.0 the bond wires weren't even connected... Oct 16 21:46:05 i875 "Following a warm Power-on-Reset (PORz) event, the boot process may hang if the SoC is within a narrow temperature range." Oct 16 21:46:14 100% reliable.... except sometimes Oct 16 21:46:22 lol Oct 16 21:46:32 it was also their first mass 22nm... Oct 16 21:46:54 so yeah... every process bug... Oct 16 21:47:16 yeah SR1.0 sounds like a hoot... "Multiple resets (up to three) are needed before the device is fully functional" Oct 16 21:48:29 the sr1.0 was also fun, in that only have of the interleaved ram worked... Oct 16 21:48:44 (more of layout issue, but it was fun..) Oct 16 21:49:57 wonder if anyone will use it.. gdb for c6000's on the x15 is now packaged and pushed. ;) Oct 16 21:50:19 how much flash is on the x15? Oct 16 21:50:42 not fixable using the dmm? one of the proto boards of our dm814x-based design had problems with part of the ram, but I managed to salvage most of RAM with some creative DMM config Oct 16 21:50:43 ds2, exact same eMMC used on the bbb.. Oct 16 21:50:53 sigh Oct 16 21:51:02 rcn-ee: which of the two? please tell me it's the kingston and not the micron Oct 16 21:51:16 this board has kingston.. Oct 16 21:51:28 but you know they'll stick whatever is cheapest and have in quanty.. Oct 16 21:51:37 it's going to be random again? *sigh* Oct 16 21:51:48 the micron is fucking slow Oct 16 21:51:55 besides with this board, grab an ssd and msata-sata cable and just boot off of ssd. ;) Oct 16 21:52:03 wish they ditched the eMMC Oct 16 21:52:11 slap a socket on there Oct 16 21:52:22 the emmc is a waste of a sd interface Oct 16 21:52:30 and 8bit one too.. Oct 16 21:52:37 ds2: MMC1 is timing-optimized for eMMC Oct 16 21:52:58 (that would be MMC2 according to the TRM's 1-based counting, argh) Oct 16 21:52:58 so MMC1 is designed for piss ass slow? ;) Oct 16 21:53:18 zmatt: timing doesn't matter if there isn't enough space Oct 16 21:53:41 at the least, slap on a 32G part. this isn't a cheap board Oct 16 21:54:08 does kingston cough up datasheets? Oct 16 21:54:10 i think we are getting close to switching to 8gb.. only because 4gb's are not as easy to source anymore.. Oct 16 21:54:10 rcn-ee: if it weren't for errata, MMC2 would have supported HS200 mode Oct 16 21:55:26 basically SD and MMC both defined new highspeed modes, but incompatible Oct 16 21:55:27 rcn-ee: at the rate you are generating packages... 8G is going to be small :P Oct 16 21:56:18 ds2, specially with the size of some of the c6000 dependicies... Oct 16 21:56:51 rcn-ee: gdb for c6000 ? I wonder how it copes with an SPLOOP Oct 16 21:57:34 I suppose that's nothing a little hotair can't fix Oct 16 21:58:02 oh I guess it might do fine if the same pipe up/down is used as for irqs occuring during an SPLOOP Oct 16 21:58:28 am I wrong to assume the c6K is under remote-proc? Oct 16 21:59:22 it's under remote-proc... Oct 16 22:01:35 crap.. Oct 16 22:01:47 i need to use yocto... Oct 16 22:01:55 why? Oct 16 22:01:58 to generate the opencl-monitor firmware... Oct 16 22:02:11 lots of ti-x86 only tools... Oct 16 22:02:32 some kind of supervisor they run on the dsp? Oct 16 22:03:09 yeah.. the opencl-monitor is the supervisor for opencl applications.. Oct 16 22:03:15 (why would you want/neeed one?) Oct 16 22:03:43 to run opencl on the c6000's... to do bitcoin mining... Oct 16 22:03:52 (with my username...) ;) Oct 16 22:03:59 lol Oct 16 22:04:30 it's more for people who don't know c6000, opencl is a sorta/decent/crappy/yetanother interface.. Oct 16 22:04:35 YES!! time to deprecate Ubuntu crap ;) Oct 16 22:04:38 just write an application, load it into the DSP, run it... why all this complicated (and probably bloated) crap around it Oct 16 22:04:49 The Return of the Angstrom Oct 16 22:05:28 or... i'll just steal it from ti's 'built' sdk... sweet don't need yocto... Oct 16 22:05:56 Ubuntu Strikes Back? :( Oct 16 22:06:55 on a different thing... Oct 16 22:07:16 rcn-ee: can I read from your replies on SGX that - rendering OpenGL off screen works today on the Bone? Oct 16 22:07:45 given that it just renders into a piece of RAM anyway, why not? Oct 16 22:07:57 it's more like straight to the fb.. and that fb might be the active one.. Oct 16 22:08:03 cuz of the crap about egl, etc Oct 16 22:08:21 hmmm nice Oct 16 22:08:39 ds2, http://git.ti.com/gitweb/?p=graphics/omap5-sgx-ddk-um-linux.git;a=shortlog;h=refs/heads/am3/k4.1 Oct 16 22:08:55 so the Bone will work for simplified supercomputing :D Oct 16 22:09:19 no interest in displaying the results. rather want the SGX for supercomputing Oct 16 22:09:46 ds2, then that link will be perfect, that's the sgx lib/bin's for null mode.. Oct 16 22:10:24 the sgx headers are: sudo apt-get install ti-sgx-335x-modules-`uname -r` Oct 16 22:10:30 rcn-ee: btw, it might be useful if we can verify the watchdog works on the alpha board (when you're near it to hard-reboot in case it doesn't)... right now I'm a bit nervous to peek around, considering errata like the one where a wrong access to the control module can completely lock it up Oct 16 22:11:06 probally not going to be using your images Oct 16 22:11:12 zmatt, go for it Oct 16 22:11:17 i'll be home shortly... Oct 16 22:11:36 zmatt: does it have the full CM or the AM335x CM? Oct 16 22:11:48 ds2: ?? Oct 16 22:12:52 zmatt: is it as flexible as the older DM37x/OMAP3 CM? Oct 16 22:12:55 Control Module Oct 16 22:13:11 ds2: the control module of omap-family devices is very different from that of the netra/centaurus/subarctic/aegis family Oct 16 22:13:33 am57xx is omap5-derivative Oct 16 22:14:00 it never was very clear on how omap5 is it Oct 16 22:14:49 well it seems there are plenty of differences too, but it's the closest ancestor afaict Oct 16 22:16:24 the centauroids all have *very* similar control modules... they only made sure there were *just* enough differences to be incompatible Oct 16 22:16:45 ;) Oct 16 22:18:32 rcn-ee: btw, are you aware your /etc/apt/apt.conf.d/02apt-get-clean breaks tab-completion for apt-get install ? Oct 16 22:19:26 does it? Oct 16 22:19:40 the cache is removes is the one consulted for it Oct 16 22:20:20 yeap.. clears out the cache.. i didn't save the #'s, but it saved enough MB for the older 2GB image.. Oct 16 22:21:28 since we do, apt-get clean anways in the script we could get rid of now.. the 2gb isn't a big deal anymore.. Oct 16 22:21:31 clearing out /var/cache/apt/archives/ is benign Oct 16 22:21:39 removing the .bin files isn't Oct 16 22:21:52 not only does it break tab completion, it also makes apt a lot slower Oct 16 22:22:07 since it needs to rebuild them Oct 16 22:22:34 so https://github.com/RobertCNelson/omap-image-builder/blob/master/scripts/chroot.sh#L284 Oct 16 22:22:38 just keep the *.bin's... Oct 16 22:23:46 I personally also keep the archives.. they've already been written to mmc anyway and they're useful to rsync to other BBBs to speed up an apt-get upgrade there, but they're not strictly needed Oct 16 22:24:46 but I generally have plenty of space left on BBBs Oct 16 22:24:47 the archives are the main problem.. when you have limited eMMC space... Oct 16 22:26:35 now if they just slapped a 32G eMMC on there... Oct 16 22:26:49 only iff... Oct 16 22:27:00 you know how many angstrom's install you could have on that! ;) Oct 16 22:27:12 you can self host angstrom :D Oct 16 22:27:29 ssh root@192.168.7.1 "bitbake" Oct 16 22:27:30 ;) Oct 16 22:27:45 zmatt, humm, dropping the *.bin's still doesn't fix autocomplete... Oct 16 22:28:01 you know, droping the *.bin removal from .conf.. Oct 16 22:28:09 rcn-ee: after apt-get update? Oct 16 22:28:26 and logout... and now rebooting..... Oct 16 22:28:37 I didn't need to do any of that on the x15 Oct 16 22:28:39 (i even installed a few packages to get the cache up..) Oct 16 22:29:25 wait, the lines setting the pkgcache to "" obviously also need to be removed Oct 16 22:29:38 i bet it's the pkg/src cache too: https://github.com/RobertCNelson/omap-image-builder/blob/master/scripts/chroot.sh#L286 Oct 16 22:31:09 watchdog expired Oct 16 22:31:13 let's see if it comes back Oct 16 22:31:36 debian@BeagleBoard-X15:~$ sudo apt-get install n Oct 16 22:31:36 Display all 798 possibilities? (y or n) Oct 16 22:31:40 that works.. ;) Oct 16 22:32:00 would be a funny hack to change that message to "Install all 798 possibilities? (y or n)" Oct 16 22:32:11 x15 is back up \o/ Oct 16 22:32:27 wait... something works on the sr1.1 silon? :0 Oct 16 22:32:40 well I'm assuming the hardware workaround for reset is in place Oct 16 22:32:49 (every reset is made a POR) Oct 16 22:33:25 but yes, something works in sr1.1 silicon and an alpha pcb ;) Oct 16 22:33:40 maybe the second eth works too if you force it to 100 Mbit, have you tried that? Oct 16 22:33:57 remove gigabit from the advertised link speeds Oct 16 22:34:25 zmatt, well on "that" alpha... the other one is actually dead.. Oct 16 22:34:31 does the X15 have a Gigabit PHY? Oct 16 22:34:37 ds2: two Oct 16 22:34:50 who's gigabitPHY? Oct 16 22:35:30 micrel.. Oct 16 22:35:37 Micrel KSZ9031 says dmesg Oct 16 22:36:00 ds2, the schemtic is actually out now: https://github.com/beagleboard/beagleboard-x15 Oct 16 22:36:05 bb, running home.. Oct 16 22:36:09 oh 'k Oct 16 22:36:13 ohhh, schematic Oct 16 22:36:31 my productivity is going to be ruined Oct 16 22:44:55 funny, the x15 is simply the baseboard of the am572x-evm Oct 16 22:59:11 <_av500_> i'm heating up the etch solution Oct 16 23:08:24 wb rcn-ee Oct 16 23:21:43 the cortex-a15 is a bit annoying... no support for write-through cache mode, which is normally my favorite mode when doing baremetal stuff (since read-latency is often the bottleneck, not write-throughput, and write-through is convenient for debug visibility) Oct 16 23:23:38 and it seems to have a glaring security hole when used in hardware virtualization mode (unless it's a documentation error) Oct 16 23:32:49 well it doesn't bootup with hardward virt enabled.. there's hacks for u-boot. ;) Oct 16 23:33:34 I don't have a strong urge to use hw virt at the moment Oct 16 23:34:19 I'd be more curious about clearing the SMP bit on the A15 cores and using one for linux and one for baremetal code Oct 16 23:34:56 or just swap over the c6000, run linux on that, then do baremetal on both a15's. ;) Oct 16 23:35:22 I can't imagine linux runs well/efficiently on a c6x Oct 16 23:35:39 there's port... ;) Oct 16 23:35:45 that doesn't mean it works well Oct 16 23:36:17 I'd consider running linux on a c6x is an act of desperation Oct 16 23:37:34 like me building opencl-monitor in yocto... desperation... Oct 16 23:37:42 general-purpose code tends to be fairly heavy on branches and calls Oct 16 23:37:49 a branch on c6x has 5 delay slots Oct 16 23:39:49 otoh it can do really cool things with tight loops ( SPLOOP <3 ) Oct 16 23:40:30 bah... ti... your yocto sdk is broken... Oct 16 23:40:30 and I thought you could grab the monitor from TI's sdk? Oct 16 23:41:05 looks like i will.. Oct 16 23:41:29 also, why on earth is the usb2phy control register on the am57xx called CTRL_CORE_SRCOMP_NORTH_SIDE Oct 16 23:41:46 the usb2phy status register being CTRL_CORE_SRCOMP_SOUTH_SIDE Oct 16 23:42:00 very intuitive names, really Oct 16 23:42:20 laughs, maybe some humor snuck by the managers... Oct 16 23:42:47 everybody knows control signals are always on the north side and status signals on the south side Oct 16 23:46:09 rcn-ee: and I found something enigmatic in the Cortex-A15 that TI failed to completely purge from the TRMs Oct 16 23:47:06 a way to turn on eve? Oct 16 23:47:07 the 572x just listed it as an address range in the local peripheral space, labeled "CMU" Oct 16 23:48:27 the 571x also has docs on the watchpoint submodule in the Memory Adapter, and there is it listed as one of the initiators (along with core 0-3, and "other (ACP, FEQ, etc)") Oct 16 23:48:34 "Not supported on this device" of course Oct 16 23:49:39 I really have no idea what it could possible be, and "CMU" is an impossible abbreviation to google, even if you combine it with more keywords and limit it to ti.com or arm.com Oct 16 23:50:09 that's the first thing i did too... Oct 16 23:50:34 and turning on EVEs will be no problem if they're not disabled by eFUSE, and absolutely hopeless if they are Oct 16 23:52:37 if you have an xds100v2, I have a little util that dumps all ICEPick registers... that's usually informative about the presence and accessibility of cores Oct 16 23:54:00 i have a blackhawk somewhere... Oct 16 23:55:13 I can probably also adapt it to other FT2232H-based JTAG adapters, but the xds100v2 is definitely preferred Oct 16 23:57:02 i think it's this one: https://www.digikey.com/product-detail/en/TMDSEMU100V2U-20T/296-31067-ND/2261950 Oct 16 23:57:12 i can always pull one from stock monday .;) Oct 16 23:57:13 no hurry though, it seems my source tree isn't in a compilable state (haven't looked at it in a while) Oct 16 23:57:58 good.. as i'm lookin around in my office-lab... i need to clean... Oct 16 23:58:22 rcn-ee: or I can just jbang... only requires that nTRST is tied high and TDO is connected to some GPIO (e.g. EMU1 Oct 16 23:58:52 but that means meddling with the control module, and that place is still scary Oct 16 23:58:59 here i was just goint to plug it into the x15... you could bang away till it reboots... Oct 16 23:59:27 yeah if you have an xds100v2 that's better since I have the code for that anyway Oct 17 00:00:14 going via an usb jtag adapter is definitely not as elegant as using gpios for self-jtagging, but fuck elegance, it works Oct 17 00:01:35 I still hope to write a jtag controller in PRU code Some Day™ .. it should really be very well suited for the task Oct 17 00:01:46 likewise for receiving real-time trace data Oct 17 00:02:24 but you'd still need some kind of robust electrical interfacing to the target Oct 17 00:04:30 eh found it.. its the olimex xds100v3-clone, with the big connectors... Oct 17 00:04:35 ew Oct 17 00:04:55 you actually have a cable from that kludgy thing to CTI-20 ? Oct 17 00:04:56 they put the small jtag pins on the x15... Oct 17 00:05:05 nope.. Oct 17 00:05:06 since afaik no such cable exists in this universe Oct 17 00:05:43 they really screwed that one up... using CTI-20 pinout but with the wrong connector, guaranteeing you will not be able to find any cable or adapter for it Oct 17 00:06:01 i'm pretty sure i have the xds100v2 in a box at my desk... i'll just bring it home for day.. Oct 17 00:07:00 the blackhawk one is also suspicious btw, it's not an XDS100v2 but "XDS100v2-compatible" yet customized Oct 17 00:07:34 but hopefully it really is compatible Oct 17 00:07:56 (and not merely compatible with CCS) Oct 17 00:07:57 well it's this one... from ti... but it says blackhawk on the label: https://www.digikey.com/product-detail/en/TMDSEMU100V2U-20T/296-31067-ND/2261950 Oct 17 00:08:53 that's odd, since that part code should be the Spectrum Digital one afaik Oct 17 00:09:44 the form-factor does seem to be blackhawk though Oct 17 00:09:51 well, we'll see Oct 17 00:11:14 I really wish olimex didn't screw up that connector... I was also looking at it, since I was interested in reprogramming the fpga to replace the TAP.7 support by stuff that's actually useful, like receiving trace data via the EMU pins Oct 17 00:11:49 the xds100v2's cpld is nice, but probably too limited for that, plus they didn't connect EMU2-4 at all Oct 17 02:43:55 ok, so there's apparently an "L4SEC" which houses two AES modules, two hash modules, a des module, and an RNG Oct 17 02:44:29 the fact that they live on a separate L4 makes me wonder if it's fact something like SecSS found on netra/centaurus **** ENDING LOGGING AT Sat Oct 17 02:59:58 2015