**** BEGIN LOGGING AT Mon Jul 22 03:02:02 2019 Jul 22 03:56:38 seanboult : I don't own a gamepup cape , but I have used some similar displays via the Mikrobus slot on the Techlab cape, that overlay contains entries for the LCD display too, if it's not working can you try it via https://github.com/notro/fbtft/wiki/fbtft_device , the same display is supported I believe: Jul 22 03:56:39 https://github.com/beagleboard/linux/blob/f45281297c419d29df9bedbb9d1eaeb12fd2b93b/drivers/staging/fbtft/fbtft_device.c#L276 Jul 22 12:25:24 * KotH stabs alan_o with a piece of dark chocolate Jul 22 12:25:50 hey Jul 22 12:26:03 how's it going? Jul 22 12:27:38 * LetoThe2nd metalizes KotH Jul 22 12:31:36 LetoThe2nd: i hope it's gold... chocolate with gold is delicious! Jul 22 12:31:52 alan_o: not too bad... doing some mathy things... Jul 22 12:32:09 KotH: usually i just use COTS lead bricks. Jul 22 12:38:59 Is access slack only for the committee members :P? Jul 22 12:39:07 slack access* Jul 22 12:41:43 LetoThe2nd: bäh! Jul 22 14:23:32 m Jul 22 18:37:22 Not sure if this is the right place to ask, the board that I designed using BBB as reference could not boot, is this where I can ask for advice? Jul 22 18:41:31 @jas Jul 22 18:41:52 JasperJia: did you install the eeprom? blank, or did you program it? Jul 22 18:42:04 did you use ddr3 with the same tps? Jul 22 18:51:52 here's the issue long description @rcn-ee[m] Jul 22 18:52:33 I have a BeagleBoneBlack board with Sitara AM3358 SoC. I buit u-boot and kernel, and they runs well from SD card or eMMC flash. But the SD card cannot boot our board. Our board uses TI Sitara AM3352 SoC. Jul 22 18:52:34 lem? Jul 22 18:52:34 output. Jul 22 18:52:37 not in our board). Jul 22 18:52:40 Jul 22 18:53:36 Well, the AM3352 is a slower variant of the AM3358, u-boot won't care, but our kernel does, as we force 1Ghz, which the AM3352 isn't efused to do.. Jul 22 18:54:38 Either way, does your AM3352 based board, have an eeprom, does it run ddr3, and does it have the same TPS as teh BBB? If you answer Yes, i do have something for you try, if you say No, then the image won't boot.. Jul 22 18:55:56 crap, u-boot does try to enable the 1Ghz OPP point... So while you may say Yes to above, it may have other issues in u-boot.. Jul 22 18:59:08 you are right I may say yes to those questions, (sorry my partner who can confirm this is now sleeping due to time diff), so what can I try? Jul 22 19:00:11 sorry, till you confirm those 3 things, i can't help.. this special builds on u-boot is used to bring up our blank-eeprom builds.. If booted on differnet hardware bad things can happen.. Jul 22 19:14:58 i will confirm the answers with my partner and likely come back, thanks rcn-ee[m] Jul 22 19:16:18 sounds good, if i'm not online, just send me an email: https://github.com/RobertCNelson Jul 22 19:28:10 noted with thanks rcn-ee[m] Jul 22 21:26:56 rcn-ee[m]: officially the memory should also be releveled anyway, unless that part has been copy-pasted 100% identically from the BBB (including all trace lengths) Jul 22 21:27:29 but I feel like that step is neglected every now and then anyway Jul 22 21:32:50 zmatt, i'm more worried about ddr2 vs ddr3 voltages. ;) Jul 22 21:34:23 yeah the bbb is pretty weird with that... using the wrong TPS65217 variant and then correcting the settings in u-boot, instead of just using the TPS65217 variant with correct defaults to begin with (C for DDR3, D for DDR3L) Jul 22 21:34:27 looks in u-boot, i sware the white was ddr2, nope, it's not.. okay loosing mind.. Jul 22 21:34:38 white was ddr2 yeah iirc Jul 22 21:34:46 it used the TPS65217B Jul 22 21:35:09 duh it's here: https://github.com/u-boot/u-boot/blob/master/board/ti/am335x/board.c#L574 Jul 22 21:35:25 double brain fart.. ;) Jul 22 21:35:50 though it shouldn't need to be messing with voltages on the white since it uses the correct TPS6217 part Jul 22 21:36:42 yeah, we tried fixing TP65217 to the correct voltage, but then TI came back and claimed: in the transtion between u-boot and the kernel, and the kernel dtb lowers that voltage there is a chance of memory instability.. Since the kernel doesn't re-train the ddr, it's not a good idea to re-volt it.. Jul 22 21:37:08 ... which is why you should use the correct part Jul 22 21:37:16 regardless, the kernel isn't revolting it Jul 22 21:37:30 u-boot does so while the DDR3 memory is held in reset Jul 22 21:38:38 a more interesting question is whether the training data was obtained while operating at the correct voltage Jul 22 21:39:06 if not, then the BBB itself is yet another example of a board which failed to retrain for their exact memory setup :P Jul 22 21:40:25 This is the biggest if, for his am3352 that i'm worried about: https://github.com/u-boot/u-boot/blob/master/board/ti/am335x/board.c#L300 Jul 22 21:40:49 yeah that'll be bad Jul 22 21:41:06 and these voltage settings: https://github.com/u-boot/u-boot/blob/master/board/ti/am335x/board.c#L352 Jul 22 21:41:59 actually am3358 vs am3352 doesn't matter Jul 22 21:42:15 in my blank eeprom those get set to true, which will override his AM3352... Jul 22 21:42:19 what matters is whether it's an AM335x-100 or lower rated Jul 22 21:42:24 Here we go: everything after: https://github.com/u-boot/u-boot/blob/master/board/ti/am335x/board.c#L478 is unknown.. Jul 22 21:42:55 (it's probally the same part just efused now days..) Jul 22 21:43:35 doesnt't seem like a good idea to override efuse anymore in your "blank" u-boot, since that was applicable only to some very old parts Jul 22 21:43:58 would TI be still binning broken die 8 years after launch? Jul 22 21:44:19 no? I think the binning issue was only in some early prototypes? Jul 22 21:44:25 Well, all the Octavo parts, don't have a correct efuse (it's blank..) Jul 22 21:44:34 oh yeah, those morons Jul 22 21:45:05 well I guess if the efuse is blank you'll have to warn loudly and fall back to some defaults Jul 22 21:45:11 * rcn-ee[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/REFGTJFzTtNFJULBEaGVckTc > Jul 22 21:45:12 has octavo still not fixed this issue? Jul 22 21:46:24 So i got a new Seeed Green proto with the Octavo chip, i should check to see if that got fixed, as it's teh latest batch.. Jul 22 21:46:35 does octavo even have any lower-binned devices? Jul 22 21:47:32 as long as they offer only a single bin, then it'll make sense to detect this situation (rev 2.1 with blank EFUSE_SMA) and assume it's that specific bin Jul 22 21:47:55 (after complaining about Octavo's idiocy on stderr) Jul 22 21:48:14 They don't bother with that, just RAM and package.. They did want to try doing an overclocked varient at one time. Jul 22 21:48:42 once they have multiple bins, they'd better program that information into efuse Jul 22 21:49:23 (in a format that's compatible with TI's programming of that register) Jul 22 21:50:31 so if TI hasn't binned these dies before shipping them to Octavo, is Octavo expected to do the appropriate testing to ensure they will run properly in the desired bin? are they doing so? :P Jul 22 21:53:08 it still seems a bit weird to me that TI isn't doing the testing/binning for these dies, they seem like the only appropriate party to be doing that Jul 22 21:54:22 and having correct binning data in efuse seem pretty much like the only way to have some hope of preventing accidental overclocking/overvolting, since people are just plain sloppy Jul 22 21:55:38 it's also so easy to override in u-boot/kernel. seems like a marketing decision, let's artificially segment this product market.. Jul 22 21:56:35 well it was made to be overridden due to fuckups in the past Jul 22 21:56:42 notably by octavo :P Jul 22 21:56:53 but also by TI earlier Jul 22 21:57:18 oh before that TI, messed it up.. let's ship a few thousand boards, and then implement this efuse idea.. Jul 22 21:57:40 as for whether it's artificial or not I have no idea, determining that would require doing testing to see how low-binned parts hold up under overclocking Jul 22 22:50:16 seriously the efuse is not implemented correctly on the octavio parts? how does the pocket beagle SW handle that? Jul 22 22:50:32 hardcoded assumptions Jul 22 22:50:52 assumption = ass of you and me (sigh) Jul 22 22:51:55 Well I was hopping for less stress with the octavio part because it handles a lot of the board crap I wouldn't want to mess with. I guess nothing is perfect... **** ENDING LOGGING AT Tue Jul 23 02:59:57 2019