**** BEGIN LOGGING AT Thu Mar 09 03:00:02 2017 Mar 09 09:25:29 zmatt: just checked again, no interrupt to m3 when mpu modulemode is not 0 Mar 09 09:25:38 zmatt: on wfi, I mean Mar 09 09:36:29 ok Mar 09 09:37:13 and the mpu waking on irq when modulemode is 0 ? Mar 09 09:37:33 (and properly in idle) Mar 09 09:41:43 zmatt: that I could not check, my current software setup doesn't cover that case Mar 09 09:45:08 wait, it's a trivial test for me actually... Mar 09 09:46:05 zmatt: hmm, looking at my setup, I think I implicitly test this case, too Mar 09 09:46:12 zmatt: and it looks like you're right Mar 09 09:46:29 zmatt: the mpu wakes up even without interaction from the m3 Mar 09 09:46:42 exactly Mar 09 09:46:55 well, saves me from doing the test again :) Mar 09 09:47:27 zmatt: the test case is simply to halt the m3 and then see if the mpu wakes up on its own, and it does Mar 09 09:47:58 and as I said, iirc this even works when the mpu power domain is off... i.e. I successfully crashed since I hadn't performed the necessary preparations :D Mar 09 09:49:20 yes, that's a different case than I was testing Mar 09 09:49:42 I was only setting MPU_CLKCTRL.MODULEMODE = 0 Mar 09 09:50:08 but without also setting the MPU power domain to off, it will survive of course Mar 09 09:55:09 an intermediate test is setting the clock domain to sw_sleep Mar 09 10:30:18 hey Mar 09 10:31:05 im Nico Weis from Germany and im a elektronik engineering in Mannheim. I have one question for you do you have the Data from your PCB Desgin and the Schematic Software ? We have a Project on the University and want to build some components around of the beaglebord on one circuit board. Thank you for your spending Time. Mar 09 10:32:17 im Nico Weis from Germany and im a elektronik engineering in Mannheim. I have one question for you do you have the Data from your PCB Desgin and the Schematic Software ? We have a Project on the University and want to build some components around of the beaglebord on one circuit board. Thank you for your spending Time. Mar 09 11:29:54 hello Mar 09 11:31:54 what's the best VNC server for a BBB runnin the latest image with LXQT? Mar 09 11:32:14 (using RealVNC from Windows, if this matters) Mar 09 11:44:14 Parduz: that depends on what you are planning to do Mar 09 11:44:48 do you want to access the Xserver as it's running or do you want to run a separate VNC server with its own X-server Mar 09 11:54:42 zmatt: hm, on omap3 there used to be a prm register where you could read the _previous_ power state of each power domain, quite useful to check whether a state transition happened as programmed Mar 09 11:54:58 zmatt: I don't find that on the am335x Mar 09 12:37:25 zmatt: I must say, Ti has really added a lot of documentation especially for suspend debugging since I last looked Mar 09 13:20:02 sorry tbr, i was away Mar 09 13:21:02 i think i'm not understanding your question (yes, i'm a noob) Mar 09 13:22:10 i just want to have the BBB desktop on my Windows PC 'cause working on the LCD cape it's a mess Mar 09 13:46:00 panto: ah, then I'd suggest to look if lxqt has something itself, failing that use x11vnc Mar 09 14:14:42 zmatt: Thanks. I think I'm all set. Mar 09 17:33:42 Hello, I am editing /sys/devices/bone_capemgr.*/slots adding SPI1 dtbo Mar 09 17:33:49 But every time that I restart the system Mar 09 17:34:16 it return to the default values Mar 09 17:34:54 in uEnv I disable the hdmi with: cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN Mar 09 17:35:11 but in 'slots' file they always appear like Mar 09 17:35:20 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI Mar 09 17:35:20 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN Mar 09 17:35:25 I don't know why Mar 09 17:35:28 someone can give a tip ? Mar 09 18:16:05 this is on the old system yes? (jessie) Mar 09 18:20:26 patrickelectric: hmm, I'm not sure but probably the entries are always there since they merely describe the existence of the hardware, doesn't mean the corresponding overlays are loaded... I'm not sure what the flags P-O-- indicate Mar 09 18:21:14 try checking the pinmux settings with my show-pins script (available at https://github.com/mvduin/bbb-pin-utils ) Mar 09 18:21:54 or check kernel log for evidence of graphics-related stuff Mar 09 18:22:01 or actually, just check if /dev/fb0 exists Mar 09 18:23:36 hi all. I've been reading about beagle bone since it came to life but I never find it suitable for my projects as I do another kind of approach using RTOSes and TCP/IP stacks . Mar 09 18:24:00 there are RTOSes for the am335x Mar 09 18:24:04 I found that most projects around the sitara are mostly linux based Mar 09 18:24:11 that is true Mar 09 18:24:24 i read that ti-rtos is not supported for the beagle bone Mar 09 18:24:29 especially since it has two extra cores (in PRUSS) for hard real-time needs Mar 09 18:24:50 yes, i read that i can use linux and an rtos on the PRUs Mar 09 18:24:59 in fact there is some cape board for that Mar 09 18:25:15 although someone complained here that it doesn't work with the new linux kernel. Mar 09 18:25:17 you don't really need any specific cape for that Mar 09 18:25:35 zmatt i undesrtand , it just that the cape will make my deveolpment faster Mar 09 18:26:17 it works with the new linux kernel, you just need to enable it because there are now two ways (uio_pruss and remoteproc_pru) and you need to pick which one you want Mar 09 18:27:08 zmatt what I mean is that I found solutions using rtos and tcp/ip and usb for the sitara and similar (arm cortex) but they are paid (keil for example) Mar 09 18:27:35 I also read that TI has its own rtos and usb and tcip/ip stack but I didn't found it clear if that can be used on the sitara Mar 09 18:28:26 http://software-dl.ti.com/processor-sdk-rtos/esd/AM335X/latest/index_FDS.html Mar 09 18:28:34 it even lists the beaglebone black as supported EVM Mar 09 18:28:48 so I don't know where you got the info that TI-RTOS isn't for the bbb Mar 09 18:29:13 I've read it somewhere, in fact i think it was in the ti forum. Mar 09 18:29:21 that was outdated info then probably Mar 09 18:29:32 ok, that sounds nice then. Mar 09 18:30:04 and what about professional use of it? I found a clone on element14 which claims to be "industrial temperature" Mar 09 18:30:18 with components up to 85° C Mar 09 18:31:00 ambient temperature on the device we are using is about 60° so perhaps the regular/common bbb won't be an option Mar 09 18:31:35 also I don't know how stable is it. zmatt do you have any experience in the field with it? Mar 09 18:31:56 60 degrees doesn't sound particularly warm to me, but I guess it depends on cpu load Mar 09 18:32:55 they seem stable to me Mar 09 18:33:56 zmatt you use them with linux? Mar 09 18:34:01 yup Mar 09 18:34:32 so, if I want to start with a bbb, what would you suggest me? I mean, a bbb of course Mar 09 18:34:34 but any other cable? Mar 09 18:34:38 jtag_ Mar 09 18:34:38 ? Mar 09 18:34:44 if i want to program an rtos for example Mar 09 18:34:55 and later go back to linux if i whish, etc Mar 09 18:35:01 *wish Mar 09 18:35:46 jtag is probably quite essential if you want to debug baremetal / rtos applications unless the rtos includes a debug monitor that operates without jtag Mar 09 18:35:48 I come from another workd (PICs) and I have everything for them, but I don't know any arm, the sitara in the bbb will be my first one. Mar 09 18:36:06 it's rarely useful with linux Mar 09 18:36:25 but if I load an rtoson the bbb and want to go back to linux Mar 09 18:36:28 note that the jtag header isn't soldered onto the beaglebone, you'd need to do that yourself Mar 09 18:36:29 i'll need the jtag? Mar 09 18:36:32 no Mar 09 18:37:32 the bbb has a bootloader so I can't ruin it? Mar 09 18:37:37 the am335x contains a ROM bootloader that can load the system from eMMC, μSD card, and many other boot media. it doesn't care whether that system is linux or not Mar 09 18:37:41 correct Mar 09 18:37:55 the only way to brick it is by causing actual hardware damage Mar 09 18:38:32 sounds nice, and another question , do you know another kind of bbb hardware based boards? I mean it because perhaps i will need more than one serial port (rs485) Mar 09 18:38:39 and I didn't see it on the bbb Mar 09 18:39:01 the bbb is designed for expansion, that's why there are two big expansion headers on it Mar 09 18:39:36 yes, i understand that, but as the hardware schematics are open, I've read that many others have done their boards based on them Mar 09 18:39:39 there are off-the-shelf boards (called CAPEs) for it, and many people just design their own PCBs containing the I/O they need Mar 09 18:39:58 which is a lot lot LOT simpler than designing your own am335x-based board Mar 09 18:40:12 e.g. a CAPE is typically 2-layer, the BBB itself is 6-layer Mar 09 18:40:41 zmatt I do not want to design any hardware, but the I found the CAPEs a little expensive . Mar 09 18:40:51 Where I work we do PCbs from 4 to 12 layers Mar 09 18:40:55 they often are yes Mar 09 18:41:12 but even thow we could do some design I would prefer an already made board. Mar 09 18:41:18 tested, etc. Mar 09 18:41:43 I've found industrial boards in the TI site based on the sitara but they are too expensive. starting from 275u$s and above Mar 09 18:42:12 there are so I/O possibilities in different combinations, finding a ready-made board or CAPE with exactly what you need requires significant luck Mar 09 18:42:42 zmatt yes, that's true. Mar 09 18:43:04 and not all CAPE are well-designed :P Mar 09 18:43:48 zmatt have you connected several usb peripherals to the bbb? Mar 09 18:44:00 perhaps instead of using rs485 i can use it via usb Mar 09 18:44:03 we occasionally use usb, but not often Mar 09 18:44:05 but i will need 6 usbs.. Mar 09 18:44:28 and I could use an expander but perhaps that won't work as on PCs Mar 09 18:45:31 it *should* work, but I would still not advise it... although the linux drivers have gotten better over time, usb has a history of issues on the bbb Mar 09 18:45:57 if you can use rs485 instead, that sounds like a better option Mar 09 18:47:19 unless you need 6 uarts that is, I'm not sure there are that many available on the bbb.. Mar 09 18:49:47 the bbb has 4 uarts, with rs485 I will need only one usart, and perhaps another for console Mar 09 18:50:01 ok that's no problem Mar 09 18:50:05 if using linux I think I could redirect the console output from crc to serial Mar 09 18:50:09 crt* Mar 09 18:50:26 the console is on serial by default Mar 09 18:51:13 many people here disable hdmi entirely to free up the corresponding pins for other uses Mar 09 18:51:37 (the last 20 pins of header P8) Mar 09 18:53:43 zmatt nice Mar 09 18:53:47 you mentioned you're previously mainly familiar with e.g. PICs... keep in mind it's hard to compare the AM335x with small microcontrollers. although you *can* use it as one, once processors become big enough to run linux often that's what people do :) Mar 09 18:53:50 I'll have to read a lot Mar 09 18:54:45 I've programmed from small 8 bits and 8 pins microcontroller to bigger 100pins and 32 bits microcontrollers with ethernet, usb, serial ports, etc. Mar 09 18:54:58 linux meanwhile had to grow in new directions since people suddenly wanted to do all kinds of microcontroller-ish things on it that you normally never would on a desktop linux system, like use gpios directly from userspace Mar 09 18:55:34 i do also PC programming but I am used to linux mostly as a user, no t a developer. I've used and use win* for developing Mar 09 18:55:52 a 32-bit microcontroller is still not quite the same as an 1 GHz Cortex-A8 Mar 09 18:56:03 yes, i am aware Mar 09 18:56:21 i've done products on small 104 form factor x586 based boards Mar 09 18:56:28 that's the closed thing to a bbb Mar 09 18:56:36 closest Mar 09 18:57:16 if you're curious, I once made a tiny example program for the BBB running without any OS and (on request) written in assembly -> https://github.com/mvduin/bbb-asm-demo Mar 09 18:57:33 it just turns a led on/off when you press the S2 button, irq-driven Mar 09 18:57:35 The ecosystem of the products I am developing is moving in the direction of huge connectivity, there is where Linux came to my mind and the bbb in particular. Mar 09 18:57:43 yep Mar 09 18:57:58 as far as now the pic32 is enough but i am thinking in the future Mar 09 18:58:06 in the near future Mar 09 18:58:29 it always takes time to become immersed in a new platform, it's always good to think ahead Mar 09 18:58:34 a u$s 275 board is not cost effective for the product , compared to u$s 35 that we spent right now with a pic32+ethernet+rs485+rs485+usb Mar 09 18:58:48 so the bbb is in the middle :) Mar 09 18:59:23 linux could be a nice option if I solve the hardware communication via rs485 that I have now Mar 09 18:59:39 I know plenty of people use rs485 Mar 09 19:00:17 sounds nice and not crazy to think that there could be a bbb based board with rs485 embedded in the same pcb? (not using CAPEs) Mar 09 19:00:57 it's quite possible, but that would be a low-volume product hence probably much more expensive than a bbb Mar 09 19:01:16 the bbb takes advantage 100.000-unit prices Mar 09 19:01:21 *advantage of Mar 09 19:02:03 yes, i pressume Mar 09 19:02:11 the bbb is 45 to 55 Mar 09 19:02:49 so perhaps having to develop a CAPEs for that Mar 09 19:03:15 it sounds like you guys have experience with making fairly complicated boards... the BBB schematic and PCB is freely available, ask internally for a quote on it ;) Mar 09 19:03:17 the trend now is about 100 per year... with luck it will be 1000 butnot 100k Mar 09 19:04:21 yes but even though there's experience on my team (I do software 99% of the time not pcb hardware design, although i do select many things on the hardware) Mar 09 19:04:32 It would be better to avoid that Mar 09 19:04:42 making a pcb takes time, money and is error prone Mar 09 19:05:08 I understand, but I mean ask them to take a quick glance to judge what pricing to expect @ 100-1000 units Mar 09 19:05:26 since other manufacturers of low-volume AM335x boards would face the same thing Mar 09 19:06:07 so if the answer is more expensive than you want, you can abandon your search for the perfect ready-made board :) Mar 09 19:07:27 =) Mar 09 19:07:37 hey Mar 09 19:08:24 is there any way of adding more RAM on the board? Mar 09 19:08:27 maunix: to be fair, it's not *that* complicated... I mean it's not like an omap5 or fun processors like that Mar 09 19:08:57 so whats the proccess? Mar 09 19:09:25 how can I upgrade it? Mar 09 19:09:26 Guest25365: no, it's not possible Mar 09 19:09:40 Guest25365: SanCloud made the BeagleBone Enhanced with 1 GB of ram... it's not clear whether they're selling them though Mar 09 19:10:02 zmatt have you tested the beaglebone green? seems to be the same without the hdmi connector Mar 09 19:10:03 changing a board that is in front of you is out of the question Mar 09 19:10:23 tbr: maybe he's very skilled with a hot-air rework tool? Mar 09 19:10:44 not even close Mar 09 19:10:45 zmatt: then he wouldn't be asking the question that way, would he? :) Mar 09 19:10:46 :p Mar 09 19:10:47 maunix: I have seen it, I haven't tested it. I have doubts about Seeed's competence Mar 09 19:11:03 I've seen really weird things in the BBG and BBGW schematics Mar 09 19:11:23 the BBGW is downright idiotic Mar 09 19:12:42 on the BBG they're using a spread-spectrum clocking generator instead of a crystal oscillator as main system clock (which is the input clock for all PLLs) Mar 09 19:13:16 noticably, on the BBGW they went back to crystal. I guess they found out that having no stable clock available anywhere on your board is perhaps not entirely ideal :P Mar 09 19:13:47 (the PLLs in the am335x can be individually configured to use spread-spectrum anyway if that's desired) Mar 09 19:14:12 =) Mar 09 19:15:22 Guest25365: one problem is that 1 GB of RAM requires either expensive hard-to-get RAM chips, or a pcb redesign to use two x8 chips instead of one x16 chip (which is what SanCloud did) Mar 09 19:16:43 1 GB per chip (single-rank) is the max size of DDR3 memory chips specified by JEDEC Mar 09 19:17:08 512 MB per chip is the largest size commonly found on the market Mar 09 19:25:58 just got my BBB 4G eMMC rev C. Got question about boot, but could'nt find the answers from google. Anyone can help? Mar 09 19:26:27 the only way to find out is by asking your question. without that, noone can help Mar 09 19:26:53 I am confused with the BBB Rev C 4G eMMC preloaded with Debian Wheezy that I have bought. I flashed it with Debian Jessie bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img. With the SD card still in the BBB with its uEnv.txt {#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh} commented out, I recycled the power thinking that the unit would boot from eMMC, but the unit keep booting from the SD card even without holding down th Mar 09 19:27:22 If the SD card is removed, then the unit booted from the eMMC. Is this the latest way of booting, from the SD card first, even without holding down the S2 button during power cycling? Mar 09 19:28:35 I don't remember it being any other way. if u-boot detect a bootable system on SD it will boot that in preference to one on eMMC Mar 09 19:28:58 even without holding down the S2 button? Mar 09 19:29:36 yes, but in a different way. holding down S2 at power-up removes eMMC entirely from the boot order used by the ROM bootloader Mar 09 19:30:16 in that case u-boot is loaded from SD, without S2 held down u-boot is loaded from eMMC Mar 09 19:30:54 in both cases however u-boot executes its own boot script to load linux, which firsts looks on SD and then on eMMC Mar 09 19:40:15 this is what I read from REF: BBONEBLK_SRM BeagleBone Black System Reference Manual Rev C.1 Mar 09 19:40:26 On boot, the processor will look for the eMMC on the MMC1 port first, followed by the microSD slot on MMC0, USB0 and UART0. In the event there is no microSD card and the eMMC is empty, UART0 or USB0 could be used as the board source. Mar 09 19:40:35 If you have a microSD card from which you need to boot from, hold the boot button down. On boot, the processor will look for the SPIO0 port first, then microSD on the MMC0 port, followed by USB0 and UART0. In the event there is no microSD card and the eMMC is empty, USB0 or UART0 could be used as the board source. Mar 09 19:40:39 page 69 Mar 09 19:44:55 technically that is somewhat correct, but as I explained above this is describing how the processor locates the bootloader Mar 09 19:45:54 (and it doesn't say clearly you need to hold the boot button during power-on, not merely reboot/reset. the cpu will then use the modified boot order until next power-on) Mar 09 19:46:22 meanwhile, the bootloader can of course do whatever it wants Mar 09 19:46:37 in practice, it's currently configured to try SD first and then eMMC Mar 09 19:46:56 Thanks zmatt. 1 more question about UART Mar 09 19:46:57 cape_enable=capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4, BB-UART5 Mar 09 19:47:06 If I want to enable UART 1,2,4,5 of the BBB. I came across that you need to modify /boot/uboot/uEnv.txt to include this: cape_enable=capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4, BB-UART5 Question is, I didn't see an existing uEnv.txt located in /boot/uboot/. Instead it is in /boot. So should I modify the file in /boot/, or create a new uEnv.txt in /boot/uboot/? Mar 09 19:47:40 /boot/uboot/ ? o.O how ancient are the instructions you're reading? Mar 09 19:47:41 I tried both way, none of them work to enable any UART Mar 09 19:47:49 correct Mar 09 19:48:07 I tried to google with the result showing at least 2016 onward Mar 09 19:48:50 try bone_capemgr.enable_partno instead of capemgr.enable_partno Mar 09 19:50:37 so just to modify the one in /boot/ Mar 09 19:50:41 ? Mar 09 19:52:42 I have these 2 lines in /boot/uEnv.txt: Mar 09 19:52:44 cmdline=coherent_pool=1M quiet cape_universal=enable bone_capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4, BB-UART5 Mar 09 19:55:00 no, replace only the capemgr by bone_capemgr Mar 09 19:55:22 I'm pretty sure the cape_enable= part is still required Mar 09 19:55:56 cape_universal is incompatible with loading overlays, but it should get disabled automatically anyway Mar 09 19:56:12 get rid of that space before BB-UART5 Mar 09 20:02:46 ok, in my /boot/uEnv.txt Mar 09 20:02:58 uname_r=4.4.30-ti-r64 Mar 09 20:03:11 cmdline=coherent_pool=1M quiet cape_universal=enable bone_capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5 Mar 09 20:03:16 no Mar 09 20:03:21 or Mar 09 20:03:26 is that one line or two lines? Mar 09 20:03:28 uuid=64b2303d-3b1b-4384-b4ad-5786aa2b81cf Mar 09 20:03:58 currently I have these 3 lines uncommented Mar 09 20:04:18 You meant I have to break this into 2 lines? Mar 09 20:04:25 breaking into two is definitely wrong Mar 09 20:04:26 cmdline=coherent_pool=1M quiet cape_universal=enable Mar 09 20:04:36 bone_capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5 Mar 09 20:05:24 but having bone_capemgr.enable_partno=... in the cmdline variable is different from what you showed earlier, where it was in the cape_enable variable Mar 09 20:05:55 I have no idea whether it works or not, Try It And See Mar 09 20:06:40 I don't use capemgr (or overlays in general) myself and never bothered to look into how exactly this stuff is passed from u-boot to capemgr Mar 09 20:07:27 I'm going to try these 2 lines: Mar 09 20:07:29 cmdline=coherent_pool=1M quiet cape_universal=enable Mar 09 20:07:35 cape_enable=bone_capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5 Mar 09 20:08:44 like I said cape_universal is incompatible with using overlays.. it will get disabled anyway but it might be better to explicitly remove the cape_universal=enable for clarity Mar 09 20:09:46 Good advice, I will do that. Meanwhile, I finally got the UART working! You are the man zmatt! Mar 09 20:17:53 \o/ Mar 09 20:48:48 sigh... "u-boot overlays" ? seriously? i.e. let's take a really unfriendly way of configuring your DT and remove its sole redeeming quality (dynamic loading) and add even more bloat to the bootloader Mar 09 22:25:44 general q - of the people that have the blue, how many have blown drivers on it already? Mar 09 22:47:05 lol Mar 09 23:11:31 trying to find out how robust it is Mar 10 00:17:43 what kind of drivers? Mar 10 00:42:23 Probably motor driver chips Mar 10 00:43:22 yes, motor drivers Mar 10 00:46:49 you'd expect those to be somewhat robust indeed, though with effort you can break anything... and motors are glad to give a helping hand Mar 10 00:47:03 this is fucking awesome -> https://www.reddit.com/r/retrobattlestations/comments/5yafgs/intel_386_test_chip_named_pronto_1_eng_fucking/ Mar 10 00:48:02 a disconnect at the wrong time can zap them quickly Mar 10 00:48:28 a commonly found warning for stepper drivers is to not disconnect while energized... I've fried them by doing exactly that Mar 10 00:49:47 hmm... current is interrupted, voltage flies up until it can spark the gap? Mar 10 01:55:57 Hello, new here. I have a BBB and getting fsck errors: Mar 10 01:56:02 fsck: error 2 (No such file or directory) while executing fsck.ext4 for /dev/mmcblk1p1 Mar 10 01:56:07 fsck exited with status code 8 Mar 10 01:56:35 should I ditch this device? I also have a BBG and it does not have any problems. Mar 10 01:58:40 that looks more like a weird software problen Mar 10 01:58:43 *problem Mar 10 01:59:16 note that it reports fsck on /dev/mmcblk1p1 failed because /dev/mmcblk1p1 didn't *exist*, not because of any problem with the filesystem on it Mar 10 02:00:10 can you pastebin the kernel log? Mar 10 02:00:20 yep Mar 10 02:01:30 :D Mar 10 02:02:31 ds2: how much are you into ddr3 leveling? :P Mar 10 02:06:09 ddr3 leveling? Mar 10 02:06:33 sorry, i think my sd card was messed up. I got same problem booting from the card and tried a different card with no issues. Going to re-flash the eMMC with the good card Mar 10 02:08:31 ds2: ah I figured you a person who might have had to deal with that (e.g. bringup of new boards with a TI SoC, most of which require software leveling) Mar 10 02:10:10 zmatt: but why level DDR3? Mar 10 02:10:22 that is RAM... RAM cells don't really wear out quickly Mar 10 02:10:40 lol, that's not what leveling refers to in the context in ram Mar 10 02:11:22 leveling is the timing adjustment done per bytelane to compensate for board layout Mar 10 02:11:58 :P never called it that Mar 10 02:12:06 jedec calls it that Mar 10 02:12:07 but I do deal with that Mar 10 02:12:16 and every other document I've ever seen Mar 10 02:12:28 <--- doesn't always use proper terminology Mar 10 02:12:40 every discipline has their own Mar 10 02:13:01 yeah but it's difficult to avoid the proper term while reading documentation :P Mar 10 02:15:02 TI is using full hw leveling in u-boot on the omap5, they're even enabling incremental leveling even though the TRM claims it's "not supported on this device", albeit they do something funny while enabling it with a vague comment indicating it's an errata workaround Mar 10 02:16:36 the Pyra prototype I have frequently crashed on its way to u-boot, and I've discovered that hw leveling seems to be failing spectacularly Mar 10 02:16:47 https://gist.github.com/mvduin/2681a4c2684754d563be045672cae773#file-note-txt Mar 10 02:17:11 heheh... sounds like another bug on the EMIF stuff Mar 10 02:17:25 it's probably still the same bug Mar 10 02:17:32 but, on uEVM leveling always seems to succeed Mar 10 02:17:44 it was on the AM35x stuff, IIRC Mar 10 02:17:47 so presumably there's a hardware contribution too Mar 10 02:18:30 afaik every ddr3 phy they've produced so far had buggy hardware leveling, except for the one in the latest Keystones apparently Mar 10 02:19:25 keystones don't use the EMIF? Mar 10 02:19:46 EMIF actually comes originally from TI DSPs Mar 10 02:19:56 afaik Mar 10 02:20:17 EMIF isn't the ddr3 phy though Mar 10 02:22:33 EMIF itself just does command scheduling and that sort of stuff, it's coupled to a phy to do the low-level stuff Mar 10 02:23:42 from SW, that's the part that gets programmed Mar 10 02:24:41 you program both... the phy is easy to recognize, it's the part that has a gratuitously different register interface in every damn SoC they make !@# Mar 10 02:24:57 oh and on the am335x they accidently made its registers write-only Mar 10 02:26:10 sometimes they're in the control module, sometimes they're in a subregion of emif's register space, sometimes they're a separate module hanging off some L4 interconnect Mar 10 02:26:47 too often the fields are bit-packed together, because everyone knows how convenient a packed array of 11-bit integers is -.- Mar 10 02:28:05 :) Mar 10 02:28:20 it is just a bunch of bits to the FPGA guys... Mar 10 02:28:30 yeah I know Mar 10 02:29:02 I really wish they would have those guys share an office with driver devs for a while Mar 10 02:35:48 heh I just noticed that one the run which got misleveled, two bytelanes got delayed by a full cycle Mar 10 02:36:35 but only on one rank Mar 10 02:36:38 write data ratios: 17a 6c 17a 78 74 6b 6d 76 Mar 10 02:36:38 write dqs ratios: 15a 4c 15a 58 54 4b 4d 56 Mar 10 02:39:31 I'm guessing as a consequence of Mar 10 02:39:36 read dqs ratios: 7f 41 7f 3b 40 44 39 3a Mar 10 02:41:17 then you would need to get security and HR in the same building.... Mar 10 02:43:26 I wonder if for evms they use dies from a particularly favorable process corner or something Mar 10 02:50:34 or maybe it is just a different batch... early stuff work... "cost reduced" ones don't Mar 10 02:52:12 I very much doubt that with the omap5 Mar 10 02:52:33 I was thinking about process corner since I noticed all its DLLs lock at noticably higher values than on the pyra Mar 10 02:52:47 suggesting slightly lower gate delay time Mar 10 02:55:31 are they the same ES silicon? Mar 10 02:55:56 yeah Mar 10 02:56:33 maybe it is from a different part of the wafer? Mar 10 02:56:51 that's what I just said Mar 10 02:57:30 you suggested they cherry picked it... I am suggesting you got it by shear luck Mar 10 02:58:13 well, to be precise, you didn't say either :P Mar 10 02:58:25 :) Mar 10 02:58:33 and yeah I got one sample of each dataset right now, not very useful for drawing conclusions ;) **** ENDING LOGGING AT Fri Mar 10 03:00:03 2017