**** BEGIN LOGGING AT Fri May 24 03:00:35 2019 May 24 13:22:01 hi - I have a prototype product I've been working on using an older Debian base (jessie) and a 10,1" screen over HDMI. I'm tryint to piece together and deliver my first finished proudct and I've found that the Jessie apt repo's seems to be gone now, so I moved to a newer Debian Version (9, 2018-06-17) and I notice some changes. most notably, I can't get the 10.1" screen to work anymore (but a 5" screen I have DOES work) May 24 13:22:39 wiki pages for display resolutions seem to be tailored to an older graphics system. can someone point me toward what the new grpahics system is so I can make sure that a supported screen resolution is available? May 24 13:53:42 greenlava: odd, hdmi screens should Just Work May 24 13:54:21 not sure what you mean by "graphics system" May 24 13:55:40 if the hdmi screen has wrong EDID information then you can try forcing the resolution in /boot/uEnv.txt (by adding an appropriate "video" parameter to the "cmdline" variable. there should be an example for that in the comments in that file) May 24 14:36:42 @zmatt thanks, I'll head down that road for a bit. appreciate the help May 24 14:44:41 @matt, that was the answer - had to lock it into 1280x800 30hz, all is well now. thanks a ton for the help May 24 14:48:29 :) May 24 17:15:32 hi, I am trying to compile u-boot for beaglebone black. there are two configuration file in the config directory i.e. am335x_boneblack_vboot_defconfig and am335x_evm_defconfig. Which one i should use and whats the difference? May 24 17:16:07 There is no documentation stating the difference. any reference in this regard will be highly helpful as well. May 24 17:16:45 am335x_boneblack_defconfig May 24 17:17:24 what the difference dear @zmatt? May 24 17:18:53 this tutorial (https://longervision.github.io/2018/01/10/Embedded/beaglebone-black-uboot-kernel/) uses the other config file i.e. am335x_evm_defconfig without mentioning the reason. May 24 17:19:11 no idea, but if you want to reproduce an u-boot that behaves like the one in the official images, you need rcn's patches and am335x_boneblack_defconfig May 24 17:19:42 Ok dear. May 24 17:20:00 can you please stop calling me "dear", I'm not your wife May 24 17:21:25 ok sorry. May 24 17:29:46 ohh. the evm is actually different board not the beaglebone black one. Link: http://www.ti.com/tool/TMDXEVM3358 May 24 17:29:59 yeah but the same u-boot can support both boards May 24 17:30:31 so the _evm config file will no doubt result in an u-boot that can run on the beaglebone, the difference will be in how u-boot is configured May 24 17:31:15 as for what the difference is, I'd suggest just inspecting the defconfig files (in the "configs" dir) May 24 17:32:31 yup. passed both file via file-difference-online. There are few switches/CONFIG difference. May 24 17:32:42 will decode it for possible difference May 24 20:49:48 the u-boot maintainers, ripped out those extra configs.. no am335x_boneblack_vboot_defconfig/am335x_boneblack_defconfig/etc anymore... So users should just use am335x_evm_defconfig May 24 20:50:16 which should work on all am335x based boards with an eeprom following ti/beagleboard's specs.. May 24 20:52:13 rcn-ee[m]: i half meant to propose re-adding them... May 24 20:52:36 but then i figured may as well move to the future May 24 20:53:11 rcn-ee[m]: there are some recent patches in u-boot to make it possible to compress the .dtb files ... not sure what speed impact it would have on the am335x May 24 20:53:27 but it would certainly shrink them considerably May 24 20:56:36 vagrantc: even if we brought that config back, that path is getting ripped out slowly thou, https://github.com/u-boot/u-boot/commit/55f8b70fee856f7fc2ccf452e3533814e98a1ac6#diff-388bd17253d807cb1096cb6d3661bb2d May 24 20:58:30 PS, jason and i have a crazy idea to extend SPL -> u-boot.img into a AM3/AM5 (SPL0) -> (SPL) -> u-boot.img... are you up for it? May 24 21:00:02 I'm definitely still tempted to make my own small&fast bootloader for am335x... am5 is a different beast though May 24 21:03:39 rcn-ee[m]: what would be the goal? May 24 21:04:06 one image for am3 and am5 devices May 24 21:04:33 I don't see any theoretical obstacle May 24 21:05:03 if cortexa-a15 jump this load address, else jump to this load address.. May 24 21:05:07 using e.g. cpuid to dispatch down the right patch May 24 21:05:09 *path May 24 21:05:13 yeah, that May 24 21:05:39 then just use the existing spl/u-boot.img (maybe spl-am3/spl-am5) so it loads the right path.. May 24 21:05:46 then just use the existing spl/u-boot.img (maybe spl-am3/spl-am5) so it loads the right path..file May 24 21:07:40 rcn-ee[m]: sounds great! May 24 21:09:01 rcn-ee[m]: although i'm guessing then we'd have even more device-trees and an even larger image... the 4MB partition start might not be enough! May 24 21:09:38 i noticed adding just one board to am57xx_evm grew the u-boot.img by ~300k May 24 21:09:53 what is this insanity /o\ May 24 21:10:07 * vagrantc joins in the /o\ May 24 21:10:37 yeah, so to make this work well, we'd have to drop the raw boot.. The initial am3 or am5 could be in raw microsd.. But then the spl/u-boot files will have to be in fat.... Otherwise the wrong SPL in raw would do some interesting things on bootup.. May 24 21:10:38 I could understand using the dts to build a board information data structure (at u-boot compile time) May 24 21:10:54 but including the dtbs verbatim and doing driver-matching at runtime... wtf May 24 21:12:06 again, they compress really well, so exploring that route might significantly buy time May 24 21:12:31 i recall in an earlier conversation zmatt suggesting moving the offset so there's more room, too. May 24 21:12:44 I did? May 24 21:13:16 i think now it's at 768, and it could probably be moved to 512 May 24 21:13:17 some u-boot targets cut up the dtb's, so they aren't a full copy.. i think on the am5 target that hasn't been fully setup.... May 24 21:14:49 on am335x SPL definitely doesn't require more than 256 sectors, since it wouldn't fit in internal sram if it did May 24 21:17:30 although using the same offsets for everything might make this harder https://fosdem.org/2019/schedule/event/one_image_to_rule_them_all/ **** ENDING LOGGING AT Sat May 25 02:59:58 2019