**** BEGIN LOGGING AT Tue Apr 11 03:00:05 2017 Apr 11 06:26:10 help Apr 11 11:23:07 I am trying to reliably boot from the sdcard on my (old BBB) (2 gig) . I removed the internal mmc partition (e.g. using dd) and the board now boots from mmc without the need to press the user button Apr 11 11:23:11 I want to access the device over serial and wonder why this doesn't always work sometimes I get until debug: [console=ttyO0,115200n8 Apr 11 11:23:14 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait Apr 11 11:23:16 coherent_pool=1M net.ifnames=0 quiet Apr 11 11:23:19 cape_universal=enable] ... Apr 11 11:23:21 ... Apr 11 11:23:24 Starting kernel ... Apr 11 11:23:26 and then nothing Apr 11 11:23:29 (I have two BBB's that have the same behaviour) but for one I replaced the DDR memory the boot log looks like http://paste2.org/p8GPjnB2 Apr 11 11:23:32 the first times I booted it got a bit futher and even until the debian:mypasswd login (I tried bone-debian-8.7-iot-armhf-2017-03-19-4gb.img Apr 11 11:23:35 and bone-debian-8.7-lxqt-4gb-armhf-2017-03-19-4gb.img) Apr 11 11:23:37 but only have serial (no HDMI or other stuff) Apr 11 11:23:40 sometimes did get the usb cdc device an such Apr 11 11:23:42 (reposting I was first talking on #beaglebone) Apr 11 11:32:06 hmm Apr 11 11:32:43 replaced the ddr memory? o.O Apr 11 11:33:45 note that you can get more info during boot by omitting the "quiet" parameter Apr 11 11:33:53 (in /boot/uEnv.txt) Apr 11 11:35:50 or if it hangs too early even for that there's the "earlyprintk" parameter, but the kernel needs to be correctly setup for that and I'm not sure it is (the -bone kernels are more likely to be than the -ti kernels, but I'm not sure about either of them) Apr 11 11:38:18 yeah, neither of 'em is Apr 11 11:40:28 note that not having hdmi output is normal for the iot image Apr 11 12:07:25 yea. I kinda .. just don't know what is happening (also did remove the quiet from the uEnv.txt but that did not change anything , also tried different sd-cards) perhaps it is a power issue Apr 11 12:08:50 it's hard to say based on the info so far Apr 11 12:08:56 btw, which BBB revision? Apr 11 12:09:18 yes! (old ones e.g. 2Gig ) and a white one :P Apr 11 12:09:37 "2Gig" is not a revision number :P Apr 11 12:10:41 replaced power supply and not I get passed the botting linux and get a serial prompt Apr 11 12:10:58 searching for a better answer about the revision Apr 11 12:11:19 BBB revisions since first production release are { A4A, A5, A5A, A5B, A5C, A6, A6A, B, C } (where C is the revision that has 4GB of eMMC) Apr 11 12:12:29 you can read it from eeprom when you've got it to boot, although *I think* it should also be marked on the pcb somewhere Apr 11 12:17:00 I haven't found it so far Apr 11 12:17:58 sudo head -c 16 /sys/bus/i2c/devices/0-0050/eeprom | hexdump -C Apr 11 12:18:12 if you can get it to boot Apr 11 12:19:14 http://paste2.org/dHDGNnnv .U3.A335BNLT0A5A Apr 11 12:19:17 so 5A Apr 11 12:19:18 A5A Apr 11 12:19:29 right Apr 11 12:22:11 ok, in that case beware that it's recommended to avoid too many power-ups/downs with serial rxd high as this may damage the uart0_rxd I/O pin in the long term. keeping the rxd pin low by disconnecting the console or sending a continuous break during power-up/down transition will safeguard the I/O Apr 11 12:24:26 I was not aware of that. (both are A5A) but the boards have already served for long enough and with the mistreatent it is getting...(e.g. the first time for me replacing DDR... they have bigger problems) Apr 11 12:24:32 but it works! Apr 11 12:25:12 there's a simple hardware patch to fix the issue, as long as you don't need too much current from VDD_3V3B (e.g. for a CAPE) Apr 11 12:25:17 https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/_oNSCta5WusJ Apr 11 12:25:52 yes you mentioned replacing the DDR... what? o.O why? Apr 11 12:26:35 I've never heard of anyone having problems with the DDR3 memory Apr 11 12:26:52 learning to use IR rework station Apr 11 12:27:19 (unless you did it to replace the 512MB ram chip by one of the rare and hard-to-find single-rank 1GB ram chips) Apr 11 12:27:33 lol Apr 11 12:27:34 ok Apr 11 12:28:08 and .. I was very lucky that the chip is similar enough (did not change any DDR settings) Apr 11 12:32:31 the BBB runs it at DDR3-800 6-6-6, really DDR3L chip of the same geometry will do :) Apr 11 12:32:38 *any DDR3L chip... Apr 11 12:32:55 they don't even include such low speeds in the datasheets anymore these days Apr 11 12:33:49 I see Apr 11 12:33:53 keesj_: what kind of problems did you have prompting a replacement of the DDR? Apr 11 12:38:33 Beeo biio Apr 11 12:38:35 if one goes through all that effort, I'd at least try to find a compatible ram chip that's 1GB, or supports 5-5-5 timings, or both :) (note that taking advantage of either would require a small u-boot modification, although it would still work without one) Apr 11 12:38:36 * Spidler blips in Apr 11 12:38:44 Hi all, sorry for the last few months of idling. Apr 11 12:40:26 Spidler: we're now reconfiguring the eMMC on BBBs to have 1.8G SLC instead of 3.6G MLC :) Apr 11 12:40:59 (along with setting the write-reliability bit...) Apr 11 12:42:03 and you're forgiven, this time Apr 11 12:42:05 ;) Apr 11 12:44:09 Haha. Right :) Apr 11 12:44:26 Well. I should have talked about this project earlyer here as I might have been able to indeed pimp my mem Apr 11 12:44:27 Glad my misery there helps someone get something better :-) Apr 11 12:44:41 I wonder if that worn-out eMMC you got would become (somewhat) usable again if you reconfigure it to SLC, since it would have much more margin Apr 11 12:44:44 zmatt: Ended up in hospital, just back in the office, so this spring has been "crap" by most definitions. Apr 11 12:44:50 ick Apr 11 12:45:02 Yeah, I'm pondering the same, Have a bin with 8 or so of them Apr 11 12:45:12 that indeed doesn't sound like the most ideal spring Apr 11 12:45:23 Indeed. Apr 11 12:45:56 And today I managed to (accidentally) flash and boot a kernel without MTD or MMC support in it on one of my machines. Apr 11 12:46:03 I feel utterly bright Apr 11 12:46:06 haha Apr 11 12:46:17 sorry :) Apr 11 12:46:24 Spidler: welcome to the crap club. Apr 11 12:46:25 Laugh all you want, I do the same :-)= Apr 11 12:46:32 Because it _is_ quite hilarious really Apr 11 12:46:41 Spidler: I'm in hospital since last April 1st. Apr 11 12:46:53 thinkfat: Last? As in, one year? _damned_ Apr 11 12:47:00 Spidler: no, typo Apr 11 12:47:02 :-) Apr 11 12:47:06 thinkfat: Thankfully I'm out, what happened to you? Apr 11 12:47:10 Spidler: nothing Apr 11 12:47:19 Spidler: but my son has pneumonia Apr 11 12:47:37 and since he's too small to stay here alone... Apr 11 12:48:35 I just had a fun week/weekend involving getting the product that had been sold and *needed* to ship at least somewhat working Apr 11 12:49:02 thinkfat: Ah, right :-( That one sucks, hope he recovers. Apr 11 12:49:44 zmatt: Oh yeah, we had one of those last week. Everything was emergency and that "one off demo" turned into production. web development sucks Apr 11 12:51:13 uhuh, except in this case both hw and sw still had issues the evening before the morning it had to ship :) Apr 11 12:52:08 for me the most important bit was being making sure we would update it afterwards Apr 11 12:52:29 except yesterday I learned that there's been a bit of miscommunication and it's been installed somewhere without internet connectivity :D Apr 11 12:52:56 fun times Apr 11 12:54:22 haha, lovely . Apr 11 12:54:36 And yeah, we're involved in bopping things on standards tracks Apr 11 12:54:57 And one of the requirements we want to push for is that everything that passes certification MUST have OTA updates Apr 11 13:16:03 Spidler: btw, converting the eMMC to SLC is pretty trivial: https://pastebin.com/GktxniGK Apr 11 13:18:43 this includes the write-reliability setting since it has to be set at the same time Apr 11 13:18:49 (if you ever want to set it) Apr 11 13:20:55 I'm still planning on making a friendlier and less error-prone util for this Apr 11 13:23:14 btw, fun paper about MLC flash vs power loss -> https://cseweb.ucsd.edu/~swanson/papers/DAC2011PowerCut.pdf Apr 11 13:23:57 well, flash vs power loss, but MLC flash gets you the most fun Apr 11 13:31:21 thinkfat: i do agree that the code in the firmware you pointed out is incorrect Apr 11 13:31:34 thinkfat: if you remove it or correct it then you are able to resume? Apr 11 13:32:00 thinkfat: I noticed that if I correct the code I see no different in the vtp_ctrl register after a resume than if I use firmware unchanged Apr 11 13:32:09 thinkfat: just wondering if you see the same Apr 11 13:34:31 dgerlach: oh btw that reminds me, about the comment here: http://git.ti.com/processor-firmware/ti-amx3-cm3-pm-firmware/blobs/master/src/pm_services/i2c.c#line111 Apr 11 13:34:50 I understand the source of the confusion there Apr 11 13:34:58 the TRM is correct, but misleading Apr 11 13:35:20 when in bypass, it does use divider N2 Apr 11 13:35:45 divider "N2" however is not configurable on the AM335x, the value read on line 111 is divider "N" Apr 11 13:38:15 (on some other processors, e.g. dm814x, the two dividers can be configured independently) Apr 11 13:42:01 so I would suggest removing line 111 and replacing the comment by one warning that n2_div is hardwired to 0 on the am335x/am437x and should not be confused with n_div Apr 11 13:47:51 to avoid unnecessarily propagating confusion :) Apr 11 14:16:32 dgerlach: if I remove the code or correct it, my trouble with resume corrupting the DDR is fixed. Apr 11 14:17:18 dgerlach: I therefore wonder what makes it work with the Linux kernel? The bug is basically there since the initial implementation. Apr 11 14:19:00 dgerlach: even on my board, using Linux shows no problem with DS0, while on my OS DS1 crashes miserably. Apr 11 14:27:36 thinkfat: ah ok, that's a very interesting data point thanks, I have not tried DS1 Apr 11 14:28:09 dgerlach: Linux kernel doesn't support it, only STANDBY and DS0 Apr 11 14:28:41 thinkfat: yeah i know, we only have mem and standby within linux to map to so we went with ds0 and standby Apr 11 14:28:42 dgerlach: difference is PER=OFF on DS0, vs ON on DS1. But should not make difference for DDR Apr 11 14:29:14 dgerlach: yay for interface standards :-) Apr 11 14:29:22 thinkfat: well emif loses context and must be restored for per turning off, so that causes all sorts of ddr headaches Apr 11 14:29:25 thinkfat: ha, yeah Apr 11 14:30:10 dgerlach: does control module actually needs to be saved and restored in DS1? Apr 11 14:30:25 thinkfat: no, that is in wkup domain Apr 11 14:30:33 dgerlach: ok Apr 11 14:30:43 thinkfat: so it won't lose context unless voltage is removed from soc Apr 11 14:31:04 dgerlach: and that would be RTC-Only case, which is really a "timed cold start" Apr 11 14:31:14 thinkfat: indeed Apr 11 14:31:18 dgerlach: so it doesn't make sense to save/restore Apr 11 14:31:28 dgerlach: ok, so I'll eliminate that code. Apr 11 14:31:37 dgerlach: one less headache to worry about Apr 11 14:32:11 thinkfat: correct, it is not needed for am335x Apr 11 14:36:40 dgerlach: but INTC I need to save/restore? Apr 11 14:42:51 thinkfat: no, not for ds0 Apr 11 14:43:33 thinkfat: we support rtc+ddr mode on am437x, which is like rtc-only mode but it keeps ddr in self refresh and can resume just like ds0, but in that case EVERYTHING loses context Apr 11 14:43:49 thinkfat: so there is some equivalent code for am335x as both am437x and am335x share sleep paths Apr 11 15:41:45 am335x could probably support that if you use that pmic ? Apr 11 15:46:53 (tps65218) Apr 11 15:47:09 which seems to be responsible for making it possible Apr 11 16:07:44 JOIN Apr 11 16:07:50 SUCCES Apr 11 16:08:18 Hello, I have an issue which needs your advice and help Apr 11 16:08:46 Are you there Apr 11 16:10:19 aww, now we'll never find out Apr 11 16:36:42 that was my drama for the day Apr 11 16:42:51 hmm? Apr 11 20:10:50 lol, the omap-sha256 driver is giving the wrong answer whenever the input length is exactly {2,3,4,5,...} * 64 bytes Apr 11 20:11:27 eh? Apr 11 20:12:54 some buffer size rounding going wrong? Apr 11 20:13:14 bytes cut off or random stuff added? Apr 11 20:13:38 I'm thinking something like while(remaining > 64) { ...; remaining -= 64; } leftover-handling; Apr 11 20:13:45 or >= 64 Apr 11 20:13:52 whichever it is, it should be the other one ;) Apr 11 20:14:45 no dma? Apr 11 20:15:05 it might Apr 11 20:15:31 it might have special-case handling for the last bytes even if dma is used Apr 11 20:16:33 cacheline related? Apr 11 20:16:50 dma and missing cache clean missing? Apr 11 20:16:56 seems unlikely Apr 11 20:17:02 too much missing Apr 11 20:17:49 that would be far more likely to go wrong with non-round input lengths Apr 11 20:19:04 unless there's a off-by-one-cacheline error Apr 11 20:32:45 https://github.com/mvduin/af_alg Apr 11 20:36:15 hilariously, the version using the hw accelerator is also slower than the software (neon) version... I don't know how the kernel driver manages to accomplish that Apr 11 20:40:56 I've seen this being blamed on AF_ALG though, I should probably try cryptodev-linux for comparison Apr 11 20:41:04 and of course uio Apr 11 20:42:40 well correctness first :) Apr 11 20:46:26 no, food first :) Apr 11 20:46:39 can't argue with that Apr 11 20:46:43 weird thing is, I seem to recall this issue being discussed aaaages ago on E2E Apr 11 20:47:11 so I'm wondering if it really never got fixed, or if the fix got lost somewhere on the way upstream Apr 11 20:49:51 maybe a fix was circulated but never upstreamed Apr 11 20:49:57 and nobody cared Apr 11 20:50:16 since it was slower that a software version using neon :-D Apr 11 20:55:25 Hi, Can the beagleboard black wireless support CAN and CoDeSys? Apr 11 21:06:38 CAN: yes Apr 11 21:06:43 CoDeSys: never heard of it Apr 11 21:08:18 thinkfat: well if my notes are right it *should* be around 4 times faster Apr 11 21:09:11 might be off by a factor of two if I'm mistaken about which interconnect clock is used, but that still means it should be twice as fast Apr 11 21:09:20 while leaving the cpu mostly idle Apr 11 21:11:11 likely the most important aspect Apr 11 21:15:40 lol, ok I just changed the cortex-a8 freq to 500 MHz to allow the hw engine to stand out better Apr 11 21:15:50 its performance dropped by 50% too Apr 11 21:16:02 oh Apr 11 21:16:13 really? the thing is cpu bound? Apr 11 21:16:26 I have no idea how, but apparently yes Apr 11 21:16:46 where's the source of this? Apr 11 21:16:56 I pasted the link not long ago Apr 11 21:17:04 https://github.com/mvduin/af_alg Apr 11 21:17:51 it builds two executables, both using the same API but one using the omap-sha256 engine and the other using the in-kernel neon implementation Apr 11 21:18:34 it uses splice() or sendfile() (whichever works) to keep the actual work entirely kernel-side Apr 11 21:23:52 zmatt: no, kernel driver source Apr 11 21:23:58 oh Apr 11 21:24:13 drivers/crypto/omap-sham.c Apr 11 21:29:51 I'm using 4.9-bone series, in case it matters Apr 11 21:39:17 Unnr:no Apr 11 21:40:24 ? Apr 12 02:03:03 I need help with flashing the Beaglebone Wireless. Can anyone help me please? **** ENDING LOGGING AT Wed Apr 12 03:00:01 2017