in its own separate thread in a loop with a task
> delay resolution to match the baud rate.
>
> Then you are done, assuming the output pin read does actually work that
> way.
> If not you can try setting input mode, read the value, then set output
> mode right after you are done r
What's the best way to detect a change in value on a GPIO configured as OUT?
It may sound really weird why one may need that. I have a custom cape and
cannot make changes to its hardware, but I need to improve certain
functionality.
poll(2) on /sys/class/gpio/gpioXY/value exits with timeout.
To
Does anybody know how to do that?
I couldn't find any instructions. In U-Boot 2018.01 source the variable
CONFIG_SPLASH_SCREEN does not appear anywhere related to BeagleBone (or I
missed something).
Thanks for directions!
Sergey
--
For more options, visit http://beagleboard.org/discuss
---
Y
Does anybody know how to do that?
I couldn't find any instructions. In U-Boot 2018.01 source the variable
CONFIG_SPLASH_SCREEN does not appear anywhere related to BeagleBone (or I
missed something).
Thanks for directions!
Sergey
--
For more options, visit http://beagleboard.org/discuss
---
Y
Excerpts from Sergey Manucharian's message from Thu 23-Aug-18 14:04:
> Excerpts from Robert Nelson's message from Thu 23-Aug-18 14:26:
> > On Thu, Aug 23, 2018 at 2:04 PM Sergey Manucharian wrote:
> > >
> > > Okay, I found that only xz compressed modules won
Excerpts from Robert Nelson's message from Thu 23-Aug-18 14:26:
> On Thu, Aug 23, 2018 at 2:04 PM Sergey Manucharian wrote:
> >
> > Okay, I found that only xz compressed modules won't be loaded. Will try to
> > find the root cause.
>
> Either you need to
Okay, I found that only xz compressed modules won't be loaded. Will try to
find the root cause.
On Thursday, August 23, 2018 at 9:57:25 AM UTC-6, Sergey Manucharian wrote:
>
> Most likely this is not a BeagleBone specific thing, just happened to me,
> and I'm really confuse
Most likely this is not a BeagleBone specific thing, just happened to me,
and I'm really confused, probably missing something obvious.
There are no problems with 4.14.51 kernel booted without any initramfs
(initrd.img).
However, in certain setups I have to boot in *rootfs* in a raw image on a
F
Excerpts from Robert Nelson's message from Mon 08-Jan-18 13:01:
> On Mon, Jan 8, 2018 at 12:54 PM, Sergey Manucharian wrote:
> > It's not clear to me: why when both eMMC and SD present and contains u-boot
> > (both in raw mode), the CPU decides to boot from eMMC.
> &g
It's not clear to me: why when both eMMC and SD present and contains u-boot
(both in raw mode), the CPU decides to boot from eMMC.
Is there a way to default to SD? The Technical Reference mentions a
timeout, or am I missing anything?
Of course, the latest u-boot (in eMMC) does check for SD presen
like I said.. u-boot bug...
>
> On Jul 1, 2017 1:24 PM, "Sergey Manucharian" > wrote:
>
> Most likely you're right assuming that u-boot must be aware of what
> particular CPU it's dealing with (otherwise it's not possible since there
> is no standard API for
.nabble.com/USB-Host-not-enumerating-properly-on-AM335x-based-board-td196920.html
Since I'll be traveling the next 10 days, will not be able to try different
versions or look into u-boot's code...
Will report the results later.
On Saturday, July 1, 2017 at 12:24:23 PM UTC-6, Sergey M
Most likely you're right assuming that u-boot must be aware of what
particular CPU it's dealing with (otherwise it's not possible since there
is no standard API for such things as USB power).
On Saturday, July 1, 2017 at 9:19:42 AM UTC-6, RobertCNelson wrote:
>
> Then that's a u-boot bug, usb sh
, but tell them
"root=/dev/sda1 rootwait" (i.e. USB drive), so the kernel enables the USB
power, then mount the USB stick. With this approach you cannot load a
kernel *from* USB drive.
On Saturday, July 1, 2017 at 8:50:01 AM UTC-6, RobertCNelson wrote:
>
> On Fri, Jun 30
*then* load kernel and stuff from USB flash drive.
On Friday, June 30, 2017 at 9:46:27 PM UTC-6, William Hermans wrote:
>
>
>
> On Fri, Jun 30, 2017 at 7:50 PM, Sergey Manucharian > wrote:
>
>> From this thread https://e2e.ti.com/support/arm/sitara_arm/f/791/t/270060
>
4 PM UTC-6, Sergey Manucharian wrote:
>
> That's exactly what I do, it works fine, the problem is that the USB has
> no power at that time, I have to use an external power supply.
>
> On Friday, June 30, 2017 at 1:16:08 PM UTC-6, RobertCNelson wrote:
>>
>>
>>
That's exactly what I do, it works fine, the problem is that the USB has no
power at that time, I have to use an external power supply.
On Friday, June 30, 2017 at 1:16:08 PM UTC-6, RobertCNelson wrote:
>
>
> Once you boot into "U-Boot" from the microSD/eMMC, load the files from
> the USB flash
I'd like to use uboot's USB subsystem to boot off a USB flash drive.
However, the USB power is disabled at boot/reset. When I provide external
power everything works as expected,
So, how to enable USB power at CPU power-up/reset or with u-boot itself?
Thanks for advises!
--
For more options, vi
Works like a charm! Thank you, Robert!
On Tuesday, June 27, 2017 at 2:41:45 PM UTC-6, RobertCNelson wrote:
>
>
> 3 things..
>
> 1st:
>
> Your going to have to upgrade that kernel.
>
> 4.4.16-ti-rt-r38 used "kernel" overlays... To support these almost
> everything is built as a module. So the
How to enable splash screen for 4.4.x kernels?
I never had problems with 3.8.x kernels. I'm using an LCD compatible with
the standard 7" cape (4DCAPE-70T).
The kernel is 4.4.16-ti-rt built from
https://github.com/RobertCNelson/bb-kernel.
I've enabled standard boot logo in the kernel, but it doe
Thanks, Robert!
It works. Of course, it didn't, when trying for first time I "deleted" *all*
those modes.
The following lines successfully set MMC clock to 25MHz:
max-frequency = <2500>;
/delete-property/ sd-uhs-sdr104;
/delete-property/ sd-uhs-sdr50;
/delete-property/ sd-uh
Thanks, Robert!
However, just adding that block of "delete-property"-s from the example you
pointed to didn't help.
By the way, where are those modes defined?
sd-uhs-sdr104
sd-uhs-sdr50
sd-uhs-ddr50
sd-uhs-sdr25
sd-uhs-sdr12
On Wednesday, December 21, 2016 at 9:19:17 AM UTC-7, RobertCNelson wr
I'm trying to limit mmc clock frequency by adding the line to a .dts
(kernel 4.4.16-ti-rt):
max-frequency = <2500>;
It works only for mmc2, but not for mmc0 and mmc1.
It remains 50Mhz for mmc0 and 52Mhz for mmc1.
Thanks for ideas!
--
For more options, visit http://beagleboard.org/discuss
-
SOLVED: it works now:
bone_capemgr.enable_partno=BB-LCD10
It was my fault. I reworked the DTS file. Initially it was based on the old
BB-BONE-LCD7-01-00A0.dts (since my cape has been designed based on Bone LCD
7").
But even BB-BONE-LCD7-01-00A1.dts works out of the box for my LCD panel.
Althou
BBB compatibility issues:
>
> You can override dtb=x in /boot/uEnv.txt...
>
> BeagleBone Black: HDMI (Audio/Video) disabled:
>
> dtb=am335x-boneblack-emmc-overlay.dtb
>
> BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
>
> dtb=am335x-boneblack-overlay.dtb
>
>
> ps, this is all in:
>
> https://g
:00A0 (prio 0)
On Wednesday, May 11, 2016 at 10:06:36 AM UTC-6, RobertCNelson wrote:
>
>
>
> On Wed, May 11, 2016 at 11:03 AM, Sergey Manucharian > wrote:
>
>> I've added it to "cmdline=" and I do see it when booted:
>>
>> $ cat /proc/cmdline
=LVDS-1:800x600@60
On Wednesday, May 11, 2016 at 9:56:34 AM UTC-6, RobertCNelson wrote:
>
>
>
> On Wed, May 11, 2016 at 10:50 AM, Sergey Manucharian > wrote:
>
>> That was the first think I tried, but it's simply ignored:
>>
>> bone_capemgr.enable_partno=XX
That was the first think I tried, but it's simply ignored:
bone_capemgr.enable_partno=
On Wednesday, May 11, 2016 at 9:43:11 AM UTC-6, RobertCNelson wrote:
>
>
>
> On Wed, May 11, 2016 at 10:40 AM, Sergey Manucharian > wrote:
>
>> Well, I'm us
Well, I'm using 4.4.8-ti-rt-r22 and the option capemgr.extra_override=
doesn't work for a cape without EEPROM, but it works by echoing into
/sys/devices/platform/bone_capemgr/slots.
On Wednesday, May 11, 2016 at 9:34:12 AM UTC-6, RobertCNelson wrote:
>
> Umm, that was 3 years ago...
>
> Just
29 matches
Mail list logo
