**** BEGIN LOGGING AT Wed Jan 30 02:59:57 2019 Jan 30 08:22:52 Hi all! Jan 30 08:23:36 I have a BeagleBone Black with an LCD cape (4D Systems BBB 4DCape Adaptor), which I want to run using Buildroot. Jan 30 08:24:34 The problem is that Buildroot does not seem to support device tree overlays well. Jan 30 08:25:21 I intend to run the BeagleBone Black always with the same cape configuration, so there may be no need for device tree overlays at all. Jan 30 08:27:21 All I want to do is to integrate device tree files like https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-4D4C-01-00A1.dts to form a single device tree Jan 30 08:29:15 The drivers I need (tilcdc, backlight-pwm, etc.) I already built into the kernel. Jan 30 08:29:31 But tilcdc complains in the kernel log: Jan 30 08:29:40 [drm] Cannot find any crtc or sizes Jan 30 08:30:04 So clearly the abovementioned BB-BONE-4D4C-01-00A1.dts is not taken into account. Jan 30 08:30:24 (I integrated these custom .dts files at two places in the Buildroot config: Jan 30 08:31:22 [1] Kernel --> Out-of-tree Device Tree Source file paths, Jan 30 08:33:21 [2] Bootloaders --> U-Boot --> Device Tree source file paths ) Jan 30 08:34:05 Does anyone have an idea on how to integrate such files to a device tree honored by U-Boot and the Linux kernel? Jan 30 08:34:11 Maybe using #include ? Jan 30 09:58:23 hi Jan 30 09:59:00 we are working on beaglebone black ,,,trying to configure CAN1 Jan 30 09:59:26 You are getting our msg? Jan 30 10:00:08 Prabu: the channel can read you, yes. Jan 30 10:00:59 We are not able to transmit the data on CAN1 Jan 30 10:01:28 we are currently using Debian 4.14.17 Jan 30 10:01:51 we have microBus and MCP2542 click board Jan 30 10:03:48 we are using P9.24 and P9.26 for CAN , when we try to configure it in uEnv.txt by cape_enable Jan 30 10:04:00 Prabu: which distribution are you using on the beaglebone black? Jan 30 10:04:13 Prabu: is it the standard debian? Jan 30 10:04:48 we got dmesg error says : failed to load at slot-4 Jan 30 10:06:16 P9.24 and P9.26 pinmux file not found Jan 30 10:07:01 Debian 4.14.17 Jan 30 10:08:34 is it the standard debian? Yes we took from beaglebone ==>Debian 9.5 2018-10-07 4GB SD LXQT Jan 30 10:09:18 Prabu: are you booting from sd card or emmc? Jan 30 10:10:23 first time we booted from sd card and then we followed procedure to wrtite in emmc Jan 30 10:10:36 currently we are running from emmc Jan 30 10:12:21 on current releases in their default config you shouldn't need to meddle with /boot/uEnv.txt at all Jan 30 10:12:43 if you undo whatever you did there, you can configure the pins using "config-pin P9_24 can" and similar for P9_26 Jan 30 10:13:23 we are fine with that ,,,provided how to enable the CAN1 Jan 30 10:13:40 btw unless you really require the lxqt desktop environment, I recommend using the iot image instead of the lxqt image Jan 30 10:14:10 then it will work with screen? Jan 30 10:14:18 i mean iot version? Jan 30 10:14:43 the can interface should exist by default, all you need to do is configure the pins and then bring up the interface as usual Jan 30 10:15:37 we configured using config-pin but couldnt transmit the data Jan 30 10:16:57 that problem description is too vague for me to give any useful feedback Jan 30 10:17:03 after doing config-pin ,we used cangen can1 ,,,but no data on can bus and we didnt see anything on terminal using candump Jan 30 10:17:13 did you bring up the interface? Jan 30 10:17:20 yes Jan 30 10:18:09 we could bring up can using ip link set Jan 30 10:22:20 Is there anything we need to do for pin-mux to route through microBus Jan 30 10:22:44 I have no idea what that is Jan 30 10:24:45 if I understand correctly, just enabling the CAN pin through pin service, is good enough to see the CAN data in the Bus Jan 30 10:25:28 let say we are using PCAN to monitor the CAN traffic Jan 30 10:26:07 could you please clarify Jan 30 10:27:50 as far as I know, you need to configure the pinmux using config-pin and then bring up the interface using ip link. I haven't done anything with can in a long time though Jan 30 10:30:15 ok. we did this exercise. However no positive result. So, had thought of missing anything related to capemgr Jan 30 10:31:07 capemgr isn't used anymore, overlays for capes are handled by u-boot Jan 30 10:31:53 apart from that, pins are typically configured using the universal overlay (i.e. config-pin) Jan 30 10:32:09 ok Jan 30 10:32:37 how about cape_enable ? Jan 30 10:33:39 since capemgr isn't used anymore, all kernel parameters related to it are obsolete Jan 30 10:34:41 As per you ,so we can forget this uEnv.txt ,,,,no modification on this file .... Jan 30 10:35:48 what is the way to check that CAN modules are transmitting data? Jan 30 10:36:30 if you mean you want to try using the BB-CAN1-00A0.dtbo overlay, you can still request it via /boot/uEnv.txt (there are a bunch of variables near the top that let you specify overlays to be loaded) instead of using config-pin, but it shouldn't give a different result. beware however that doing so may disable the universal overlay and as a result config-pin won't work and the can interface may be ... Jan 30 10:36:36 ...called can0 instead of can1 Jan 30 10:37:19 (I don't know if the latest image still disables the universal overlay if you specify a custom overlay to be loaded, I haven't checked) Jan 30 10:37:44 uhh, check using a scope? Jan 30 10:38:25 we checked on scope ,,,no pulse from P9.24 Jan 30 10:40:42 Do you anticipate any issue if we use LXQT instead of iot? Jan 30 10:41:07 shouldn't matter, apart from being slower to boot and leaving very little free space on eMMC Jan 30 10:41:26 Got it. Jan 30 10:42:24 There was an error on MCP2542 CANH ,L signals were swapped them ,but still no pulse on CAN Bus Jan 30 10:42:37 and the iot image doesn't include a desktop environment by default but a display itself (connected to hdmi?) will still work, e.g. for full-screen qt applications that don't need x11 Jan 30 10:44:29 We always see "can state Error Active " when we get this using ip -details Jan 30 10:44:46 that doesn't sound good Jan 30 10:45:40 So what could be the cause of this erro? Jan 30 10:45:42 I've played with can a while ago and I remember it being a bit fiddly... if a transmission didn't see itself, it would go into error state and not attempt any further transmissions Jan 30 10:46:46 I think the error state should be cleared if you do link down and link up again? Jan 30 10:46:49 can we enable auto retransmition ? Jan 30 10:47:17 I have no idea, I don't know much about can and even less about how can works in linux Jan 30 10:47:33 I think it'll auto-retransmit on collision and such Jan 30 10:47:49 but not if it thinks the hardware is faulty Jan 30 10:48:16 just to verify, you are using the can1 interface right? (also in linux?) Jan 30 10:50:01 Yes can1 Jan 30 11:36:30 hi how to bring up can module on beagle bone Jan 30 13:55:06 tistolz: so what you're asking is how to manually apply an overlay to your dts? Jan 30 13:57:04 tistolz: each fragment node of the overlay (child node of the root) becomes a top-level fragment in your dts. here's a reference for how fragments in normal dts syntax and overlay syntax relate to each other: https://pastebin.com/b8kZfhRG Jan 30 13:59:20 tistolz: you can ignore the metadata and the first fragment that disables pinmux helpers Jan 30 14:00:25 you mean, in https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-4D4C-01-00A1.dts ? Jan 30 14:00:46 so the first fragment you'd add to your dts is &am33xx_pinmux { ... }; Jan 30 14:01:32 so you mean there is no way of doing without editing that file? Jan 30 14:02:11 well without overlays, your beaglebone + cape combination is basically just a new hardware platform, which should have a dts that describes it Jan 30 14:02:49 my suggestion would be to create a new dts file that #includes the dts for the beaglebone and adds the fragments needed for the cape (and any other external hardware) Jan 30 14:03:32 So basically uboot just reads a single dtb file from the boot partition, according to the device type found? Jan 30 14:03:36 this is basically the same as what u-boot does when it loads a base dts and applies an overlay, except done at build time Jan 30 14:04:10 based on configuration provided, or hardware autodetection as fallback Jan 30 14:05:12 (btw, it's case it's useful, here's a quick summary of dts syntax: https://pastebin.com/XC8vB33d ) Jan 30 14:10:54 So thanks for your input... I guess manually assembling a .dts file is still second choice for me, I would like U-Boot to do the work for me :) Jan 30 14:11:46 There is a problem in the Buildroot makefiles s.t. compilation of manually added .dts files into .dtb for u-boot does not work, I'm discussing that over at #buildroot Jan 30 14:12:37 So maybe the question for you is: If I manage to supply those .dtb files (e.g. a BB-BONE-4D4C-01-00A1.dtb) to the boot partition, will U-Boot pick multiple ones and combine them? Jan 30 14:13:17 not if you're using mainline u-boot Jan 30 14:13:25 Hmm.. Jan 30 14:13:45 u-boot overlays are a custom patch for the beaglebone's u-boot, primarily to allow capes to work plug & play Jan 30 14:14:28 if you're building a custom system for a specific piece of hardware, which I presume you are since you're using buildroot, it makes more sense to use a single device tree file Jan 30 14:14:58 I had some indices that cape detection worked in my U-Boot - I'm getting lines like this: Jan 30 14:15:38 BeagleBone: cape eeprom: i2c_probe: 0x54: /lib/firmware/BB-BONE-4D4R-01-00A1.dtbo [0xfe1323f] Jan 30 14:15:38 BeagleBone: cape eeprom: i2c_probe: 0x55: Jan 30 14:16:09 how are you booting? Jan 30 14:16:12 And there is a symbol in uboot-menuconfig called OF_LIBFDT_OVERLAY=y (Enable the FDT library overlay support) Jan 30 14:16:44 I'm booting with a SD card, on which I flashed the sdcard.img made by buildroot Jan 30 14:17:19 unless you're powering on while holding down the S2 button (the button closest to the sd card slot), bootrom will prefer loading u-boot from eMMC over loading it from SD card Jan 30 14:17:33 so you're probably not using the u-boot built by buildroot Jan 30 14:18:58 and yes overlays are in mainline u-boot, but cape autodetection is not Jan 30 14:19:14 Anyway, later I'm going to burn the Buildroot system on the integrated flash, so it will replace the BeagleBone u-boot? Jan 30 14:22:17 you can also just wipe eMMC (sudo blkdiscard /dev/mmcblk1), then it'll necessarily load u-boot from sd card Jan 30 14:22:45 In the end, the product should completely do without SD card. Jan 30 14:23:07 I understand, but for testing it's probably more convenient than reflashing eMMC Jan 30 14:24:56 Of course :) Jan 30 14:26:13 After "sudo blkdiscard /dev/mmcblk1", is it easy to restore Debian and its u-boot using a flasher SD-card image? Jan 30 14:31:12 OK, I found out about the S2 button, which starts the u-boot from external SD card. Jan 30 14:31:33 yes you can just reflash eMMC Jan 30 14:32:25 note that the S2 button is only sampled during power-up (i.e. you can let go once the power led turns on), bootrom will retain its configuration across reboot/reset Jan 30 15:13:34 zmatt: Hi, do you know basically gnuplot ? Jan 30 17:08:46 m Jan 30 17:25:43 best effort GSoC IRC meeting in 5 minutes on #beagle-gsoc! Jan 30 17:38:53 #beagle-gsoc Jan 30 17:39:07 join #beagle-gsoc Jan 30 17:52:15 Hi all Jan 30 17:54:03 I'm interested to work for BeagleBoard deeplearning project. Could you guys please shared some info regarding the skillset required for the same Jan 30 18:00:59 Gaurav_: for GSoC? Personal learning? Jan 30 18:01:24 if GSoC related, you should ask in #beagle-gsoc Jan 30 18:16:02 fred__tv_: I know it exists Jan 30 18:28:29 zmatt: any pet projects you'd like to see done as part of GSoC? Jan 30 18:34:01 hrm. saw a fix on 4.19.x for omap-mmc, but uinfortunately it still didn't fix eMMC/microSD on beagleboard-x15 :/ Jan 30 18:34:18 haven't gotten anything newer than 4.17 to recognize it Jan 30 18:36:00 the beagleboard.org images are still shipping an older kernel? Jan 30 18:37:03 * vagrantc wonders if it's a missing regulator or something Jan 30 18:42:37 vagrantc: we are still pushing 4.14 as our stable. Jan 30 18:42:52 we do a lot of playing with 4.19. Jan 30 18:43:13 and by we, I mean rcn-ee and anyone who follows him closely Jan 30 18:43:28 4.19.x is what will ship with Debian's upcoming release Jan 30 18:43:37 there's a 5.0-rc up and running if you want to play. Jan 30 18:43:54 vagrantc: isn't Buster still a ways off? Jan 30 18:43:55 mostly want to get 4.19.x working in Debian :) Jan 30 18:44:05 jkridner[m]: it's in the early stages of freezing Jan 30 18:44:47 hope to see a release in may or june, maybe earlier Jan 30 18:44:55 I've been doing a bit of isolation of Robert's integrations in Buildroot to make sure I don't miss some of the stuff he does in userspace and the bootloader. https://github.com/beagleboard/buildroot/releases/tag/bt-0.1.15 Jan 30 18:45:12 also gives me an easy way to play with new kernels. Jan 30 18:45:41 there were a couple of issues with 4.19, but they don't float to the top of my head. Jan 30 18:46:01 I think uio got broken with the remoteproc work moving forward for PRU support. Jan 30 18:46:31 yeah, the eMMC/microSD issues is all i've noticed so far Jan 30 18:46:39 jkridner[m]: uhh I dunno. something that might be useful is figuring out how to arrange the hdmi audio to use s/pdif format instead of i2s (both mcasp and the hdmi framer support this), since it would free up two pins (and in particular allow spi1 to coexist with hdmi audio) Jan 30 18:47:17 jkridner[m]: hmm, how would uio and remoteproc even interact? they're completely unrelated drivers Jan 30 18:47:33 lemme check which kernel I use on my x15 Jan 30 18:47:54 zmatt: I probably don't understand it right. I just though rcn-ee was discussing some regressions on uio on the list related to 4.19 Jan 30 18:48:10 I thought uio was otherwise "done" upstream. Jan 30 18:48:39 https://groups.google.com/d/msg/beagleboard/poKd5tCRD04/lEdzl7VhGQAJ Jan 30 18:49:50 I'll see if I can fix it then, I actively rely on uio_pruss Jan 30 18:50:58 the uio pruss driver should be pretty trivial to forward-port, so I wonder what the issue is Jan 30 19:07:08 Hey everyone. Does anyone know what the header format is for u-boot.img that the MLO expects? Jan 30 19:12:36 uhh, when using an SPL, the u-boot.img loaded by it should simply be considered an opaque blob Jan 30 19:13:23 Hey again Matt. Turns out the spec of this project changed slightly and I don’t need to recreate the SPL, just u-boot image that the MLO loads and the kernel. Jan 30 19:13:53 From what I understand however, the u-boot.img contains headers and the actual binary file, so it’s not as easy as just executing from the start of the file Jan 30 19:14:04 At least that’s what this answer suggests: https://stackoverflow.com/questions/29494321/what-is-different-between-u-boot-bin-and-u-boot-img Jan 30 19:14:11 I'm pretty sure that SPL and u-boot.img are tightly linked together and you should always replace both of them together Jan 30 19:14:17 not mix&match versions Jan 30 19:14:31 Also in your hexdump you sent, it does appear to have a header, since it seems to list the version number Jan 30 19:14:50 well the MLO handles a lot of the timing stuff and the u-boot would just mainly handle loading the kernel into memory which i figured would be easier Jan 30 19:16:13 you're the one who wanted to baremetal stuff? (my memory isn't great) Jan 30 19:16:41 I mean, sure you can have your kernel loaded by u-boot to avoid having to deal with things like setting up the memory controller Jan 30 19:17:15 u-boot can kernels/applications in various formats, including raw binary I'm pretty sure Jan 30 19:17:19 *can load Jan 30 19:17:24 Yea, we spoke on the weekend. It’s part of a project I’m doing as a group. Not trying to get you to do my homework for me or anything but I’m not sure where to look for this information. Jan 30 19:17:37 Part of our requirements is creating the 3rd stage bootloader, AFTER the MLO Jan 30 19:17:39 and the kernel Jan 30 19:18:02 3rd stage bootloader? what would it do? Jan 30 19:18:18 and that would technically be fourth stage then I guess Jan 30 19:18:23 if you have u-boot load your bootloader Jan 30 19:19:09 Rom is the first stage -> Loads the MLO, MLO does some init for memory timings and loads the third stage into main memory -> Replace the u-boot third stage with our own -> Load our kernel Jan 30 19:19:42 Honestly the way you are saying things, I feel like my proff is mistaken. You’re right that the MLO and u-boot are compiled together and probably pretty coupled that you shouldnt just replace what the MLO is compiled to expect Jan 30 19:20:18 the secondary loader, u-boot SPL ("MLO" is just the name of the file format) is not designed to load anything other than u-boot.img built at the same time as the SPL itself (same version, same config) Jan 30 19:22:16 (or, well, it can directly load other stuff via the "falcon" mechanism, but that's meant as a shortcut to accelerate boot, and still requires u-boot to set that up in advance) Jan 30 19:22:57 hmmm so your suggestion is either have u-boot load a 4th stage bootloader or replace the MLO and u-boot together Jan 30 19:23:12 what's the point of the extra bootloader stage? Jan 30 19:23:46 Creating a bootloader is part of the requirements for this project, I think the proff tried to make it easier by saying we can just replace u-boot and use the SPL Jan 30 19:26:17 I mean, I don't exclude the possibility that it's possible, but it would probably be a lot easier to load your stuff from u-boot proper Jan 30 19:27:22 then you can use normal u-boot commands to load your application (whether it be a kernel or bootloader or any other sort of baremetal program) Jan 30 19:28:33 Yea I don’t think that’s possible, given what we are expected to do. This is supposed to be automated. I can’t find any real documentation on what format the header for u-boot.img is as I think you’re right in saying it’s coupled specifically at compile time Jan 30 19:29:03 u-boot can obviously load your stuff automatically too Jan 30 19:29:09 depending on how it is configured Jan 30 19:29:34 Yea, I’m just saying we have to create the bootloader either way. It’s a requirement Jan 30 19:29:49 so whether we do the whole thing or just ‘fake’ a bootloader by having u-boot load our bootloader.. not sure Jan 30 19:29:52 I don't see the problem Jan 30 19:30:17 I need to create a bootloader, i can’t use u-boot Jan 30 19:30:32 or at least not supposed to Jan 30 19:30:51 except getting permission to use SPL means you're not required to deal with the poorly documented and tricky low-level board initialization Jan 30 19:31:04 correct Jan 30 19:31:26 so then I don't see why it would be a problem to have u-boot load your bootloader Jan 30 19:33:04 if you use it to load a raw binary then the situation is similar again to being loaded directly by bootrom (like SPL is), except with more low-level board init having been performed Jan 30 19:33:39 I’m going to ask about that. Thank you Jan 30 19:33:52 as opposed to attempting to get loaded by SPL, which would require figuring out image formats and such Jan 30 19:34:08 which doesn't sound relevant to the project goal to me Jan 30 19:34:24 that would be a learning project to understand u-boot rather than focussing on writing your own code Jan 30 19:34:33 I agree completely Jan 30 19:35:10 For u-boot to load my ‘bootloader’ I would want to match the header of the file in accordance with this correct? https://github.com/u-boot/u-boot/blob/master/include/image.h#L204 Jan 30 19:35:28 Unless there is a really ‘raw’ mode it does seem like u-boot would need some headers on the image it loads Jan 30 19:35:30 I'm pretty sure u-boot can load and execute raw binaries without any header Jan 30 19:35:59 hmm Jan 30 19:37:21 you can just load the binary into memory and then use the 'go' command probably Jan 30 19:38:26 I’d need to automate that though so I’m wondering what the convention is. Because loading it into memory involves specifying a destination address which would probably be provided in the header no? Jan 30 19:38:27 it's possible that wrapping your binary into an image file using u-boot mkimage (so you can load it using bootm) might be more convenient Jan 30 19:38:50 you could just hardcode that Jan 30 19:40:48 how would you hardcode that? Jan 30 19:42:14 like, if you'd be loaded directly by bootrom, then you'd almost certainly use 0x402f0400 as load address. while MLO lets you specify the load address in principle, loading at 0x402f0400 would give you the most space, and some other boot methods do not use a header at all and always use 0x402f0400. so I feel like harcoded a load address for your bootloader would be most similar to the situation of ... Jan 30 19:42:20 ...being loaded by bootrom Jan 30 19:42:40 you'd hardcoded it in the bootscript you'd use in u-boot Jan 30 19:43:41 (which loads and executes your bootloader) Jan 30 19:43:55 Where is the 0x402f0400 load address from? Is that in the TRM memory map? Jan 30 19:44:11 Is the bootscript something u-boot looks for like uEnv.txt? I’ve never seen one on my BBB Jan 30 19:44:20 you can find it documented in the initialization chapter of the TRM Jan 30 19:45:24 the bootscript is just whatever u-boot commands are performed at boot, whether from compiled-in defaults or elsewhere Jan 30 19:46:49 pretty sure you can take it over completely using a suitable file like uEnv.txt, but I was kind of assuming that you wouldn't want to rely on files on a filesystem to configure u-boot and would just compile u-boot with a different default bootcmd instead (after testing it manually) Jan 30 19:48:49 yea that would be ideal Jan 30 19:49:04 I’m going to take a look at the TRM again. I didn’t see that address the first time I read it Jan 30 19:49:21 and I’ll try and find more information about the bootscript or how it can be editted Jan 30 19:50:02 Thank you again. I might be around this IRC asking things from time to time until I get this part figured out. I’m not too good with the hardware stuff. Once I’m in my kernel I’ll be able to progress faster Jan 30 19:50:39 in u-boot you can define a CONFIG_BOOTCOMMAND in the right place Jan 30 19:51:09 e.g. you can find it in the right include/configs/*.h file (iirc am335x_evm.h unless it moved around) and replace that Jan 30 19:51:26 after testing the command sequence you need manually Jan 30 19:55:10 That looks right, although the load address is different Jan 30 19:55:29 you can use whatever load address suits you of course Jan 30 19:55:38 nvm thats for SPI i was looking at Jan 30 19:55:44 zmatt: Glad to know you know gnuplot exist... :-)) Jan 30 19:55:58 or probably use 0x402f0400 to simulate a similar situation as being loaded by bootrom Jan 30 19:56:21 I suspect u-boot doesn't use that internal ram anymore after SPL Jan 30 19:56:28 but I'm not 100% sure Jan 30 19:58:06 not a gnuplot issue thougth.. Jan 30 19:59:15 chaos_: I suggest you just start by making a hello-world binary and manually loading and executing that from u-boot Jan 30 20:01:01 Will do. Jan 30 20:01:08 Do you know what section under intialization that address was? Jan 30 20:01:12 I’m looking right now Jan 30 20:03:12 26.1.4.2 Public RAM Memory Map for example Jan 30 20:03:34 lol, not sure where figure 26-7 there came from though, but figure 26-6 is correct Jan 30 20:04:22 it is also mentioned as the fixed address for peripheral boot (26.1.9.2) Jan 30 20:06:48 But that’s only 130kb? Jan 30 20:06:57 no, less Jan 30 20:07:00 or is that all the MLO sets up? Jan 30 20:07:49 that's the only ram available for the executable loaded by bootrom (e.g. u-boot SPL), before the memory controller has been set up Jan 30 20:09:20 I can’t overwrite that memory though without messing up u-boot since it’ll be loaded there won’t it? Jan 30 20:09:32 I thought u-boot initialized the Mem controller Jan 30 20:10:14 spl relocates to external memory after it has initialized the memory controller, and there's also where u-boot proper is loaded Jan 30 20:10:23 u-boot spl initializes the memory controller Jan 30 20:11:16 ah so u-boot SPL will be in the SRAM starting at 0x402f0400, and u-boot proper will be in the DDR that the SPL had setup? Jan 30 20:11:48 So yea I could put my 4th stage bootloader into the SRAM that the SPL was in, and then after passing control to it, load my kernel overtop of where u-boot proper was loaded into memory Jan 30 20:13:18 yep, as long as your bootloader isn't too bloated to fit in 127 KB Jan 30 20:13:42 I’d hope not haha Jan 30 20:15:43 Do you know what address the DDR starts at? Is that 0x80000000 in section 2 labelled “EMIF0 SDRAM”? Jan 30 20:15:51 yep Jan 30 20:15:55 kk Jan 30 20:15:59 0 Jan 30 20:16:32 0x80000000 - 0x9fffffff Jan 30 20:16:46 I was getting that mixed up with the GPMC that starts at 0x0 since that’s 512mb that the BBB has Jan 30 20:17:01 but yea it should be the other one i said just half the side for only 512mb even though it’s 1gb reserved Jan 30 20:17:03 thank you Jan 30 20:17:41 EMIF's address space is actually 2GB (0x80000000 - 0xffffffff) Jan 30 20:18:03 (yes I know the TRM claims otherwise, but the TRM is wrong) Jan 30 20:18:08 oh okay haha Jan 30 20:20:21 I’ve got to log but thanks for the help again. I shot an email to the proff as well to get approval for this idea. I think it makes more sense with what we are supposed to be learning Jan 30 20:20:38 You might see me again later ;) Jan 30 20:20:58 (though actually hooking up 2GB of ram to the am335x would require using two 8-bit width memory chips (similar to the beaglebone enhanced), and the necessary 1GB single-rank ddr3 memory chips are somewhat hard to find and expensive) Jan 30 20:21:10 I’m trying not to just leech you for information too btw. Sorry if i seems that way. I try to do my research before asking Jan 30 20:21:19 np Jan 30 20:31:53 bb enhanced? a new board? Jan 30 20:32:08 no it's been around for quite a while Jan 30 20:32:15 ok didn't miss anything Jan 30 20:32:50 I so love these things I don't wanna miss a thing :) Jan 30 20:35:00 basically had more ram and maybe wifi? Jan 30 20:35:48 1GB ram, usb hub with wifi chipset attached to one of the ports, gigabit ethernet, bunch of misc sensors Jan 30 20:36:01 zmatt: we were ended succesfully in a script to read data from UART and store in a file. I've put in a loop so file is updated every second: Jan 30 20:37:00 now gnuplot reads from this file in a loop , keeping plotted graph updated in a sort of "live" graph Jan 30 20:37:29 ew Jan 30 20:37:32 I mean, great to hear! Jan 30 20:37:35 :D Jan 30 20:38:11 the problem comes when sometimes gnuplot read files while script write into it , messing up things... Jan 30 20:38:38 so why are you doing those things separately, instead of invoking gnuplot after updating the file Jan 30 20:39:41 that's why if i recall gnuplot into script, graph id displayed for a fraction of second then disappears until the next call Jan 30 20:40:32 using the gnuplot "permanent" option works but each time a new gnuplot instance is created Jan 30 20:41:06 (ps ax shows tons of gnuplot) Jan 30 20:42:22 gnuplot has its own script mode to re-plot into a loop , but I can't insert the read/update script into it Jan 30 20:44:42 that sounds unfortunate Jan 30 20:45:09 looking for a way to synchronize things.... Jan 30 20:46:26 have you considered using an actual programming language instead of using bash to hackily glue all this together? Jan 30 20:46:37 e.g. python with pyserial and matplotlib Jan 30 20:47:54 sounds like chinese language to me :-((( Jan 30 20:48:34 Python! Jan 30 20:50:01 Heh? Jan 30 20:50:34 What goes together like bees and an okay grade? Jan 30 20:51:01 BB-B! Jan 30 20:52:47 Cheesy! Jan 30 21:02:21 Hello>? Jan 30 21:03:03 Okay. Off to find more productive things to do. I guess it is better than knowing you are reading my terrible jokes in disgust. **** ENDING LOGGING AT Thu Jan 31 02:59:57 2019