[beagleboard] Re: apt-show-versions
Thanks for the help. The base issue appears to be that compressed packages (.lz4) do not work at this time. Replacing them with uncompressed packages works. Check in rm /var/lib/apt/lists to see if the packages are .gz or .lz4. Remove them in either case and follow the instructions to finish the job. Very satisfying now that it works. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3fa8772f-b621-40c3-921f-46451a41a1bd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Enable charging while pocketbeagle is off
I've configured my pocketbeagle with a 3.7v Li-ION battery and it works fine. It also charges when I power the pocketbeage via the USB connector (and switches seamlessly as USB power comes and goes) . However it won't charge the battery when the computer shuts down. I suspect something disables charging on the PMIC during shutdown. Does anyone know if it's possible to tell the system not to disable charging? Or what part of the kernel handles this? I've also successfully read and written PMIC registers using the i2c utilities, for example to reconfigure the upper charge voltage to 4.2v. Thanks, Dan -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/04e1a9aa-7f61-431c-8c2b-42332d70e0aa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't get SPI data up to 10 MHz - PRU
Hi Charles, thank you very much for your answer,
I followed your advice but something overly odd is happening.
First of all, let me contextualize you: the image sensor is always sending
data through the CS, SCLK, and MOSI pins. The delay between each frame is
about 10 ms. That said, I wrote the code in attachment "prog_pru_v1". In
the first stage, I test it using the another PRU from beagle bone. So, I
send some clocks from PRU 1 and count them on the PRU1; here I checked that
the PRU can get all the pulses up to a frequency clock of 20 MHz (I only
need 10 MHz). The problem comes when I shortened the delay time between
frames, it stops catching all the clocks (in fact, it catches very few
clocks) and I don't understand the reason since it should be in a loop
(between the variation edges from the CS pin.
The other problem I did (prog_pru_v2.c) seems to work a bit better. It
sometimes catches all the clocks from the sensor and fails another times.
Surprisingly, the assembly code seems to be much uncluttered on this code.
I can't understand why is this happening, it doesn't seem to have much
sense. I validate the code successfully, but the problem comes when I start
sending much data spaced about 10 ms!
Find attached the code programs mentioned above, both the .c code and
assembly.
Let me know if you have any other suggestion I should test,
Bets regards,
-- Fred Gomes
Charles Steinkuehler escreveu no dia sexta,
7/12/2018 à(s) 13:47:
> On 12/7/2018 3:52 AM, Fred Gomes wrote:
> >
> > Here's the code where I got the better results:
> >
> > while(__R31&cs); // CS = 1
> >
> > while(__R31&sclk){ //sclk = 1
> >
> > if(__R31&cs){
> > goto END;}
> > }
> > while(!(__R31&sclk)); //SCLK = 0
> > var = (__R31&miso)? var |(0x01 << shift): var;
> >
> > k++;
> > shift--;
> >
> > if(shift == -1){
> > *(buffer_shared + cnt) = var;
> > cnt++;
> > shift=31;
> > var = 0;
> > }
> > END:
> > *(buffer_shared+2600) = k; // Here I am storing the value of the counter,
> > to check if all the clocks wre catched.
> >
> > I have only one small problem though, the sensor is sending data every
> > time, and sometimes it catches more than one frame. I don't
> > understand quite well why is it happening since the time between frames
> is
> > about 10 ms, and in that why it is difficult to have sure that I haven't
> > miss clocks in the frame. So, to have sure I am not missing clocks I add
> > the following line:
> >
> > LABEL:
> > if(k==79184)
> > goto END;
> >
> > And I noticed that sometimes I miss one clock (although here I am
> > introducing one extra instruction, which will make the program a bit
> slow).
> > If you have any suggestion I should implement to tackle this problem,
> > please let me know ...
>
> Again, please either write in assembly or post the assembly listing
> the compiler is generating. You have 12 lines of C code above, and
> that doesn't even look like the entire loop (just the inner loop for
> one 32-bit word). As mentioned previously, you have time for about 20
> PRU assembly instructions, which isn't many for 12 lines of C.
>
> Without the full code and seeing the assembly your compiler is
> generating, I can only make a few suggestions. An optimizing compiler
> would probably do much of this for you, but it doesn't sound like your
> compiler is doing much optimization (again, let's see some listing
> files!):
>
> * Get rid of the count variable and create a dedicated buffer pointer,
> then increment that, ie:
>
> *(buffer_shared + cnt) = var;
> cnt++;
>
> ...turns into:
>
> // Initial setup
> uint32_t *buffer_ptr = buffer_shared
>
> // ...other code goes here...
>
> *(buffer_ptr) = var;
> buffer_ptr++;
>
> * Review the generated code for the var update. The PRU has lots of
> bit test and shift instructions, so changing this calculation slightly
> could reduce the number of instructions needed. If I was writing in
> assembly I would shift var first then conditionally or in a '1'
> depending on the state of the input pin. In C it would look like this
> (but I don't know if this will generate the actual assembly I'm
> thinking of, it depends on your compiler):
>
> var >>= 1;
> if (__R31&miso) var |= 0x8000;
>
> * Review the code generated for the various bit test instructions (eg:
> __R31 & ). These should be a single bit test instruction in PRU
> assembly, but that may not be what the compiler is generating.
>
> There are other "tricks" you can try (eg: get rid of the shift count
> and use a bit in var instead). Without being able to see the
> generated assembly you can easily wind up making things much worse,
> but you can try it if you like. Make sure to initialize var to 0x8000
> and set the buffer_ptr value in your setup code:
>
> while(!(__R31&sclk)); //SCLK = 0
>
> k++; // I assume this is needed outside the loop
>
> // 1 in the LSB means this is the last bit of our 32-bit word
> if (var & 0x01)
> {
> // Shift in the last bit
> var >>= 1;
> if (
[beagleboard] Re: How to use "reserved-memory" in device tree to reserve DDR memory?
OK. I had made a mistake. Your suggestion solved the problem. Now I have a
gap in System RAM.
This is the device tree source that i have used and is OK:
/dts-v1/;
/plugin/;
/* Reserve 256kB DDR memory for the ping/pong buffers */
/ {
fragment@0 {
target-path = "/";
__overlay__ {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
pruadc_reserved: pruadc_reserved@0x9001 {
reg = <0x9001 0x0004>;
no-map;
status = "okay";
};
};
};
};
};
Thank you very much.
On Wednesday, October 10, 2018 at 12:24:35 AM UTC+3:30, GS wrote:
>
> I am trying to figure out how to reserve memory in device tree. (this is
> based on an example by TI: Dts
>
> and
> compile instructions section 3.1.2.4
> )
> Here is is my dts file:
>
> /dts-v1/;
>
> / {
> reserved-memory {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> pruadc_reserved: pruadc_reserved@0x9ffc {
> reg = <0x9ffc 0x0001>;
> no-map;
> status = "okay";
> };
> };
> };
>
> However, when I compile I get the following warnings:
> src/arm/MEM.dtbo: Warning (ranges_format): /reserved-memory has empty
> "ranges" property but its #address-cells (1) differs from / (2)
> src/arm/MEM.dtbo: Warning (avoid_default_addr_size): Relying on default
> #address-cells value for /reserved-memory
> src/arm/MEM.dtbo: Warning (avoid_default_addr_size): Relying on default
> #size-cells value for /reserved-memory
>
> Other combinations of address-cells/size-cells give reg format warnings.
>
> Any suggestions would be much appreciated.
>
> Thanks
> Gaurav
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/28f6d0c9-ffea-485b-89cc-7cce975588a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PRU Internal clock
Thanks to both of you, this is really helpful. Charles, this is what I was looking for and for this particular problem is what I need, but also thanks Bill I will have a look at this timer as well. On Friday, December 7, 2018 at 7:35:21 PM UTC-5, Charles Steinkuehler wrote: > > On 12/7/2018 11:16 AM, alanmthomason via BeagleBoard wrote: > > I use the BeagleBone Black PRU for a very time critical task. I > currently > > have registers that increment based on how many instructions I have just > > run and their type (SBBO's for instance take more than the usual 1 clock > > cycle per instruction) so that I can keep track of time. I have seen > > somewhere that you can reset and read an internal clock on the BBB PRUs, > > but I just can't seem to find that again. > > > > Has anyone used this feature, and if so can you guide me on how to go > about > > reading and resetting? > > There's the Industrial Ethernet Peripheral, mentioned by Bill which > includes support for 8 timers. > > In addition, there is an ECAP module within the PRU fabric (separate > from the other BBB ECAP timer modules). > > But I think you may be thinking of the Cycle/Stall registers. You can > enable the cycle count register in the Ctrl register (CTR_EN bit), and > you can clear the cycle count when the counter is disabled, if desired. > > -- > Charles Steinkuehler > cha...@steinkuehler.net > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1c969921-303f-4865-bef5-108620b6f67a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] How to use "reserved-memory" in device tree to reserve DDR memory?
I did what you said, but no result. Does memory reserving need any kernel
driver or configurations?
On Friday, December 7, 2018 at 8:53:22 PM UTC+3:30, RobertCNelson wrote:
>
> On Fri, Dec 7, 2018 at 10:49 AM >
> wrote:
> >
> > Hello.
> > I compiled the following code as the device tree source.
> >
> > /dts-v1/;
> > /plugin/;
> > /* Reserve 256kB DDR memory for the ping/pong buffers */
> > / {
> > fragment@0 {
> > target = <&ocp>;
> swap ocp for this:
>
> target-path = "/";
>
> > __overlay__ {
> > reserved-memory {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges;
> >
> > pruadc_reserved: pruadc_reserved@0x9000 {
> > reg = <0x9000 0x0004>;
> > no-map;
> > status = "okay";
> > };
> > };
> > };
> > };
> > };
> >
> >
> > But after booting, there is no trace of the reserved memory in the
> /proc/iomem file (there is no gap in "System RAM"). I also tested a large
> number of different sources, but none of them came up with a result.
> > Can you share here the device tree source that you have used?
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/1ab6ac42-67bc-40de-8274-b334d354c8d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] How to use "reserved-memory" in device tree to reserve DDR memory?
OK, I'm sorry. I'd made a mistake. Your suggestion solved the problem. Now
I have a gap in System RAM.
This is the device tree source that i have used and is OK:
/dts-v1/;
/plugin/;
/* Reserve 256kB DDR memory for the ping/pong buffers */
/ {
fragment@0 {
target-path = "/";
__overlay__ {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
pruadc_reserved: pruadc_reserved@0x9001 {
reg = <0x9001 0x0004>;
no-map;
status = "okay";
};
};
};
};
};
Thank you very much.
On Friday, December 7, 2018 at 8:53:22 PM UTC+3:30, RobertCNelson wrote:
>
> On Fri, Dec 7, 2018 at 10:49 AM >
> wrote:
> >
> > Hello.
> > I compiled the following code as the device tree source.
> >
> > /dts-v1/;
> > /plugin/;
> > /* Reserve 256kB DDR memory for the ping/pong buffers */
> > / {
> > fragment@0 {
> > target = <&ocp>;
> swap ocp for this:
>
> target-path = "/";
>
> > __overlay__ {
> > reserved-memory {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges;
> >
> > pruadc_reserved: pruadc_reserved@0x9000 {
> > reg = <0x9000 0x0004>;
> > no-map;
> > status = "okay";
> > };
> > };
> > };
> > };
> > };
> >
> >
> > But after booting, there is no trace of the reserved memory in the
> /proc/iomem file (there is no gap in "System RAM"). I also tested a large
> number of different sources, but none of them came up with a result.
> > Can you share here the device tree source that you have used?
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/e5887811-11e7-4890-bd65-54b8c7135550%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Enable UART4 - bbb - 4.4.113-ti-r149
I am running into the following error using Adafruit_BBIO.UART
UART.setup("UART4")
RuntimeError: Unable to export UART channel.
On Friday, December 7, 2018 at 10:55:48 PM UTC-5, Mike Brandon wrote:
>
> How is UART4 enabled on beaglebone black, uname_r=4.4.113-ti-r149
>
> Would I use
>
> cape_enable=bone_capemgr.enable_partno=BB-UART4
>
> in uEnv.txt?
>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/6423d8d7-0aa2-4224-9497-f24140b8ff50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: How does one get updates for BB customizations?
With regards to the customisations, they are in deb package bb-customisations. So apt upgrade does the job $ sudo dpkg -S /etc/udev/rules.d/60-omap-tty.rules bb-customizations: /etc/udev/rules.d/60-omap-tty.rules On Saturday, December 8, 2018 at 5:52:12 PM UTC+8, Luther Goh Lu Feng wrote: > > I customise my own Debian Stretch image based off a console image dated 04 > Apr 2018. I just stumbled upon bb-customisations in this repo: > https://github.com/rcn-ee/repos/tree/master/bb-customizations/suite/stretch/debian > > Question: Do I get these customisations if I just simply do a sudo apt > upgrade? If no, how do I get the latest snapshot of these customisations? > Is there any downside to using an old console image? Thanks! > > > --Luther > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a545bf9d-b058-4a52-b05f-75440f6eb80c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] How does one get updates for BB customizations?
I customise my own Debian Stretch image based off a console image dated 04 Apr 2018. I just stumbled upon bb-customisations in this repo: https://github.com/rcn-ee/repos/tree/master/bb-customizations/suite/stretch/debian Question: Do I get these customisations if I just simply do a sudo apt upgrade? If no, how do I get the latest snapshot of these customisations? Is there any downside to using an old console image? Thanks! --Luther -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/54325bdd-29a5-4e3a-8f84-7e99bbb19a6d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
