**** BEGIN LOGGING AT Thu Dec 13 03:00:02 2018 Dec 13 04:21:29 ergh Dec 13 04:21:34 I seem to have lost SGX once again... Dec 13 04:21:56 I don't suppose any part of getting 3d with SGX has gotten easier in the last year or so? Dec 13 04:25:51 I should really find the type to make an easy procedure for it (e.g. debian packages) Dec 13 04:25:55 *find the time Dec 13 04:26:17 "lost SGX once again" .. what do you mean lost? Dec 13 04:27:31 lol Dec 13 04:27:40 I believe last time I was here you gave me a package Dec 13 04:27:50 sgx-ti335x-userspace Dec 13 04:28:18 https://liktaanjeneus.nl/sgx/ Dec 13 04:28:18 I took it apart, browsed what was there, repacked it and used it for a while Dec 13 04:28:25 ah Dec 13 04:28:47 by "lost" I really mean that now I'm trying to build a fresh image on a newer 4.14-ti kernel and Ubuntu 18.04 instead of 16.04 Dec 13 04:28:49 why did you need to repack it? Dec 13 04:29:21 IIRC I ended up tweaking the dependency and conflict list based on my initial work to get 18.04 to work Dec 13 04:29:30 ah Dec 13 04:29:46 hrmm Dec 13 04:30:19 anyway, in case you lost the urls, these are the patches: https://github.com/dutchanddutch/bb-kernel/tree/am33x-v4.14/patches/drivers/ti/sgx Dec 13 04:30:53 kk - I'll start hacking on this and see if I can at least figure out what's actually keeping it from working Dec 13 04:31:12 also, am I recalling correctly that the packages libegl1-sgx-omap3 libgles2-sgx-omap3 opengles-sgx-omap3 are ancient and will lead to sadness and depression? Dec 13 04:31:52 and this is my repo for the kernel module, including build script I used (which contains hardcoded paths and require tweaking): https://github.com/mvduin/omap5-sgx-ddk-linux this repo hasn't been synced with upstream in a long time though Dec 13 04:32:18 no idea, but I'm assuming you have a beaglebone and not an omap3 Dec 13 04:34:09 brb Dec 13 04:38:08 is there a better low-level test than running gles2test1? Dec 13 04:41:27 # pvrsrvctl --dump-debug Dec 13 04:41:27 PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ] Dec 13 04:41:27 PVR:(Error): PVRSRVConnect: Unable to open connection. [0, ] Dec 13 04:41:27 pvrsrvctl: PVRSRVConnect failed (err=4) Dec 13 04:41:53 but pvrsrvkm is loaded and I don't see anything alarming in dmesg... Dec 13 04:46:48 interesting Dec 13 04:46:49 has it also been initialized using pvrsrvctl ? (iirc my userspace package had a systemd service for it) Dec 13 04:47:11 `pvrsrvctl --start --no-module` fails with similar errors Dec 13 04:47:53 I have a working image with 16.04 and kernel 4.14.50-ti-r56 sitting next to the broken image with 18.04 and kernel 4.14.67-ti-r74 Dec 13 04:48:23 and the immediately obvious thing is that the old image prints `[drm] Initialized pvr 1.14.3699939 20110701 for 56000000.sgx on minor 2` when loading pvrsrvkm Dec 13 04:48:30 but the new image doesn't ever print anything Dec 13 04:48:41 what's in /dev/dri ? Dec 13 04:48:43 I... think that might point to an overlay issue? Dec 13 04:48:48 yeah could be Dec 13 04:49:08 there should be two "cards" in /dev/dri, one for lcdc and one for sgx Dec 13 04:49:14 lol Dec 13 04:49:23 old image has 3 cards Dec 13 04:49:29 new image has 2 Dec 13 04:49:43 but they actually diverge more than that: Dec 13 04:49:48 # find /dev/dri Dec 13 04:49:53 3 ? what? Dec 13 04:50:15 ergh, you'd think IRC would have a sane multiline hack by now Dec 13 04:50:27 pastebin :P Dec 13 04:50:29 old image has card0, card1, card2, sgx, renderD128 Dec 13 04:50:45 where did it get a third card? vgem maybe? Dec 13 04:50:51 new image has card0, card1, by-path/platform-4830e000.lcdc-card Dec 13 04:51:01 the sgx symlink is a custom udev rule Dec 13 04:51:28 yea, looks like sgx -> renderD128 Dec 13 04:52:33 https://pastebin.com/raw/A9qdXYEb this is what I have Dec 13 04:52:39 yea, looks like it's an overlay issue Dec 13 04:52:55 old image also has /sys/devices/platform/ocp/56000000.sgx but new image does not Dec 13 04:53:11 overlay? normally it's enabled in the base dts I think Dec 13 04:53:28 ... yea, there's something weird there Dec 13 04:53:39 well you're using ubuntu so :P Dec 13 04:53:43 I do have a /sys/firmware/devicetree/base/ocp/sgx@56000000 Dec 13 04:54:01 does it have a 'status' property that's set to disabled? :P Dec 13 04:54:22 lol yes Dec 13 04:54:54 so how'd that happen... Dec 13 04:58:05 signs point to rcn-ee[m] Dec 13 04:59:57 actually, that device doesn't seem to be defined in any of the device trees in RCN's repo Dec 13 05:00:04 wat Dec 13 05:00:11 so where does it come from then... Dec 13 05:01:39 https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am33xx.dtsi#L1299-L1307 Dec 13 05:01:56 https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-boneblack-uboot.dts#L18-L20 Dec 13 05:02:29 well that's awkward Dec 13 05:02:38 so U-Boot must be loading the wrong overlays? Dec 13 05:03:25 are you using overlays? Dec 13 05:03:39 I am Dec 13 05:03:42 I mean, if you're using u-boot overlays then yes you would be, but I don't know if you are Dec 13 05:03:45 ok Dec 13 05:04:05 well what I just showed confirms what I said earlier: it's enabled in the base dts, not in an overlay Dec 13 05:04:31 so my guess would be your base dts doesn't have it Dec 13 05:04:31 aye, although I believe U-Boot is still responsible for loading the base if it's enabled? Dec 13 05:04:47 ehm, without the base dts you don't have a bootable system Dec 13 05:05:22 I understand that Dec 13 05:06:06 but as I understand the process, U-Boot is loading the base DTB into memory, loading and applying overlays to it according to the detected capes and uEnv.txt, then loading the kernel and passing the address of the DTB into it? Dec 13 05:06:20 anyway, if you want to know exactly which base dtb and overlay dtbos are being used, you'll need to check u-boot's console output Dec 13 05:06:31 I'm doing that now :) Dec 13 05:06:31 basically yes Dec 13 05:09:37 interesting - it looks like I'm getting am335x-boneblack-uboot-univ.dtb instead of am335x-boneblack-uboot.dtb Dec 13 05:09:46 and the univ tree doesn't enable SGX Dec 13 05:09:56 huh it doesn't? but why Dec 13 05:10:34 https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-boneblack-uboot-univ.dts Dec 13 05:10:36 dunno Dec 13 05:10:54 for now I'm going to overwrite -univ with the base one and see if that resolves the issue Dec 13 05:11:10 if it does, I guess I'll file a bug and ask RCN what he thinks about it Dec 13 05:11:10 that sounds like a bad idea Dec 13 05:11:20 please just add the sgx declaration to the univ one and recompile Dec 13 05:11:33 (in dtb-rebuilder) Dec 13 05:11:42 lol Dec 13 05:11:49 that's less fun, though :D Dec 13 05:12:05 are you using the universal overlay? Dec 13 05:12:44 to be honest I don't really understand why the universal overlay also has a different base dts instead of putting the differences in... you know... the universal overlay Dec 13 05:12:54 I was, but now I've turned it off and it doesn't seem to change anything Dec 13 05:13:16 yeah that's another thing I noticed, that it uses the -univ variant regardless Dec 13 05:13:26 iirc that depends on the exact u-boot version you have though Dec 13 05:13:42 yea, I'm wondering if that's actually the bug here Dec 13 05:14:10 regardless, it does seem like a bug to me that the sgx-enabling fragment is missing from am335x-boneblack-uboot-univ.dts Dec 13 05:22:57 lol Dec 13 05:23:11 after the edit and recompile, I have no rootfs Dec 13 05:25:00 eh what? Dec 13 05:25:06 what did you do exactly? Dec 13 05:25:26 added sgx to am335x-boneblack-uboot-univ.dts and did a make install Dec 13 05:25:48 not really sure what's gone wrong here - there are no obvious errors from U-Boot Dec 13 05:25:50 did you use the right branch? Dec 13 05:26:00 hrmmm Dec 13 05:26:07 that... could be the issue Dec 13 05:26:26 I suspect I probably used master Dec 13 05:26:51 eh, but there's nothing in master... Dec 13 05:27:14 ah well, I'll reflash and try once more Dec 13 05:28:27 4.14-ti is the correct branch if you're using a 4.14-ti series kernel Dec 13 05:40:55 interestingly, 4.14-ti is the default branch Dec 13 05:41:25 so I was definitely on the right branch... Dec 13 05:46:29 copying am335x-boneblack-uboot.dtb to am335x-boneblack-uboot-univ.dtb worked Dec 13 05:46:39 the device is enabled and the driver is responding Dec 13 05:47:17 weird, I wonder what went wrong when you did a recompile and make install Dec 13 06:25:16 I filed https://github.com/RobertCNelson/dtb-rebuilder/issues/32 Dec 13 11:04:00 hey everyone i created a sd card with Debian 9.5 2018-10-07 4GB SD LXQT, i press the boot button to boot from the SD card, my isssue is thati cant log in, i use Putty type in 192.168.7.2 enter username root password root and i get access denied Dec 13 11:04:23 i am using beagle bone black Dec 13 11:04:44 a quick look at the getting-started page or a few minutes of googling would have yielded: username "debian", password "temppwd" Dec 13 11:05:02 btw the "iot" image is recommended for most uses Dec 13 11:05:48 a desktop environment doesn't run very comfortably on a beaglebone, is rarely what people actually need or want, and uses up a lot of space Dec 13 11:06:50 Thanks for the advice.. i tried thatlast night and nothing. but now it work Dec 13 11:07:09 maybe you just made a typo? Dec 13 11:07:30 another question for the group how do i get the beagle bone black to boot from the sd Card without pressing the button? Dec 13 11:07:54 zmatt possibly i tried it a million times.. thank a million Dec 13 11:10:26 it should actually boot from sd card even if you don't use the button, unless the bootloader on eMMC is really ancient. however, even if it boots without the button, not everything may work correctly unless the bootloader on eMMC is the same (or very similar) version as the sd card. if you don't care about the contents of eMMC, the easy solution is to just erase it. then the beaglebone will ... Dec 13 11:10:32 ...automatically use the bootloader on sd card instead (just like it would when using the S2 button) Dec 13 11:10:57 you can erase the eMMC using the command: sudo blkdiscard /dev/mmcblk1 Dec 13 11:16:08 zma thannks for the advice i am new at this, i have to run to work ttyl cheers :) Dec 13 14:47:17 Victory!!! - Thanks zmatt :-D Dec 13 14:47:44 RS485 is active, and RTS is operating as required :D Dec 13 14:49:55 yay Dec 13 14:50:44 Yay indeed! Dec 13 14:52:06 Where would the best place be, to publish the procedure to get it working? - Perhaps someone else is having a hard time? Dec 13 14:54:13 m Dec 13 15:40:42 hello, We replaced the 2G of RAM on our beagleboard x15 with a 4G chip set. When we boot the board it still only recognizes 2G. Can anyone help me figure out how to modify the boot loader to properly initialize the full 4G of RAM? Dec 13 16:03:43 raffo: ehh Dec 13 16:05:28 which memory part did you use? Dec 13 16:07:29 Micron MT41K512M16, the 2G set was Micron MT41K256M16 Dec 13 16:11:48 that was a mistake, that's a dual-rank device which is not supported Dec 13 16:12:45 basically it's two MT41K256M16 dies in a single package Dec 13 16:15:30 unless the rest of the part number is important for making the distinction Dec 13 16:16:27 it actually is! Dec 13 16:16:55 MT41K512M16HA is a single-rank, MT41K512M16TNA is dual-rank Dec 13 16:17:35 (today we learn: don't abbreviate part numbers :P ) Dec 13 16:24:36 and according to the schematic A15 is wired (even though it's not used in the ram configuration used on the bbx15), so that's fortunate ;) Dec 13 16:25:46 so yeah, then it should be a simple matter of bumping number of rowbits from 15 to 16 and increasing tRFC from 260 to 350 Dec 13 16:27:14 unfortunately those are buried in an array of hex values... quite annoying Dec 13 16:28:00 see the beagle_x15_*_emif_regs structs in board/ti/am57xx/board.c Dec 13 16:28:49 oh and probably the lisa map (directly above it in that file) will need a change too Dec 13 16:29:43 I'll look those values up in a bit, need to do a thing first Dec 13 17:23:45 zmatt: Thank you. We're looking at those files and trying to figure out how to modify those registers. Any help is welcome. Dec 13 17:55:03 we're using the MT41K512M16HA Dec 13 18:13:12 raffo: changing the sdram_config and sdram_config_init from 0x61851b32 to 0x61851bb2 will configure 16 row bits Dec 13 18:16:44 changing sdram_tim3 from 0x407f88a8 to 0x407f8ba8 will increase tRFC from 260ns to 350ns Dec 13 18:20:13 the lisa map is probably fine actually since it only covers 2GB anyway Dec 13 18:20:34 the total memory size still needs to be considered somewhere though... hmm Dec 13 18:34:09 trying now... Dec 13 18:41:42 there are two emif_regs structures. In the first, sdram_tim3 is 0x409f88a8, in the second it is 0x407f88a8. Note the third digit difference. I made the change so both end with 8ba8. The board boots, and it still only reports 2 GB. Dec 13 18:42:34 yes like I said, the total memory size still needs to be declared somewhere I'd assume, but I'm not sure where and I'm a bit too distracted to dig through u-boot right now Dec 13 18:43:18 it's also possible u-boot will report 2GB regardless since it can probably only use 2GB... not sure Dec 13 18:43:35 or maybe u-boot also had an LPAE option? it's been a while since I was doing stuff with this Dec 13 18:44:21 note that you'll need an LPAE kernel (CONFIG_ARM_LPAE=y) to be able to use more than 2 GB Dec 13 18:48:07 We'll continue to investigate. I'm booting the OS image put out by Robert Nelson and the kernel does not have LPAE enabled. I'll recompile kernel and keep testing. Thank you for your help. Dec 13 18:48:55 correct, since rcn's -ti kernels are meant for both beaglebone and beagleboard-x15 Dec 13 18:49:02 and probably older beagleboards too Dec 13 18:50:26 the x15 doesn't need LPAE (since it only has 2GB ram) and the beaglebone and older boards do not support LPAE, which that an LPAE kernel will not boot on them Dec 13 18:50:35 *which means that Dec 13 18:57:38 now if I could find where in the config menu the option is..... Dec 13 18:59:53 found it! Dec 13 19:01:26 I'm not sure if we need LPAE though, since we're not going over the 4GB limit. Dec 13 19:01:39 without LPAE the limit is 2GB Dec 13 19:02:29 or rather, without LPAE the cortex-a8 only has a 4GB address space, the upper half of which is for external ram Dec 13 19:02:35 the cortex-a15 sorry Dec 13 19:03:42 the lower half is for other stuff like peripherals, internal memories, the TILER address space, etc Dec 13 19:06:15 OK, the kernel config help page mentions only 4G. I'm compiling the kernel now. I'll give it a try once it finishes. Dec 13 19:08:28 There is a memory section in the device tree loaded by the kernel that specifies the RAM size. If this kernel boots, I'll tweak with that parameter. Dec 13 19:09:12 yeah it needs to declare two ranges. normally u-boot fills in that part of the DT though Dec 13 19:09:26 I think whatever you put there manually will end up being overridden Dec 13 19:12:37 it is possible to override it using a kernel parameter, for testing purposes until u-boot understands the correct memory size itself: mem=2032M@0x80000000 mem=2048M@0x300000000 Dec 13 19:17:00 The size is defined in arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi Dec 13 19:17:15 no, like I said that gets overwritten by u-boot Dec 13 19:17:24 I don't know why they even bother putting a declaration in the dts Dec 13 19:17:28 The compilation just finished. Let me install it in the uSD card and give it a whirl. Dec 13 19:17:55 at least, it worked like that last time I worked with this stuff in u-boot Dec 13 19:18:09 maybe it's different now, who knows Dec 13 19:22:58 this is so ugly... the DT uses 64-bit addressing, but writes them using 32-bit integers (e.g.: reg = <0x0 0x95800000 0x0 0x3800000>;) instead of using 64-bit integers (reg = /bits/ 64 <0x95800000 0x3800000>;) Dec 13 19:23:08 yuck Dec 13 19:29:42 It worked! it reports 3724860 bytes or RAM. Dec 13 19:30:27 yeah it looks like it actually won't overwrite a /memory declaration in DT if one exists... I wonder if that changed or if I just remember it wrong Dec 13 19:31:05 what change did you make to the DT exactly? Dec 13 19:35:01 The DT from the kernel sources, no changes. Dec 13 19:35:24 oh, you used my kernel parameter suggestion instead? Dec 13 19:36:55 Yes. I'm not sure what the syntax of the config would be of the parameters you listed above. Dec 13 19:38:18 yeah me neither, I'd need to dig it up. also, I just noticed that mem=2048M@0x300000000 is a bit weird, it should technically be at address 0x200000000 Dec 13 19:38:27 though 0x300000000 works too in practice due to aliasing Dec 13 19:43:48 I just had a "Unable to handle kernel paging request at virtual address ba578000" Dec 13 19:47:04 It'll boot with 0x20000000. Dec 13 19:47:07 so not all is well :) Dec 13 19:47:10 shouldn't matter Dec 13 19:48:24 there's probably something else wrong, but I can't really guess what. just because it shows you have 4GB of ram doesn't mean it works, that's something you discover when you actually try to use the memory Dec 13 19:51:18 yeah, I'll need to test. Dec 13 19:59:39 could explain what these particular numbers were chosen? mem=2032M@0x80000000 mem=2048M@0x200000000 Dec 13 20:02:02 the first is the lower 2GB (minus 16M usually reserved for a dummy mapping for DMM) located in the upper half of the 4GB address space, the second one is the upper 2GB located in the extended address space of the cortex-a15 Dec 13 20:02:40 see also a more detailed explanation I wrote in this post: https://e2e.ti.com/support/processors/f/791/p/741967/2739843#2739843 Dec 13 20:04:17 (highmem interleaving is enabled by u-boot btw, I noticed this in the code) Dec 13 20:54:43 if that is the purpose of the flag is_ma_present in the board.c file, then it looks like the memory adapter MA_HIMEM_INTERLEAVE_UN_MASK is set. Dec 13 21:20:40 is_ma_present must always be true on am57xx Dec 13 21:25:17 and arch/arm/mach-omap2/emif-common.c always enables himem interleave... the use-case for non-interleaved himem seems pretty obscure to me anyway Dec 13 21:28:24 yes, I found that grepping around. Dec 13 21:32:29 interesting, board/ti/dra7xx/evm.c does configure the ram bank info: https://elixir.bootlin.com/u-boot/latest/source/board/ti/dra7xx/evm.c#L633 Dec 13 21:33:03 and on am335x there's https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-omap2/am33xx/board.c#L42 Dec 13 21:34:05 and it kinda has to be setup correctly somewhere for things like this to work: https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-omap2/omap-cache.c#L54 Dec 13 21:35:20 but I'm not sure where. also, this looks like it would horribly blow up if himem is being declared Dec 13 21:35:24 *confused* Dec 13 21:36:26 btw I just remembered u-boot also has an LPAE config flag... I don't remember quite what its impact is though, or why u-boot would need it Dec 13 21:36:46 oh yeah, it needs it if you want to boot the cpu in HYP mode to support hardware VMs Dec 13 22:19:18 doesn't look like am57xx board code is doing this kind of initialization. Like what dram_init_banksize() is doing for the dra7xx board. Dec 13 22:22:17 I'm running "memtester 3000" on my board. So far so good. Dec 13 22:22:49 I'm heading out now. Thank you very much zmatt, your help is appreciated. **** ENDING LOGGING AT Fri Dec 14 03:00:01 2018