**** BEGIN LOGGING AT Mon Jul 25 02:59:58 2016 Jul 25 03:13:01 Ok, I've narrowed down everything to a problem with the boot loader. New MLO = utter failure. Old MLO = partial failure, but only because it's old. Jul 25 03:13:56 I figure if I can build it with the right settings I should be able to get it to work. I just don't know how to do that and all the instructions I'm running into are for the beaglebone, or at best the -xM :( Jul 25 03:14:23 I thought the xm was very similar to the original? Jul 25 03:16:31 So did I. It's just the dm3730 vs the omap 3530 and is supposed to be just a straight upgrade, but I think it's actually an issue with the RAM Jul 25 03:17:08 hmm Jul 25 03:17:11 Different RAM chips, different initialization or something. I dunno, I'm an app developer, not a boot rom developer. Jul 25 03:18:18 both are lpddr though Jul 25 03:19:48 https://groups.google.com/forum/?fromgroups=#!topic/beagleboard/XhHgB-0oQmk Jul 25 03:20:17 Different ram with the C5: "This new revision results in a change being required to the UBoot and Xloader" Jul 25 03:20:21 ahhh Jul 25 03:21:21 Now I just need to figure oot how to build it, but all links I find are dead or beaglebone specific Jul 25 03:22:13 actually it seems the difference is in the nand, which is also part of the PoP Jul 25 03:22:59 http://e2e.ti.com/cfs-file/__key/CommunityServer-Discussions-Components-Files/353/7416.MT29C4G48MAZAPAKQ_2D00_5-IT_5F00_Micron-168_2D00_Ball-NAND-Flash-and-LPDDR-PoP-_2800_TI-OMAP_2900_-MCP.pdf Jul 25 03:24:23 that shouldn't affect SD booting though Jul 25 03:24:41 unless something changed about how the ram works too Jul 25 03:24:44 oh it did Jul 25 03:24:53 Iunno. I feel like I'm just spinning in circles Jul 25 03:25:17 "the old Micron PoP had two 128MB RAM parts, one on each chip select line. The new one has only one of 256MB." Jul 25 03:25:36 really, that sort of thing is something u-boot ought to be able to auto-detect easily Jul 25 03:26:48 but most likely it just reads the board id from i2c eeprom or such to decide on the ram config to use Jul 25 03:28:34 hmmm? Jul 25 03:28:41 the BBC/BBX do not have i2c eeproms Jul 25 03:28:52 no? how will it then know it's rev C5 ? Jul 25 03:29:00 it uses GPIOs Jul 25 03:29:11 okay, that works too I guess Jul 25 03:29:17 it is only the AM335x disaster that uses the EEPROMs Jul 25 03:31:18 actually, looking at u-boot, apparently C5 uses the same board revision as C5, they read ID info from the PoP to distinguish them Jul 25 03:31:23 *C4 Jul 25 03:33:06 WizardStan_: putting some debug messages there (get_board_mem_timings() in board/ti/beagle/beagle.c in u-boot) would at least let you verify it's correctly recognizing it Jul 25 03:33:18 I hope at least the debug console already works at that point Jul 25 03:33:33 yeah it should Jul 25 03:34:21 ohh, life gets more complicated... "If we use SPL then there is no x-loader nor config header so we have to setup the DDR timings ourself on both banks." Jul 25 03:34:41 I'll have a hack at it tomorrow. I've abandoned anything even closely resembling instructions and I'm just bashing my way through the u-boot mainline git repository Jul 25 03:34:43 in other words, if x-loader or a config header is used then the u-boot memory setup code is skipped Jul 25 03:35:07 I would use mainline yes, possibly with https://github.com/eewiki/u-boot-patches/blob/master/v2016.07/0001-omap3_beagle-uEnv.txt-bootz-n-fixes.patch Jul 25 03:35:58 Thanks. I'm off for the night, it's getting late. Jul 25 03:36:15 hardware init on an omap does seem more involved than the am335x Jul 25 03:36:39 for omap5 I noticed that u-boot writes control module registers marked as "reserved" in the TRM :/ Jul 25 07:30:28 hello everyone Jul 25 07:31:21 is there any method of catching a "BREAK" condition on the serial bus (UART)? Jul 25 07:32:50 all examples that are available on web are not working Jul 25 07:33:45 I think that the driver don't actually signal this exception Jul 25 07:34:03 any ideas how to make this work? Jul 25 07:34:58 this is the code I was using: http://stackoverflow.com/questions/1492858/linux-receive-signal-break-for-ttycontrol-program Jul 25 07:35:24 hardware: BBB rev. C with Debian distro Jul 25 08:16:36 anyone? Jul 25 08:29:54 mariusmg: maybe you're the first one to try that with the beagle Jul 25 08:30:06 mariusmg: check the serial driver whether it actually handles that Jul 25 08:31:27 is this the driver: https://github.com/torvalds/linux/blob/master/drivers/tty/serial/omap-serial.c Jul 25 08:31:27 ? Jul 25 08:31:37 probably maybe? Jul 25 08:43:17 yep, that is the driver Jul 25 08:52:55 actually current kernels for the bbb don't use the omap-serial driver Jul 25 08:54:07 (you can check which of /dev/ttyS0 and /dev/ttyO0 exists and isn't a symlink... if ttyO0 then you're using omap-serial) Jul 25 09:27:57 @zmatt: on my system both /dev/ttyS0 and /dev/ttyO0 are not symlinks Jul 25 09:28:32 file /dev/ttyO0 outputs: ttyO0: character special Jul 25 09:28:55 file /dev/ttyS0 outputs: sticky character special Jul 25 09:41:54 check with ls -ld /dev/ttyS0 /dev/ttyO0 Jul 25 09:43:16 anyhow it shouldn't matter, either of 'em should support breaks afaik Jul 25 09:48:33 this is the output: Jul 25 09:48:34 crw-rw---- 1 root tty 247, 0 Mar 1 20:46 /dev/ttyO0 crw-rw---T 1 root dialout 4, 64 Mar 1 20:46 /dev/ttyS0 Jul 25 09:59:29 weird Jul 25 10:00:55 our beaglebones all have ttyO0 a symlink to ttyS0 Jul 25 10:01:10 and some other board which uses omap-serial has no ttyS0 at all Jul 25 10:05:19 what distro are you using? Jul 25 10:05:35 and what Linux kernel version? Jul 25 10:06:16 debian, 4.6.0-bone3 Jul 25 10:10:08 I have Debian 3.8.13-bone70 Jul 25 10:10:34 do you think changing the distro would change the behavior? Jul 25 10:14:42 no, kernel will Jul 25 10:15:09 well, changing distro might as a consequence of switching kernel :P **** ENDING LOGGING AT Tue Jul 26 02:59:58 2016