Re: [beagleboard] Re: BeagleBoard-X15 - seriously? :)

On 14 January 2015 at 17:17, Gerald Coley ger...@beagleboard.org wrote: I agree. But, the IP owners seem to be worried about someone copying their IP than they are using it and getting royalties. *stares at the PCIe chapter again and wonders how that would be helpful* Is there some magic

Re: [beagleboard] Re: BeagleBoard-X15 - seriously? :)

On Friday, 16 January 2015 16:29:37 UTC+1, RobertCNelson wrote: Check on linux-omap, Tony's been adding DM81xx support.. :D I think the problem with lack of mainline DM81xx support, is TI/etc never made a low cost BeagleBoard thus, the community never worked on it. ;) Yup, a shame

Re: [beagleboard] Re: BeagleBoard-X15 - seriously? :)

On Sunday, 18 January 2015 05:23:51 UTC+1, liyaoshi wrote: AM57x dont have EVE IP Well, they *have* four EVEs, but they didn't pass the factory test and got disabled. If all EVEs did pass the test it would probably have ended up with TDA2 stamped on its package. It two pass the tests (and

Re: [beagleboard] Re: BeagleBoard-X15 - seriously? :)

On Sunday, 18 January 2015 04:50:25 UTC+1, RobertCNelson wrote: Related to ipc 3.x/rpmsg, started hacking on getting ducati (gst-ducati) working This is getting confusing... as far as I know ducati properly refers only to the dual cortex-m3 subsystem, although somehow it seems to have

Re: [beagleboard] Re: BeagleBoard-X15 - seriously? :)

On Sunday, 18 January 2015 03:34:53 UTC+1, liyaoshi wrote: 1) dm81xx only support syslink ti called ipc ver1.x 2) dra74x only support ipc version 3.x , compatible with linux kernel rpmsg IPC should be pretty easily portable; which is also evident from the fact that IPC 3.x supports tci6638,

Re: [beagleboard] Re: BeagleBoard-X15 - seriously? :)

On 13 January 2015 at 02:35, Robert Nelson robertcnel...@gmail.com wrote: but we will see the bugs when users start plugging them in. ;) The revision that's in the DM814x certainly has some fun ones... - *Advisory 3.0.6* - Data is corrupted is burst accesses (e.g. EDMA) are performed

Re: [beagleboard] Re: BeagleBoard-X15 - seriously? :)

On 12 January 2015 at 19:32, Gerald Coley ger...@beagleboard.org wrote: You are correct. And all of those that were made public, evidently, should not have been. I really don't understand all this fussing about documentation. You'd think that being well-supported by software adds value to

Re: [beagleboard] Beaglebone Black Ethernet Phy Not Detected on Boot.

You can also fix most strapping options, including the PHY address, by writing to mdio register 0x12 (see datasheet http://ww1.microchip.com/downloads/en/DeviceDoc/8710a.pdf page 60). This whole issue still sounds really weird though. The RXD3/PHYAD2 line has internal pull-down in the PHY,

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

On Wednesday, 29 April 2015 17:30:14 UTC+2, Matthijs van Duin wrote: Your original question is actually very easy to answer I posted a bit too hastily since I missed the second half of your original post. If external hardware unconditionally drives or pulls up to 3V3EXP (in case of BBW

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

On Wednesday, 29 April 2015 20:18:51 UTC+2, Andrew Bradford wrote: If you take a BBW and cut the trace coming from U8 pin 5 (the LDO enable line) and then wire U8 pin 5 to the PWR_LED net on page 2 of the schematic, then the U8 LDO will shutdown correctly when on battery. It will shut

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

On Friday, 1 May 2015 19:01:06 UTC+2, Matthijs van Duin wrote: I've captured the shutdown sequence on DC versus BAT power in more detail Just a quick clarification to avoid confusion: Unlike the scope images in my original post, these were captured with BATMON connected to BAT even

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

On Thursday, 30 April 2015 12:14:19 UTC+2, Andrew Bradford wrote: For reference, I've not seen any failure of the am335x with this rework when using a custom cape at my previous job. That's not saying there isn't damage, just that I didn't see any. I'm also not sure how easily the am335x

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

On Wednesday, 29 April 2015 14:00:17 UTC+2, Andrew Bradford wrote: You seem to be talking about the BBB, correct? Correct, though it seems nearly all posts in this thread are referring to the BBB issue? My initial work was on BBW back in 2012 (prior to BBB release). It sounds like BBB has

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

On 19 May 2015 at 22:41, Max msonnail...@gmail.com wrote: Did you try any change in the EN pin of U4 (enable signal of 3V3B)? No, we replaced U4 by this state-of-the-art voltage-tracking regulator: ​ It can't supply as much current as the original, but our needs are modest enough. I'm

Re: [beagleboard] Re: Load and execute PRU code from bare-metal application

On 15 June 2015 at 16:33, Bill M billmerry...@gmail.com wrote: After reading through a bit more in the TRM about the PRU UART, I don't think a PRU UART will be feasible since it looks like they top out at around 300Kbs Hmm, where'd you get that number? The PRU UART looks like the highest

Re: [beagleboard] Re: Where is a manual for GCC asm coding (syntax etc.)?

On 14 June 2015 at 19:57, Matthijs van Duin matthijsvand...@gmail.com wrote: Uhh, in fact the output looks pretty invalid to me: it's putting :64 alignment specifiers on vector loads, yet those addresses only increment by 16 each loop iteration... Never mind that, alignment specs in Neon

[beagleboard] Re: Where is a manual for GCC asm coding (syntax etc.)?

On Sunday, 14 June 2015 06:49:37 UTC+2, Robert Willy wrote: I want to write ARM asm code with GCC toolchain. Previously, I use TI CGT, whose asm syntax is different from GCC. The assembler is actually part of Binutils, not of GCC itself. You can find its manual at:

Re: [beagleboard] Re: Load and execute PRU code from bare-metal application

On Wednesday, 10 June 2015 20:03:22 UTC+2, Charles Steinkuehler wrote: In addition to the other thread, I'd suggest looking at the BeagleLogic code. It's possible to move _large_ amounts of data through the PRU to the DRAM, but it requires some finesse. My first intuition would be using

Re: [beagleboard] Re: Where is a manual for GCC asm coding (syntax etc.)?

On 14 June 2015 at 17:59, Robert Willy rxjw...@gmail.com wrote: I know generally C compiler can do an excellent work. Well, to be honest I've also seen both GCC and Clang produce pretty idiotic output quite often enough. However, they do save you from the large amount of boilerplate you'd need

Re: [beagleboard] Re: Where is a manual for GCC asm coding (syntax etc.)?

On 15 June 2015 at 06:52, Robert Willy rxjw...@gmail.com wrote: I don't know how to get assembly code list file from compiling. I actually used it in my reply to your original post: On 14 June 2015 at 12:45, Matthijs van Duin matthijsvand...@gmail.com wrote: [..] compile it with arm-linux

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

On 20 May 2015 at 13:55, Maximiliano O. Sonnaillon msonnail...@gmail.com wrote: I will probably have to add an extra buffer to have PGOOD in 3.3V level Heh, it's a pity U3 is an inverter rather than a buffer... it's currently not actually used (hardware reset is not enabled in eMMC), it's

Re: [beagleboard] Beaglebone Black Ethernet Phy Not Detected on Boot.

I have to say, the motivation to remove caps suddenly makes a lot more sense to me after actually observing the power-on reset sequence on the scope: Horizontal scale: 5ms per grid line, 1ms per minor tick Vertical range 0-4V, scale: 0.8V per grid line, 0.2V per minor tick (except the yellow

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

On 20 May 2015 at 13:55, Maximiliano O. Sonnaillon msonnail...@gmail.com wrote: I was considering that one because it's a 3.3V logic signal. PGOOD is a 1.8V signal and the EN pin of U4 has a minimum of 2V to consider it high. Ick, I completely overlooked that. So it seems there's no single

Re: [beagleboard] BB X15, any status?

On 21 August 2015 at 15:30, Karl Karpfen karlkarpfe...@gmail.com wrote: TI's StarterWare forum is a mess Makes sense, given that StarterWare itself is too. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups

Re: [beagleboard] BB X15, any status?

On Tuesday, 14 July 2015 22:33:53 UTC+2, William Hermans wrote: hmm guess I'll have to read on the PCIE stuff once that information is widely available. Was kind of wanting to mess around with PCIE in hopes of learning how it all works - from a software perspective, and extremely low

[beagleboard] Re: eMMC Reset Line

I think you can also use mmc-utils from linux to enable the reset pin functionality in eMMC. Keep in mind this setting (ECSD byte 162, "RST_n_FUNCTION"), like disturbingly many of the eMMC's settings, is *one-time-programmable*. No margin for mistakes or second thoughts here :P (Unlike the

Re: [beagleboard] Re: eMMC Reset Line

On 1 November 2015 at 09:49, Matthijs van Duin <matthijsvand...@gmail.com> wrote: > Note BTW that as long as you leave mmc_clk alone you can safely use the > remaining pins for other purposes, so unless you really need that last pin > too I would leave reset alone. Or, if you

Re: [beagleboard] BeagleBone Black GPIO max frequency/bus latency (without using PRU)?

On Sunday, 30 August 2015 11:13:03 UTC+2, Andrew P. Lentvorski wrote: > > Apparently mmap is doing something stupid that slows down the access from > user space. > It maps the memory as "strongly ordered", which means the writes get flagged with a "delivery confirmation required" bit and the

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

On 2 November 2015 at 04:33, William Hermans wrote: > I honestly do not know the eCAP / PWM modules at all, but I suspect that > you would not necessarily need to use the PRU to access these modules. Although I haven't yet tried to use the eCAP in PRUSS, I don't think

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

On 2 November 2015 at 07:52, William Hermans wrote: > Determinism. I do agree with what you're saying, but sometimes, you need > things to happen at exactly . In userland, you may be > able to achieve that most of the time, but you will not be able to achieve > that all of the

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

On 2 November 2015 at 06:22, William Hermans wrote: > *Correct, pretty much anything can be used from userspace like that, >> although some people will frown at you for bypassing the kernel if you do.* >> > > So maybe to you, and others this seems like an argument. > No, I

[beagleboard] Re: Slave McSPI with DMA

On 2 November 2015 at 19:02, John Syne wrote: > I have been reading your posts and I am impressed with your detailed > knowledge of the inner workings of the AM335x. Do you have any experience > with using MCSPI as a slave and using EDMA. I’m using a high speed ADC that >

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

On 4 November 2015 at 03:40, Pierre-Louis Constant wrote: > you guys provided me enough info leads for a whole year of insomnia. > haha, sorry :-) > Correct, pretty much anything can be used from userspace like that, >> although some people will frown at you for bypassing

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

On 4 November 2015 at 05:01, William Hermans wrote: > Where would be a good start to read up on uio ? I've been reading around, > but have not found anything of much use yet. > The official doc is the UIO Howto , but it's very

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

On 4 November 2015 at 07:06, Matthijs van Duin <matthijsvand...@gmail.com> wrote: > See TRM chapter 12 for usage (yes, "Touchscreen Controller", that's the > one). You can also peek at my header: http://gerbil.xs4all.nl/adc.h (the headers it depends on can be found

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

On 4 November 2015 at 07:34, Matthijs van Duin <matthijsvand...@gmail.com> wrote: > #include sorry, #include "util/device.h" it's obviously not a system header (but also one you can find in jbang) -- For more options, visit http://beagleboard.org/discuss --- You re

[beagleboard] BBB pull contention

On 9 February 2016 at 17:46, Gerald Coley wrote: > If you don't run SW, that fixes a contention issue in the processor and > let it sit, you will void the warranty and damage the processor after about > 120 hours of operation.. Speaking of contention, I reported one in

[beagleboard] Re: BBB pull contention

On 12 February 2016 at 15:07, Robert Nelson wrote: > Nah, that one is my fault.. That bug report must be bad luck, as > every time i started looking at it, something at the day job pulled me > away.. > OK, thing is, although it didn't seem particularly important to me

[beagleboard] Re: BBB pull contention

On 12 February 2016 at 16:37, Robert Nelson wrote: > So, P9.15, gpmc_a0 is setup as: > > {OFFSET(gpmc_ad0), (MODE(1) | RXACTIVE | PULLUP_EN)}, /* MMC1_DAT0 */ > Those are different pins. The only useful purpose of pin 16 ("gpmc_a0") on a BBB is as pwm 1 tripzone input.

Re: [beagleboard] BBBW sgx driver and library

On Sunday, 22 January 2017 01:12:53 UTC+1, RobertCNelson wrote: > > It's a different stack, and we don't really have TI's new userspace > working yet. I have been able to successfully run kmscube on the new stack today! Here's the set of magic ingredients:

[beagleboard] Re: Problems using BeagleBone Black's UART

On Thursday, 9 February 2017 13:30:23 UTC+1, oetti133 wrote: > > For testing I ordered the Waveshare RS485-CAN Cape > . > Ehm, I noticed in its schematic that it ties the R-output of

[beagleboard] Re: eQEP not reading meaningful values

On Friday, 3 February 2017 13:17:20 UTC+1, Hugh Frater wrote: > > However when I 'cat position' in each of the relevant sys entries (having > moved my encoder A/B lines to the relevant pins each time), I get a > changing value but it isn't meaningful. Am I missing something, or is it > more

[beagleboard] Re: Microchip mcp2515, can over spi, not working. Wrong device tree overlay?

I haven't really looked yet at your overlay, but two immediate thoughts: 1. why on earth are you using an spi can controller when there are *two* built-in CAN controllers already on the beaglebone? 2. you have cape-universal enabled, this conflicts with pretty much every overlay (remove the

[beagleboard] Re: Microchip mcp2515, can over spi, not working. Wrong device tree overlay?

The clocks node is definitely wrong. Every top-level node in an overlay file is treated as a fragment (names like fragment@0 are conventional but not actually important), but your clocks-node has no target property nor an __overlay__ child node, so it accomplishes nothing. Matthijs -- For

Re: [beagleboard] SGX on 4.4.*-ti-rt kernel

On Monday, 26 September 2016 21:06:17 UTC+2, RobertCNelson wrote: > > sudo mkdir -p /lib/modules/4.4.11-00332-gce54280-dirty/extra/ > sudo ln -s /lib/modules/`uname -r`/extra/ti335x/pvrsrvkm.ko > /lib/modules/4.4.11-00332-gce54280-dirty/extra/pvrsrvkm.ko > You can also just modprobe the module

Re: [beagleboard] SGX on 4.4.*-ti-rt kernel

On Wednesday, 28 September 2016 11:05:50 UTC+2, Matteo Facchinetti wrote: > > libEGL warning: DRI3: xcb_connect failed > libEGL warning: DRI2: xcb_connect failed > libEGL warning: DRI2: xcb_connect failed > Unable to initialise egl > egl error 'EGL_NOT_INITIALIZED' (0x3001) > > Sounds like

[beagleboard] Re: init-eMMC-flasher mmcqd allocation failures

I've also run into this once during an apt-get upgrade, leaving the system in a pretty hosed state. I managed to recover it but it required a lot of effort. Although evidently rare, this is clearly a very serious issue. The direct cause is edma_prep_slave_sg() failing to allocate memory for the

Re: [beagleboard] SGX on 4.4.*-ti-rt kernel

On 4 October 2016 at 23:18, Robert Nelson wrote: > > debian@beaglebone:~$ sudo modprobe pvrsrvkm > > (nothing in dmesg) > > debian@beaglebone:~$ lsmod | grep pvr > pvrsrvkm 379674 0 > debian@beaglebone:~$ ls /dev/dri/* > /dev/dri/card0 /dev/dri/controlD64 >

Re: [beagleboard] SGX on 4.4.*-ti-rt kernel

On 5 October 2016 at 02:43, William Hermans wrote: > So libEGL is Mesa's Wayland extensions. > No. https://en.wikipedia.org/wiki/EGL_(API) > Mesa is a 3d graphics library. Not sure how SGX even comes in at this > context ? > > Well it's not going to if you accidently use

[beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

On Monday, 20 February 2017 01:51:53 UTC+1, ags wrote: > > Is it correct that whenever the PRU cores access any resource through the > 32-bit system but, it is subject to varying delay since the other PRU core > and even the ARM core (through the OCP slave, for instance if the ARM is > pushing

Re: [beagleboard] Re: Problems using BeagleBone Black's UART

For what? using the uarts? If you're using a recent image then you don't have to mess with overlays at all. In the default configuration, you can configure pin function at runtime using the "config-pin" utility, e.g. for uart4: config-pin P9.11 uart # switch P9.11 to uart 4 rxd config-pin P9.13

[beagleboard] enable use of the hwrng for kernel entropy pool

Today I learned that the hardware rng, even though its driver was loaded, wasn't being used at all other than to create /dev/hwrng which isn't used by anything. The problem is that the driver neglects to declare a "quality" parameter that indicates the quality of the entropy it generates, which

[beagleboard] py-uio now supports using clpru with uio_pruss

Hi all A while ago I made a small pure-python uio library with some examples on how to use uio_pdrv_genirq to directly use various peripherals on the BBB. More recently I built a PRU-ICSS library using uio_pruss on top of it, making it a pure-python alternative to prussdrv. Although I

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

I just realized that enabling it in the base dts for beaglebone using a remoteproc-pru compatible structure was probably a bad idea... While it is safe to apply the remoteproc-pru overlay on top of it (albeit pointless since it hasn't been ported to 4.19 yet), applying the uio-pruss overlay on top

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

I've forward-ported the uio-pruss driver to the 4.19 kernel series, and cleaned it up a bit in the process. I've done a quick test on beaglebone black and on beagleboard-x15 (both pru instances), including that irqs work. Here's the patchset:

Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected on Boot.

On Tue, 5 Jun 2018 at 02:11, wrote: > I've come up with a software only workaround that can make sure a BBB will > always come up with a working Ethernet port - although it can take a few > minutes and require several automatic internal power cycles. > > You can read about it here... > > >

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

On Tue, 12 Feb 2019 at 19:56, Robert Nelson wrote: > I just enabled the first patch by default: > > > https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.19.y/patch.sh#L489-L492 Ahh, I missed that. I just saw the merge in the git commits and didn't realize it was a merge with

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

OK, shame on me for just testing everything works on bbx15 and merely checking the devices show up on beaglebone and *assuming* they work. They really didn't. I had overlooked that the ti,deassert-hard-reset DT property is a non-standard thing added by the original uio-pruss patch. A better

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

at 12:44, Matthijs van Duin wrote: > Adding ti,pintc-offset = <0x2>; to should suffice Obviously we could also change the uio-pruss driver to avoid this need for this property entirely. It ought to be implicit from the compatible-string. Matthijs -- For more options, v

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

On Wed, 13 Feb 2019 at 12:20, Roger Quadros wrote: > I see that uio_pruss is important for the bone community. We will need > to work together to make sure that it continues to operate > Fortunately uio_pruss is a pretty simple driver that's easy to forward-port. > Meanwhile, I'd like to

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

On Wed, 13 Feb 2019 at 13:42, Roger Quadros wrote: > On 13/02/19 13:57, Matthijs van Duin wrote: > > +#ifdef CONFIG_ARCH_DAVINCI_DA850 > > if (pdata->sram_pool) { > > gdev->sram_pool = pdata->sram_pool; > > What is this sram pool? Is it abo

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

On Monday, 28 January 2019 20:40:09 UTC+1, RobertCNelson wrote: > > On Mon, Jan 28, 2019 at 1:33 PM Daniel Kulp > > wrote: > > Does this mean it's something that is being worked on to be fixed for an > upcoming 4.19 kernel update or are UIO folks completely SOL and stuck on > 4.14 kernels? >

[beagleboard] Re: librobotcontrol

On Sunday, 7 July 2019 20:44:21 UTC+2, Steven Coddington wrote: > > just installed (again) latest image. got Strawson librobotics in a > directory. tried to run rc_blink.c and got following message: > > Compiling /var/lib/cloud9/sandbox/librobotcontrol/examples/src/rc_blink.c > ... > cc

[beagleboard] Re: Beagle Bone Black 24-Bit LCD_DATA?

On Sunday, 5 January 2020 22:39:31 UTC+1, Alex Rodriguez wrote: > > Hello everyone, > > I recently purchased a display that I would like to use with my Beagle > Bone Black. > > I understand that the BBB can be configured to use 24-bit color via the > LCD_DATA lines using custom overlays. I have

Re: [beagleboard] BBGW - Changing boot order ?

On Monday, 6 January 2020 21:53:07 UTC+1, David Cherkus wrote: > > Is there a workable way to "corrupt" the MLO in eMMC so the first level > program loader in ROM skips over it and tries sdcard instead? > sudo dd if=/dev/zero of=/dev/mmcblk1 seek=256 count=1 Matthijs -- For more options,

Re: [beagleboard] realtime kernel

Your question has nothing to do with the topic of this thread (kernel warnings and breakage when trying to use an RT kernel on the BBAI, caused by the brcmfmac driver). Please create a new thread instead of hijacking an old unrelated one. This clutters the original topic and will reduce the