[beagleboard] BBB ping not working after restart
Dear all, I am having a strange problem with my BBB, I could not find any solution so far on internet to solve the issue so writing here. I have configured my BBB with stable debian image from the main BB website. After that I did the internet configuration added default gateway and updated nameserver then the ntp for date internet worked. I updated/upgraded and then I updated the kernel to have source headers as I needed them for some driver I wanted to install. I followed the following instructions provided by Robert Nelson; https://groups.google.com/forum/#!topic/beagleboard/l5RLNUGYrAc wget https://raw.github.com/gkaindl/beaglebone-ubuntu-scripts/master/bb-get-rcn-kernel-source.sh chmod +x bb-get-rcn-kernel-source.sh ./bb-get-rcn-kernel-source.sh The kernel was successfully updated and I moved forward with my work happily. Today, when I came back to work and started my BBB ran the script I used to update the gateway and namerserver on startup. After that I did ping 8.8.8.8, it did not work. It just stays there no response at all, I assume that it is sending the packets but not receiving back any. I don't know why I am having this problem. Any help will be highly appreciated. Please let me know if any help is required. PS: I am running windows 7 PC, which is connected to a wireless network. Regards, Naqqash -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB ping not working after restart
I have solved the problem. The solution is quite strange but worked for me so I thought I should share if anybody will have the same problem in future. All I did is that in my windows pc I re shared the internet connection. Regards, Naqqash On Thursday, November 6, 2014 11:53:25 AM UTC+1, Naqqash Abbassi wrote: Dear all, I am having a strange problem with my BBB, I could not find any solution so far on internet to solve the issue so writing here. I have configured my BBB with stable debian image from the main BB website. After that I did the internet configuration added default gateway and updated nameserver then the ntp for date internet worked. I updated/upgraded and then I updated the kernel to have source headers as I needed them for some driver I wanted to install. I followed the following instructions provided by Robert Nelson; https://groups.google.com/forum/#!topic/beagleboard/l5RLNUGYrAc wget https://raw.github.com/gkaindl/beaglebone-ubuntu-scripts/master/bb-get-rcn-kernel-source.sh chmod +x bb-get-rcn-kernel-source.sh ./bb-get-rcn-kernel-source.sh The kernel was successfully updated and I moved forward with my work happily. Today, when I came back to work and started my BBB ran the script I used to update the gateway and namerserver on startup. After that I did ping 8.8.8.8, it did not work. It just stays there no response at all, I assume that it is sending the packets but not receiving back any. I don't know why I am having this problem. Any help will be highly appreciated. Please let me know if any help is required. PS: I am running windows 7 PC, which is connected to a wireless network. Regards, Naqqash -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Make modules modules_install problem.
Adding to my observations: By inspecting the bb-kernel/tools/local_install.sh I found that the 3.8.13+ probably stems from the file ./KERNEL/include/generated/utsrelease.h The script sets the KERNEL_UTS to 3.8.13+ by extracting the parameter from the utsrelease.h As the kernel version is distributed as 3.8.13-bone67, this seem to be a flaw in the kernel build/install system? -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: [U-Boot] [PATCH 11/11] beagle_x15: add board support for Beagle x15
On Thu, Nov 6, 2014 at 8:28 AM, Felipe Balbi ba...@ti.com wrote:
This is the bare minimum support for Beagle x15
into u-boot. There is still quite some work in
order to get this in good shape, but it's a
start.
Sorry, I should have commented earlier :)
we could expand this a little more here?
How about:
BeagleBoard-X15 is the next generation Open Source Hardware
BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ A15
processor. The platform features 2GB DDR3L (w/dual 32bit busses),
eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60), separate LCD
port, video In port, 4GB eMMC, uSD, Analog audio in/out, dual 1G
Ethernet.
For more information, refer to:
http://www.elinux.org/Beagleboard:BeagleBoard-X15
ofcourse - the wiki is yet to be built up..
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap5/Kconfig | 4 +
board/ti/beagle_x15/Kconfig | 12 ++
board/ti/beagle_x15/Makefile | 8 +
board/ti/beagle_x15/board.c | 328
++
board/ti/beagle_x15/mux_data.h| 55 +++
configs/beagle_x15_defconfig | 5 +
include/configs/beagle_x15.h | 89 +++
include/configs/ti_omap5_common.h | 2 +
8 files changed, 503 insertions(+)
create mode 100644 board/ti/beagle_x15/Kconfig
create mode 100644 board/ti/beagle_x15/Makefile
create mode 100644 board/ti/beagle_x15/board.c
create mode 100644 board/ti/beagle_x15/mux_data.h
create mode 100644 configs/beagle_x15_defconfig
create mode 100644 include/configs/beagle_x15.h
diff --git a/arch/arm/cpu/armv7/omap5/Kconfig
b/arch/arm/cpu/armv7/omap5/Kconfig
index 129982c..aca862d 100644
--- a/arch/arm/cpu/armv7/omap5/Kconfig
+++ b/arch/arm/cpu/armv7/omap5/Kconfig
@@ -12,6 +12,9 @@ config TARGET_OMAP5_UEVM
config TARGET_DRA7XX_EVM
bool TI DRA7XX
+config TARGET_BEAGLE_X15
+ bool BeagleBoard X15
+
endchoice
config SYS_SOC
@@ -20,5 +23,6 @@ config SYS_SOC
source board/compulab/cm_t54/Kconfig
source board/ti/omap5_uevm/Kconfig
source board/ti/dra7xx/Kconfig
+source board/ti/beagle_x15/Kconfig
endif
diff --git a/board/ti/beagle_x15/Kconfig b/board/ti/beagle_x15/Kconfig
new file mode 100644
index 000..a305ff1
--- /dev/null
+++ b/board/ti/beagle_x15/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_BEAGLE_X15
+
+config SYS_BOARD
+ default beagle_x15
+
+config SYS_VENDOR
+ default ti
+
+config SYS_CONFIG_NAME
+ default beagle_x15
+
+endif
diff --git a/board/ti/beagle_x15/Makefile b/board/ti/beagle_x15/Makefile
new file mode 100644
index 000..5cd6873
--- /dev/null
+++ b/board/ti/beagle_x15/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2014
+# Texas Instruments, www.ti.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y := board.o
diff --git a/board/ti/beagle_x15/board.c b/board/ti/beagle_x15/board.c
new file mode 100644
index 000..5cafc87
--- /dev/null
+++ b/board/ti/beagle_x15/board.c
@@ -0,0 +1,328 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Felipe Balbi ba...@ti.com
+ *
+ * Based on board/ti/dra7xx/evm.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include palmas.h
+#include sata.h
+#include usb.h
+#include asm/omap_common.h
+#include asm/emif.h
+#include asm/arch/clock.h
+#include asm/arch/sys_proto.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/sata.h
+#include asm/arch/gpio.h
+#include environment.h
+
+#include mux_data.h
+
+#ifdef CONFIG_DRIVER_TI_CPSW
+#include cpsw.h
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+const struct omap_sysinfo sysinfo = {
+ Board: BeagleBoard x15\n
+};
+
+static const struct dmm_lisa_map_regs beagle_x15_lisa_regs = {
+ .dmm_lisa_map_3 = 0x80740300,
+ .is_ma_present = 0x1
+};
+
+void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs)
+{
+ *dmm_lisa_regs = beagle_x15_lisa_regs;
+}
+
+static const struct emif_regs beagle_x15_ddr3_532mhz_emif_regs = {
+ .sdram_config_init = 0x61851B32, /* dont know what to do about
this */
+ .sdram_config = 0x61851B32,
+ .sdram_config2 = 0x,
+ .ref_ctrl = 0x1035,
+ .sdram_tim1 = 0xCEEF266B,
+ .sdram_tim2 = 0x328F7FDA,
+ .sdram_tim3 = 0x027F88A8,
+ .read_idle_ctrl = 0x00050001, /* not sure where in gel file */
+ .zq_config = 0x0007190B,
+ .temp_alert_config = 0x,
+ .emif_ddr_phy_ctlr_1_init = 0x0E24400A, /* not sure what to do about
this */
+ .emif_ddr_phy_ctlr_1= 0x0E24400A, /* based on non hw level
enabled */
+ .emif_ddr_ext_phy_ctrl_1 = 0x10040100, /* not sure wherein gel file */
+ .emif_ddr_ext_phy_ctrl_2 = 0x00740074,
[beagleboard] Re: [U-Boot] [PATCH v2 11/11] beagle_x15: add board support for Beagle x15
On Thu, Nov 6, 2014 at 8:44 AM, Felipe Balbi ba...@ti.com wrote:
BeagleBoard-X15 is the next generation Open Source
Hardware BeagleBoard based on TI's AM5728 SoC
featuring dual core 1.5GHZ A15 processor. The
platform features 2GB DDR3L (w/dual 32bit busses),
eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60),
separate LCD port, video In port, 4GB eMMC, uSD,
Analog audio in/out, dual 1G Ethernet.
For more information, refer to:
http://www.elinux.org/Beagleboard:BeagleBoard-X15
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
awesome - looks good to me. Thanks for doing this.
changes since v1:
new commit log
arch/arm/cpu/armv7/omap5/Kconfig | 4 +
board/ti/beagle_x15/Kconfig | 12 ++
board/ti/beagle_x15/Makefile | 8 +
board/ti/beagle_x15/board.c | 328
++
board/ti/beagle_x15/mux_data.h| 55 +++
configs/beagle_x15_defconfig | 5 +
include/configs/beagle_x15.h | 89 +++
include/configs/ti_omap5_common.h | 2 +
8 files changed, 503 insertions(+)
create mode 100644 board/ti/beagle_x15/Kconfig
create mode 100644 board/ti/beagle_x15/Makefile
create mode 100644 board/ti/beagle_x15/board.c
create mode 100644 board/ti/beagle_x15/mux_data.h
create mode 100644 configs/beagle_x15_defconfig
create mode 100644 include/configs/beagle_x15.h
diff --git a/arch/arm/cpu/armv7/omap5/Kconfig
b/arch/arm/cpu/armv7/omap5/Kconfig
index 129982c..aca862d 100644
--- a/arch/arm/cpu/armv7/omap5/Kconfig
+++ b/arch/arm/cpu/armv7/omap5/Kconfig
@@ -12,6 +12,9 @@ config TARGET_OMAP5_UEVM
config TARGET_DRA7XX_EVM
bool TI DRA7XX
+config TARGET_BEAGLE_X15
+ bool BeagleBoard X15
+
endchoice
config SYS_SOC
@@ -20,5 +23,6 @@ config SYS_SOC
source board/compulab/cm_t54/Kconfig
source board/ti/omap5_uevm/Kconfig
source board/ti/dra7xx/Kconfig
+source board/ti/beagle_x15/Kconfig
endif
diff --git a/board/ti/beagle_x15/Kconfig b/board/ti/beagle_x15/Kconfig
new file mode 100644
index 000..a305ff1
--- /dev/null
+++ b/board/ti/beagle_x15/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_BEAGLE_X15
+
+config SYS_BOARD
+ default beagle_x15
+
+config SYS_VENDOR
+ default ti
+
+config SYS_CONFIG_NAME
+ default beagle_x15
+
+endif
diff --git a/board/ti/beagle_x15/Makefile b/board/ti/beagle_x15/Makefile
new file mode 100644
index 000..5cd6873
--- /dev/null
+++ b/board/ti/beagle_x15/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2014
+# Texas Instruments, www.ti.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y := board.o
diff --git a/board/ti/beagle_x15/board.c b/board/ti/beagle_x15/board.c
new file mode 100644
index 000..5cafc87
--- /dev/null
+++ b/board/ti/beagle_x15/board.c
@@ -0,0 +1,328 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Felipe Balbi ba...@ti.com
+ *
+ * Based on board/ti/dra7xx/evm.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include palmas.h
+#include sata.h
+#include usb.h
+#include asm/omap_common.h
+#include asm/emif.h
+#include asm/arch/clock.h
+#include asm/arch/sys_proto.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/sata.h
+#include asm/arch/gpio.h
+#include environment.h
+
+#include mux_data.h
+
+#ifdef CONFIG_DRIVER_TI_CPSW
+#include cpsw.h
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+const struct omap_sysinfo sysinfo = {
+ Board: BeagleBoard x15\n
+};
+
+static const struct dmm_lisa_map_regs beagle_x15_lisa_regs = {
+ .dmm_lisa_map_3 = 0x80740300,
+ .is_ma_present = 0x1
+};
+
+void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs)
+{
+ *dmm_lisa_regs = beagle_x15_lisa_regs;
+}
+
+static const struct emif_regs beagle_x15_ddr3_532mhz_emif_regs = {
+ .sdram_config_init = 0x61851B32, /* dont know what to do about
this */
+ .sdram_config = 0x61851B32,
+ .sdram_config2 = 0x,
+ .ref_ctrl = 0x1035,
+ .sdram_tim1 = 0xCEEF266B,
+ .sdram_tim2 = 0x328F7FDA,
+ .sdram_tim3 = 0x027F88A8,
+ .read_idle_ctrl = 0x00050001, /* not sure where in gel file */
+ .zq_config = 0x0007190B,
+ .temp_alert_config = 0x,
+ .emif_ddr_phy_ctlr_1_init = 0x0E24400A, /* not sure what to do about
this */
+ .emif_ddr_phy_ctlr_1= 0x0E24400A, /* based on non hw level
enabled */
+ .emif_ddr_ext_phy_ctrl_1 = 0x10040100, /* not sure wherein gel file */
+ .emif_ddr_ext_phy_ctrl_2 = 0x00740074,
+ .emif_ddr_ext_phy_ctrl_3 = 0x00780078,
+ .emif_ddr_ext_phy_ctrl_4 = 0x007c007c,
+ .emif_ddr_ext_phy_ctrl_5 = 0x007b007b,
+ .emif_rd_wr_lvl_rmp_win = 0x,
+
[beagleboard] Cant flash image to BBB 4GB
Hello! I made some tests with DeviceTree and uEnv.txt on my BBB (eMMC). I have an error in my uEnv.txt and so I want to flash the eMMC new ... but can´t. I test another BBB, there it works. You find the boot log here: http://pastebin.com/CqQgZNPK Can some check what is wrong? Thanks a lot! -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: load device tree overlay through uEnv.txt on startup
The problem is that all that info is all over the places and changes all the time. I'd buy a BBB book to help me get organized and understand how to do things, but I'm afraid that changes would make the book obsolete by the time it arrived in the mail :-) So I think the only solution is to keep thinking of using the beaglebones as an adventure, and to take lots of notes. It would all be impossible if it weren't for the forums here -- so thanks for your post! -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: BeagleBone Black doesn't sometimes start. Only Power LED is on
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chu. On 2014-11-05 11:47, Mikkel Kirkgaard Nielsen wrote: As my modification also solves the issue, your assumption about your fix (a high level at J4.1/B_UART0_RX (U15.2/1A)) is not true. Sorry, J1.4 is the correct pin. I've now done tests with a stronger pulldown (1k in parallel with R165= 990 ohm) and a short directly to DGND/VDD_3V3B (I'll post details later, find them at http://www.mikini.dk/index.php/category/beaglebone-black). These tests confirm that B_UART0_RX can't be pulled down/up, to prevent the failure to occur. But forming a stable voltage on the input using a voltage divider (also using 0 ohm= short circuit!) does solve the problem. That is; whether we form a stable 0.58V or a stable 3.3V on B_UART0_RX the system will always boot. Does anybody have definite confirmation (by scope measurements) that U15.6 (1Y) really is flickering during early power? It would be exiting to do some experiments showing how it is affected by the U15.3 (1A) input. I think that is the core of this issue. We removed the R165 which is the pull down resistor on the UART0_RX line. The UART0_RX is around 1.4V and sometimes floating. We also checked the device tree. The internal pull up of the UART0_RX is turned on. [UART0_RX on 1.4V or floating] Peculiar, as it should never float. I haven't been able to replicate that measurement. I got 3V3 on UART0_RX (the one without B_, on the cpu side), except in early power up. I see the voltage flickering shortly just after power is applied, and in the same instance that kernel is loaded (USR0-USR3 leds starts lighting up) there also some activity. Are you sure that you actually did measure on U15.6? It isn't easy to place the probes right on those small pads. We do not know why the UART0_RX is not getting 3.3V, can you please check the voltage on both UART0_TX and UART0_RX when U15 is removed? I'll definitely look into this tomorrow. Including taking this measurement. Here they are, I see nothing unexpected here when things are static. I also checked the U15 supply, which seems to be ok. * BBB measurements on terminals of removed U15 ** Device Under Test: Modified Beaglebone Black produced by CircuitCo (PCB REV B6, serial 007142901445, marked beaglebone+ beagle logo and beagleboard.org). Modified by removing U15 (uart0 buffer chip: SN74LVC2G241) and its decoupling capacitor C155. ** Equipment *** Multimeter Brymen Elma BM515CF MOBILE LOGGER, MFG.#: 063391676. *** Power Supply Unit Huawei HW-050200E3W, output 5V 2A, USB A-connector. Danish plug. Sourced from Huawei E589 mobile wifi. *** Power Cable 20 cm no-name USB A male connector to USB Mini-B male connector. ** Procedure Apply power to BBB through USB Mini-B connector. Use multimeter to measure voltage levels on exposed U15 terminals and related supply lines to check possible supply voltage drop. COM probe fixed at DGND on decoupling capacitor (terminal C155.DGND farthest from PCB edge). ** Measurements C155.VDD_3V3B: 3.352V (terminal nearest to PCB edge) U15.1: _1OE = 0V U15.2: 1A= 0V U15.3: 2Y= floating (flickering +-0.000,50V) U15.4: GND = 0V U15.5: 2A = UART0_RX = 3.335V U15.6: 1Y = UART0_TX = 3.195V U15.7: 2OE = 3.352V U15.8: VCC = 3.352V J1.1 = DGND = 0.000,02 V P2.20 = GND5 = 0.000,02 V FB4.1 = VDD_3V3B = 3.351 V Regads, Even more regads, - -- Mikkel ,= ,-_-. =. ((_/)o o(\_)) `-'(. .)`-' \_/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUW47fAAoJEJ2luFWzaTSanH0H+gKv5DcQ/9NeX0vuf+9eIE3r 6mNho8sKbpWtx6uGcLRZzxEBLbU0NWnq/ePzhCzbWq7c/nEyXlYwtoa7hagJl7VT OGaqjxxvt3Ti/iVTLp1rtiCm97Uyi0DzOKxuM8SwFTQDXTjWdmp/2ArApJqETZUD PkpBABtfvFFWenks5rEpUYvQlI+a3SGL6nBHDmYdfD1bLExlM3ceKZ/rlCiIuHQa 8+Gj8BnoSfXO7FYk/3zUX13bBxEne2tdFgNtkOsqZK8/ut8G72jsrQwi2HmA1i1j 77CcoyTKUUeVwThcqx544pWDCvYx4FuAJz7dqIuTp3eNjHDN0JHcjNdemaL6O1M= =LasS -END PGP SIGNATURE- -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Seriously Confused
Thanks Brandon. Alas, the path used in the c_adc.c software just doesn't seem to exist in the Debian I'm using -- one of the big sources of confusion for me. I'm starting to think the only solution is to try to dig into the kernel source as Joshua suggests -- but that sounds like it might take more years than I have left :-) On Wednesday, November 5, 2014 4:24:01 PM UTC-6, Brandon I wrote: https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/source/c_adc.c The adc source for bbio should be useful. Keep in mind that these sysfs interfaces are incredibly slow compared to memory poking since each operation requires opening, reading/writing and closing the file. For example, with GPIO, you're limited to a few hundred khz (regardless of language since it's just file operations). With mmap and python, you can toggle at 3Mhz. C a bit faster. Kernel, 12Mhz. There are python and closing libraries that handle all of the memory poking. Also, check out libpruio. It will setup the pin muxing, and provides quick adc and GPIO support. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Disable boot messages
I have a Qt app which launches automatically but some boot messages appear on screen before it starts up. How can I disable these boot messages? I've tried 1. editing /etc/systemd/system/getty.target.wants/getty@tty1.service and commenting out ExecStart. 2. removing lightdm 3. checking /boot/uEnv.txt, it doesn't contain any console command ( https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/disable$20screen$20boot$20message|sort:date/beagleboard/765LGQ4a0bY/_wqpId-7C3IJ ) Thanks, James uname -a Linux beaglebone 3.8.13-bone67 #1 SMP Wed Sep 24 21:30:03 UTC 2014 armv7l GNU/Linux Messages include... [0.372552] omap2_mbox_probe: platform not supported [0.527489] tps65217-bl tps65217-bl: no platform data provided [0.614605] bone-capemgr bone_capemgr.9: slot #1: No cape found [0.651712] bone-capemgr bone_capemgr.9: slot #2: No cape found [0.688822] bone-capemgr bone_capemgr.9: slot #3: No cape found [0.707546] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed [0.741892] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8 [0.753606] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22 [0.760896] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Disable boot messages
On Thursday, November 6, 2014 3:43:00 PM UTC, James S wrote: I have a Qt app which launches automatically but some boot messages appear on screen before it starts up. How can I disable these boot messages? I've tried 1. editing /etc/systemd/system/getty.target.wants/getty@tty1.service and commenting out ExecStart. 2. removing lightdm 3. checking /boot/uEnv.txt, it doesn't contain any console command ( https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/disable$20screen$20boot$20message|sort:date/beagleboard/765LGQ4a0bY/_wqpId-7C3IJ ) Thanks, James uname -a Linux beaglebone 3.8.13-bone67 #1 SMP Wed Sep 24 21:30:03 UTC 2014 armv7l GNU/Linux Messages include... [0.372552] omap2_mbox_probe: platform not supported [0.527489] tps65217-bl tps65217-bl: no platform data provided [0.614605] bone-capemgr bone_capemgr.9: slot #1: No cape found [0.651712] bone-capemgr bone_capemgr.9: slot #2: No cape found [0.688822] bone-capemgr bone_capemgr.9: slot #3: No cape found [0.707546] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed [0.741892] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8 [0.753606] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22 [0.760896] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single uEnv.txt command line cmdline=quiet init=/lib/systemd/systemd -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: libpruio-0.2
I've tested that code but it produces an error for me:
MURX: 4294967285
config failed (failed executing Pru_Run instructions)
This is the code I used
#include unistd.h
#include stdio.h
#include ../c_wrapper/pruio.h
int main(int argc, char **argv)
{
int n;
pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1);
pruio_adc_setStep(io, 9, 4, 0, 0, 0); // step 9 for AIN-4
if (pruio_config(io, 0, 1 9, 6285, 0)){ // '1 9' - step 9, '6285'
ns - 159.1 kHz
printf(config failed (%s)\n, io-Errr);}
else{
pruio_rb_start(io);
for(n = 1; n = 1000; n++){
printf(%u\n, io-DRam[0]);
sleep(1);
}
}
pruio_destroy(io);
return 0;
}
Greetings,
Nils Kohrs
--
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.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] Understanding how to partition the eMMC/SD card
Hi
I've been following the steps at
https://eewiki.net/display/linuxonarm/BeagleBone+Black; Trying build the
latest mainline kernel with the minimum Debian filesystem.
I don't quite understand what is happening in the following steps under Setup
microSD/SD card
*sudo dd if=/dev/zero of=${DISK} bs=1M count=10sudo dd if=./u-boot/MLO
of=${DISK} count=1 seek=1 conv=notrunc bs=128ksudo dd
if=./u-boot/u-boot.img of=${DISK} count=2 seek=1 conv=notrunc bs=384kCreate
Partition Layout:sudo sfdisk --in-order --Linux --unit M ${DISK}
-__EOF__1,,0x83,*__EOF__Format Partitions:for: DISK=/dev/mmcblk0sudo
mkfs.ext4 ${DISK}p1 -L rootfs*
I realise the a card is being wiped and then formatted but I'm not sure
why.
The default Debian sd card image (and other images I found) Have separate
boot partition, however in this example only one partition is created.
Why is this tutorial different?
Is it just a new feature of U-boot?
Also after following the all the steps in the tutorial the the beagelbone
black will boot from the SD card but it will hang on the line net eth0:
phy 4a101000.mdio:01 not found on slave 1 for about 30 sec before showing
the login prompt but that is probably a question for another thread.
David
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel
Hi Robert, Thanks for the help .. Finally, I am Successful in booting the u-boot with the blank EEPROM . but now the kernel booting stopped at certain point, it hangs trying to mount the rootfs (/dev/mmcblk0p2). *Waiting for root device /dev/mmcblk0p2...* after this print it got stuck over there. I have already tried with BBB (without EEPROM) using the same build images and it also hangs at the same place. Any help in solving this will be appreciated On Friday, October 31, 2014 7:36:21 PM UTC+5:30, RobertCNelson wrote: On Thu, Oct 30, 2014 at 10:50 PM, nishikan...@gmail.com javascript: wrote: Hi Andrew, Now we are using one customized board based on Beaglebone Black Design. In case of BBB TI is writing some board type configuration in the EEPROM, so during the Initial booting process it reads those information and configures the board accordingly. As we are using one fresh board we don't have anything written into the EEPROM, because of which it is failing at the U-boot every time with some errors like: U-Boot SPL 2013.01.01-00129-g6d40c2a-dirty (Oct 30 2014 - 09:58:22) Incorrect magic number (0x) in EEPROM I have tried to skip the read_eeprom () in the u-boot which reads the EEPROM header for board type, also done the Pin muxing in board/ti/am335x/mux.c but didn't get any better result out of this. As per my knowledge if we will write the same Configuration into the EEPROM as BBB then the board will boot properly. but we want to avoid that procedure. so could you please tell me is there any other method to solve this issue. Looking for a quick response from your end .. See this patch for reference (yes it's v2014.10) It is what CircuitCo uses to boot blank eeprom boards. https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.10/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch Regards, -- Robert Nelson http://www.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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: [U-Boot] [PATCH 11/11] beagle_x15: add board support for Beagle x15
On Thu, Nov 06, 2014 at 08:35:41AM -0600, menon.nisha...@gmail.com wrote: On Thu, Nov 6, 2014 at 8:28 AM, Felipe Balbi ba...@ti.com wrote: This is the bare minimum support for Beagle x15 into u-boot. There is still quite some work in order to get this in good shape, but it's a start. Sorry, I should have commented earlier :) we could expand this a little more here? How about: BeagleBoard-X15 is the next generation Open Source Hardware BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ A15 processor. The platform features 2GB DDR3L (w/dual 32bit busses), eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60), separate LCD port, video In port, 4GB eMMC, uSD, Analog audio in/out, dual 1G Ethernet. For more information, refer to: http://www.elinux.org/Beagleboard:BeagleBoard-X15 ofcourse - the wiki is yet to be built up.. will do, it has been a while since this stopped being bare minimum anyway. It's actually pretty complete from u-boot's point of view. -- balbi signature.asc Description: Digital signature
[beagleboard] Re: PRU0 base address
The PRU does need to be enabled, typically by a Device Tree entry similar
to this:
fragment@4 {
target = pruss;
__overlay__ {
status = okay;
};
};
If using a cape of some kind, this would normally be in the device tree
setup for that cape.
If it's your own custom cape, you would need to add this to your device
tree file.
There may also be a suitable device tree overlay already installed in
/lib/firmware that you can simply enable, but I don't have my BBB in front
of me right now to check.
On Wednesday, November 5, 2014 11:19:34 PM UTC-8, Karl Karpfen wrote:
OK, the base address seems to be correct. Nevertheless CTRL-register isn
ot readable, so it seems some important PRU-initialisations are missing. So
is there any clock or power that has to be turned on for PRU?
Am Dienstag, 4. November 2014 17:54:03 UTC+1 schrieb Karl Karpfen:
OK, I'm sure it is a stupid question but I don't find it in AM335x
TRM...there the offset of PRU_CTRL-register is defined with 0x. But
what is the base address? I found a definition 0x4a322000 in one of
Starterware headers but this seems to be wrong.
So what is correct base address for PRU0 registers and RAM areas?
--
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.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: PRU0 base address
Hey man, You should read this PDF file. It helps a lot. http://mythopoeic.org/BBB-PRU/am335xPruReferenceGuide.pdf From there most of your doubts will surely be solved. If not, keep posting. Best of luck, Jose On Tuesday, November 4, 2014 10:54:03 AM UTC-6, Karl Karpfen wrote: OK, I'm sure it is a stupid question but I don't find it in AM335x TRM...there the offset of PRU_CTRL-register is defined with 0x. But what is the base address? I found a definition 0x4a322000 in one of Starterware headers but this seems to be wrong. So what is correct base address for PRU0 registers and RAM areas? -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Changes to be made to create a patch for rtl8192eu
Patch for linux driver rtl8192eu version rtl8192EU_linux_v4.3.1.1_11320.20140505 Works with kernel 3.6.x through 3.17.x http://users.telenet.be/x86_64/Patches/rtl8192eu-k3.13.patch On Monday, June 16, 2014 2:07:48 PM UTC+2, Sibi Sankar wrote: Resources on the internet provide heavy support for rtl8192cu however I find minimal support for rtl8192eu based wifi adapter that I had purchased with the BBB. The github resource on patch for rtl8192cu can it also be followed for rtl8192eu.I try to patch it manually but I find a lot of difference between the two . The only resource that I gave me hope that I could get it working is a post on rtl8192eu in raspberry pi.Could someone guide me about the changes that need to incorporated in rtl8192eu to get 8192eu.ko.Any help would be appreciated.Thank you. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Bone VDD_3V3EXP Disable Issues
Pinging this group again in hopes for some advice or info or updates: Has anyone successfully shutdown the PMIC from software while on battery pwr? I can confirm the board mod works, but now I'm facing a qty 100 order! That's too much rework for me, so I can't place an order until I have a reasonable resolution. Thanks, JP On Saturday, July 19, 2014 11:12:20 AM UTC-6, JohnP wrote: I just learned the hard way that there's a shutdown difference in the Rev C boards vs. Rev A5, so I'm glad to find this thread. I confirmed with 'i2cdump -f 0 0x24' that register 0x0Ah = 84 which means it IS configured to enter OFF mode when the button is pushed. Should the 'pmic-shutdown-controller' code change still be made? Is there a better way to get the PMIC into OFF mode when the button is pushed? I really need this function so the battery isn't drained during extended off time. I'm 2 for 2 with Rev C boards that act this way, so I assume it's common. Thanks for any help, JP On Thursday, June 26, 2014 8:53:36 PM UTC-6, john3909 wrote: From: Terry smit...@gmail.com Reply-To: beagl...@googlegroups.com beagl...@googlegroups.com Date: Thursday, June 26, 2014 at 1:01 PM To: beagl...@googlegroups.com beagl...@googlegroups.com Cc: and...@bradfordembedded.com Subject: [beagleboard] Re: Bone VDD_3V3EXP Disable Issues Does anyone know if there is a software solution to this issue? I haven't seen any changes in the recent hardware revisions to address this. We are currently planning on deploying a couple of dozen BBB and I would prefer not having to make hardware mods. I’ve just been looking into the PMIC for another user and this is probably a configuration issue. The PMIC supports several modes (page 15 of the TPS65217C datasheet). I believe the PMIC isn’t configured to enter OFF mode, but rather it is entering SLEEP mode which means any rails not controlled by the power-down sequencer will remain enabled in SLEEP mode. Here is what I think the solution might be: Add pmic-shutdown-controller as shown in /Documentation/devicetree/bindings/regulator/tps65217.txt. In the V3.15.1-bone2 kernel, /drivers/mfd/tps65217.c line 213, the comments “Set the PMIC to shutdown on PWR_EN toggle”. This should work for all kernel V3.8 onwards. Reading “Power Down Sequence” on page 18 (TPS65217C datasheet), this will initiate the power down sequence and leave the PMIC in OFF mode. I want to confirm this with Robert Nelson first before proceeding; however, you can add pmic-shutdown-controller” as described in the kernel docs to /arch/arm/boot/dts/tps65217.dtsi and see if this works for you. Regards, John Terry On Thursday, January 30, 2014 12:34:51 PM UTC-5, Brad Andersen wrote: An update: For the A6 (Beaglebone Black) version, I connected U4 pin 1 (enable) back to VDD_3V3AUX (same as A5C). It now shuts down correctly while on battery. This was verified on two A6 BBB. The mystery is what causes the VDD_3V3A to hang up on the A6 version when shutting down while on battery. -- 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...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3.17.1-rc4 sudden reset
I followed up on the USB OTG hint as mentioned in my previous post. I patched the dtb for the bbb so that the mini usb port runs as peripheral and not as OTG. The patch was deployed to 7 systems so far and they all are stable (no reboot) since then on any of the systems. The uptime is more than 3 days now. If interested, I can post more details. On Tuesday, November 4, 2014 3:01:53 PM UTC+1, Ives van der Flaas wrote: Have you had *any* resets since the upgrade to the new u-boot version? I've also been suspecting u-boot, hence my Meaning that I'm also running an old u-boot. in the last post. Op dinsdag 4 november 2014 00:18:43 UTC+1 schreef david turvene: On Saturday, November 1, 2014 3:24:33 PM UTC-4, david turvene wrote: The system runs fine when I'm not messing around with the plugs, changing the wifi properties, or sniffing. When I do any of these the system occasionally silently reboots - I've been able to test up to 20 sniffing sessions before it reboots, sometimes it will reboot immediately when I start an monitor session. * I run the BBB headless, generally using SSH xterm. * The silent reboot happens with NO indication. NOTHING. The uart console just shows a system restart. * I triggered a watchdog NMI (it takes 22 seconds) and it showed a lot of diagnostic info - so that's not it. Further research - similar behavior was reported last year. Lot's of red herrings (USB control appeared to be the most suspicious because that's my main interface but also long threads blaming the power management unit.) Someone found that another clock source was needed for low-power state and moved the new code into u-boot. I was running with a local build from RCN's git repo described at: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot and 2014.7 baseline. I noticed it is now at 2014.10 so I rebuilt and installed on target. The system is much more stable after testing for a lot longer than I could before. And I'm pretty sure the clocking/power is the root cause of the silent reboots so I'm checking how the clock change, to the RTC32K clock, works. Also, since I'm running from emmc, I used am335x_boneblack_defconfig to build u-boot. The only difference is it sets EMMC_BOOT but a quick grep shows it changes logic in a couple places. Anyway, it's a start... -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Custom Beaglebone Black does not bootup unless UART0 port is used
I have the same exact problem with a stock Beaglebone Black a5a board. The board used to work fine. I shut it down for a few months. I went to plug it in and no usr lights flashed. Only the power light flashed. I as you, went to see what was wrong and hooked up a USB to serial on the UART rx, tx, gd to see the output. As soon as I applied power to the board it booted with an SD card. When I take the SD card out it boots as well. However if I don't have anything hooked up to the UART rx, tx, gd no boot, just a power light comes on. Does anyone know how to fix this permanently or what has caused this? On Thursday, January 9, 2014 11:14:01 PM UTC-8, nitesh singh wrote: Hi, I am using a customised Beaglebone Black, whose schematics is very close to Original Beaglebone Black. You can say we cloned the Beaglebone black hardware and assembled the board. Now I used Robert C Nelson's Debian wheezy emmc flasher image sd card to boot it for first time , and wrote the emmc. Then I dumped binary data copied from EEPROM of one of the original beaglebone black's eeprom to the eeprom on this. So, now the issue that i am facing is that, this board will not boot up again from emmc or another sd card that i use, other than the flasher sd card. Then accidently or by chance, i tried to look at its UART0 port from UART port on the other beaglebone black and it booted up as usual. After that i observed that this customised beaglebone black is booting only when the UART0 is accessed on another Beaglebone black or just simply connected to its UART. What can be the problem here ? The emmc flashed on another original beaglebone black is working fine, just this customised board will not boot in the usual manner. I was reading through the minicom output at UART0 for this custom board, it gave some read errors, and also said that mmcblk0boot0 and mmcblk0boot1 does not valid partition table. What are these partitions and is it possible to write or create any partitions on them ? I have seen that they are there on other beaglebone blacks and mmcblk0 changes to mmcblk1 if booted from sd card, I could not understand its function. Is this creating any problem with the bootup ? I suspect the eeprom data also might be causing this error. I have attached the minicom output file for the custom board's UART0 port while it was booting. One more thing, it seems, connecting only DGND and UART0_RX to another board is sufficient to make it boot. So it is reading some data over Uart0, is it to do with eeprom ? Please help. Thanks and regards, Nitesh -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Getting Beaglebone Black Rev. B to display UI on 24 bit LCD
Hello together, I am new to Beaglebone Black (and embedded linux). I am trying to get an external LCD with 18bit or 24bit Interface to work on the Beaglebone Black. The LCD I am using is a Kyocera T-55343GD035JU-LW-ADN with 320x240 pixel and 24 bit colordepth. ( http://www.kyocera-display.com/products/partdetail.asp?PartNumber=T-55343GD035JU-LW-ADN) I wrote my own Devicetree-Overlay based on cape-bone-lcd3-00A0.dts at /lib/firmware without the Touchscreen and Keys, but have added the additional pins for lcd_data 16 to 23 and changed the bpp in the panel info to 24. The LCD itself works and it boot to the GUI on Angström or Debian, but i only get lcd_data 0 -15 to work. Bits 16 to 23 doesn't have any data on them. When I add video=LVDS-1:320x240-24@60 to the uEnv.txt file like it is written here: http://elinux.org/24bit_LCD_for_BBB, I get many errors in dmesg starting with [4.185659] WARNING: at drivers/gpu/drm/tilcdc/tilcdc_crtc.c:245 tilcdc_crtc_mode_set+0x2f/0x460() So this doesnt work. Changing the DefaultDepth at X11 config file changes the color-order from RGB to BGR (how it should be at 24bit) at least with the Angstrom OS. At Debian the Xserver doesnt start any more with this option. At Angstrom the color-order is fine but the bits 16 to 23 doesnt work at all (No Data on this lines). I also tried to change the depth of the framebuffer with fbset -depth 24 but get only the error : fbset: FBIOPUT_VSCREENINFO: Invalid argument When I read the documentation of the fbdev driver at the ti website, there is written that the beaglebone should work at 24 (or 32 bit) without any Probems. (Here http://processors.wiki.ti.com/index.php/AM335x_LCD_Controller_Driver%27s_Guide and here http://processors.wiki.ti.com/index.php/Linux_Core_LCD_Controller_User_Guide#AM335x_LCDC_Display_Driver_.28DRM.29 ) What am I doing wrong? Can anyone please try to help me find my errors? Thanks for your help Harald -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Getting an LCD-Display to Work with 24 bits on an Beaglebone Black
Hello together, I am new to Beaglebone Black (and embedded linux). I am trying to get an external LCD with 18bit or 24bit Interface to work on the Beaglebone Black. The LCD I am using is a Kyocera T-55343GD035JU-LW-ADN with 320x240 pixel and 24 bit colordepth. ( http://www.kyocera-display.com/products/partdetail.asp?PartNumber=T-55343GD035JU-LW-ADN) I wrote my own Devicetree-Overlay based on cape-bone-lcd3-00A0.dts at /lib/firmware without the Touchscreen and Keys, but have added the additional pins for lcd_data 16 to 23 and changed the bpp in the panel info to 24. The LCD itself works and it boot to the GUI on Angström or Debian, but i only get lcd_data 0 -15 to work. When I add video=LVDS-1:320x240-24@60 to the uEnv.txt file like it is written here: http://elinux.org/24bit_LCD_for_BBB, I get many errors in dmesg starting with [4.185659] WARNING: at drivers/gpu/drm/tilcdc/tilcdc_crtc.c:245 tilcdc_crtc_mode_set+0x2f/0x460() So this doesnt work. Changing the DefaultDepth at X11 config file changes the color-order from RGB to BGR (how it should be at 24bit) at least with the Angstrom OS. At Debian the Xserver doesnt start any more with this option. At Angstrom the color-order is fine but the bits 16 to 23 doesnt work at all (No Data on this lines). I also tried to change the depth of the framebuffer with fbset -depth 24 but get only the error : fbset: FBIOPUT_VSCREENINFO: Invalid argument When I read the documentation of the fbdev driver at the ti website, there is written that the beaglebone should work at 24 (or 32 bit) without any Probems. (Here http://processors.wiki.ti.com/index.php/AM335x_LCD_Controller_Driver%27s_Guide and here http://processors.wiki.ti.com/index.php/Linux_Core_LCD_Controller_User_Guide#AM335x_LCDC_Display_Driver_.28DRM.29 ) What am I doing wrong? Can anyone please try to help me find my errors? Thanks for your help Harald -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Disable USB mass storage
In my Debian I did
sudo nano /opt/scripts/boot/am335x_evm.sh
You could comment out line shown below, but it would disable Ethernet.
#modprobe g_multi file=${gadget_partition} cdrom=0 stall=0 removable=1
nofua=1 iSerialNumber=${SERIAL_NUMBER} iManufacturer=Circuitco
iProduct=BeagleBone${BLACK} host_addr=${cpsw_1_mac}
add this to have Ethernet
modprobe g_ether host_addr=${cpsw_1_mac}
On Thursday, February 6, 2014 9:05:59 AM UTC-5, ka...@silvertejp.nu wrote:
When I connect the BeagleBone Black to my PC it shows up as as USB mass
storage device. Is there some way that I can disable this function? I want
to use Ethernet over USB but I don't want it to act as a storage device.
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3.17.1-rc4 sudden reset
I have followed the USB OTG hint as mentioned in my previous post. I patched the dtb for the bbb so that the mini usb port runs as peripheral and not as OTG. The patch was deployed to 7 systems so far and they all are stable (no reboot) since then on any of the systems. The uptime is more than 3 days now. On 4 Nov 2014 15:02, Ives van der Flaas ives@gmail.com wrote: Have you had *any* resets since the upgrade to the new u-boot version? I've also been suspecting u-boot, hence my Meaning that I'm also running an old u-boot. in the last post. Op dinsdag 4 november 2014 00:18:43 UTC+1 schreef david turvene: On Saturday, November 1, 2014 3:24:33 PM UTC-4, david turvene wrote: The system runs fine when I'm not messing around with the plugs, changing the wifi properties, or sniffing. When I do any of these the system occasionally silently reboots - I've been able to test up to 20 sniffing sessions before it reboots, sometimes it will reboot immediately when I start an monitor session. * I run the BBB headless, generally using SSH xterm. * The silent reboot happens with NO indication. NOTHING. The uart console just shows a system restart. * I triggered a watchdog NMI (it takes 22 seconds) and it showed a lot of diagnostic info - so that's not it. Further research - similar behavior was reported last year. Lot's of red herrings (USB control appeared to be the most suspicious because that's my main interface but also long threads blaming the power management unit.) Someone found that another clock source was needed for low-power state and moved the new code into u-boot. I was running with a local build from RCN's git repo described at: https://eewiki.net/display/linuxonarm/BeagleBone+Black# BeagleBoneBlack-Bootloader:U-Boot and 2014.7 baseline. I noticed it is now at 2014.10 so I rebuilt and installed on target. The system is much more stable after testing for a lot longer than I could before. And I'm pretty sure the clocking/power is the root cause of the silent reboots so I'm checking how the clock change, to the RTC32K clock, works. Also, since I'm running from emmc, I used am335x_boneblack_defconfig to build u-boot. The only difference is it sets EMMC_BOOT but a quick grep shows it changes logic in a couple places. Anyway, it's a start... -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/RMOTnQBgIo8/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Initialize system time on boot (wireless)
I am a little confused on systemd setup here. So, my BBB loses its time on bootup. I know that is expected because there is not hardware clock. I also see that ntpdate is supposed to run once a day in cron.daily. However, I really want the system to get the correct time on bootup. I am running wireless (set to auto), so I need this to run after the wireless connection is made. In syslog, I do see the date being set on bootup, but it is off by years. And in /lib/systemd, I see timedated and time-sync. They appear to be in systemd, but never loaded. I see other documentation that refers to ntpupdate.service, but that doesn't exist here. So far, I tried installing and uninstalling apt-get install ntp. I linked /etc/localtime to my timezone in /usr/share (America/Los_Angeles). I also set /etc/adjtime to LOCAL instead of UTC. So far, I haven't had any luck. Mostly, I am just unsure of where to even configure things. I am really unfamiliar with systemd. Thanks. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Problem with Bonescript I2C
Greetings,
I am trying to use ADS7828 which is an 8-channel I2C ADC from TI. I am
using javascript to accomplish this task. I am using the latest version of
bonescript.
I have added this line: echo BB-I2C1 /sys/devices/bone_capemgr.9/slots
to /etc/profile.d/node.sh to execute upon power up or reset.
Executing ls -l /sys/bus/i2c/devices/i2c-*, gives the following results:
lrwxrwxrwx 1 root root 0 May 15 04:39 /sys/bus/i2c/devices/i2c-0 -
../../../devices/ocp.3/44e0b000.i2c/i2c-0
lrwxrwxrwx 1 root root 0 May 15 04:39 /sys/bus/i2c/devices/i2c-1 -
../../../devices/ocp.3/4819c000.i2c/i2c-1
lrwxrwxrwx 1 root root 0 Nov 4 16:27 /sys/bus/i2c/devices/i2c-2 -
../../../devices/ocp.3/4802a000.i2c/i2c-2
Here is my code:
var b = require(bonescript)
var port = '/dev/i2c-2';
b.i2cOpen(port, 0x49, {});
testADC();
function testADC()
{
// Internal Voltage Reference 2.5V
// Single-ended conversion
// channel number address is kind of weird on this chip
var channelNumber = [0x00, 0x04, 0x01, 0x05, 0x02, 0x06, 0x03, 0x07];
var channelOutput = [0, 0, 0, 0, 0, 0, 0, 0];
var n;
//b.i2cOpen(port, 0x49);
for (n = 0; n 8; n++)
{
channelOutput[n] = readADCchannel(channelNumber[n]);
}
}
function readADCchannel (adcChannelNumber)
{
var command;
var singleEnded = 0x80;
var voltageReference = 0x0C;
var buffer = [];
command = singleEnded + (adcChannelNumber 4) + voltageReference;
// send command to start conversion
*b.i2cWriteByte(port, command);*
// Conversion should start immediately
console.log(command);
// serves as a time delay
for (var x = 0; x 30; x++)
{
}
// read the conversion result
*buffer = b.i2cReadBytes(port, {} , 2);*
console.log(Buffer0 = + buffer[0]);
console.log(Buffer1 = + buffer[1]);
var voltage = ((buffer[1] + (buffer[0] * 256)) * 2500) / 4096;
var s = Output Voltage of Channel: + adcChannelNumber + = +
voltage + mv;
console.log(s);
return voltage;
}
I am using Cloud9 to debug this. I put two break points where I am writing
to and reading from the chip. I am using a Gabotronics Xmega Xminilab to
read the I2C exchange between the BBB and the ADC converter.
http://www.gabotronics.com/development-boards/xmega-xminilab.htm
After executing the b.i2cWriteByte((port, command); I correctly see the
following bytes on the Xminilab display 49 8C+ the indicates a write
cycle to address 0x49 which is the ADC address and the + sign indicates an
ack from the ADC. If I execute the b.i2cReadBytes(port, {} , 2); command
I see the following: 49 00+ 49 00+ 00- . The 49 00+ indicates another
write cycle with 00 command , the indicates a read cycle from address
0x49 followed by the two bytes that I am interested in, basically the ADC
reading, the - sign indicates no ack..
The question is where is the second write cycle coming from? It basically
screws up the ADC reading and all I get is a zero reading from the ADC.
So, what am I doing wrong here? I can't use i2cReadByte because the ADC
outputs 2 bytes as a result of read request.
This is driving me crazy.
Thanks in advance,
Mostafa
--
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.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] Disable UART1 Echo
Hello All, I am working with the stock Debian distribution of Beagle Bone Black (rev C). I run the following command to enable UART 1 : echo BB-UART1 /sys/devices/bone_capemgr.*/slots and it works fine i.e. I am able to see ttyO1 listed in /dev and also able to transmit commands to a remote terminal. However, when I send anything from the terminal to BBB, I observe that the same data is echoed by BBB back to the terminal! How do I disable this? I went through the stty commands but nothing relevant there. Thanks! -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Enable UART1
Apologies for the delayed response. I work on this project mostly on weekends. I had given up on editing uEnv.txt , but what worked for me was running the below command : echo BB-UART1 /sys/devices/bone_capemgr.*/slots On Saturday, October 25, 2014 11:10:10 PM UTC-4, Jimit Doshi wrote: Hello All, I plan to use UART1 and UART2 of BBB for an application. I understand that only UART0 (which is any ways used for debug purpose) is enabled by default. As such, I see only 'ttyO0' in my '/dev/' directory. To enable UART1/2 , I added the following line in my uEnv.txt file : #optargs=capemgr.enable_partno = BB-UART1,BBUART2 However, on reboot I don't see 'ttyO1' and 'ttyO2' in my '/dev/' directory. What am I missing? Thanks! PS : I am using the BBB rev C with the stock Debian distribuition. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Computer Hardware and Software
Banned. On Thursday, November 6, 2014 10:47:31 AM UTC-5, William Hermans wrote: So perhaps this long list of partners you mention needs to be notified that one of their partners has stooped to spamming google groups that have nothing to do with your so-called skews ? I very seriously doubt you're anyone, hardly worth even this reply. On Thu, Nov 6, 2014 at 4:16 AM, Tecmeout Sales tecme...@gmail.com wrote: Tecmeout is an innovative and fast growing value added reseller of *technology products and services* http://www.tecmeout.com/for businesses, government and education. Our goal is to make technology procurement simple and easy by offering the highest level of service available in the industry. We offer the latest technology and commercial products that businesses require to run their operations effectively. Our products include computer hardware, software and peripherals such as notebooks, desktops, servers, storage devices, networking devices, printers, display, office equipment and supplies. We have over one million unique skews on our website and are partnered with hundreds of the most respected manufacturers in the industry, including Hewlett Packard, Cisco, Lenovo, Netgear, Microsoft and dozens of other major manufacturers. Our direct relationships with industry leaders allows us to offer very competitive pricing and unmatched customer service. For more info Visit: www.tecmeout.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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: libpruio-0.2
Hey TJF,
with 6285 ns I was only able to set the amount of samples to 1 without
getting an error. With 6290 works everything fine.
Here is some c samplecode for you, it keeps writing all the samples to a
file in burst of 100/4 samples per writing burst.
#include unistd.h
#include stdio.h
#include ../c_wrapper/pruio.h
//! The main function.
int main(int argc, char **argv)
{
FILE* oFile;
uint8 bDiv = 4, bStep;
uint32 bSize = 1e6;
uint32 bsSize = bSize/bDiv;
oFile = fopen(output,wb);
pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new
driver structure
pruio_adc_setStep(io, 9, 4, 0, 0, 0); // step 9 for AIN-4
if (pruio_config(io, bSize, 1 9, 6290, 0)){ // '1 9' - step 9,
'6285' ns - 159.1 kHz
printf(config failed (%s)\n, io-Errr);}
else{
pruio_rb_start(io);
sleep(1);
while(1){
while(io-DRam[0] (bStep+1) * bsSize io-DRam[0] bStep * bsSize
){
sleep(1);
}
printf(start writing %u\n,bStep*bsSize);
fwrite(io-Adc-Value, sizeof(uint16), 16000, oFile);
printf(end writing %u\n,(bStep+1)*bsSize);
bStep = bStep+1 bDiv ? bStep+1 : 0;
}
}
pruio_destroy(io);
return 0;
}
Greetings,
Nils Kohrs
--
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.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] TI PRU cape available now for $39
There is some software associated with it as well, but I haven't tried it yet. Placed an order for mine---you'd think they'd be smart enough within TI to send me one AHEAD of the announcement, but whatever. I created a project page at http://beagleboard.org/project/prucape/ Also, I was told on G+ that Micro Center has the Element14 BeagleBone Blacks available for $39. I confirmed they had boards at my local store. Not sure why the fire-sale pricing, but I don't see why not to take advantage of it and pick up a couple extra boards! -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: [PATCH] ARM: dts: Add am57xx-beagle-x15
On Thu, Nov 06, 2014 at 10:18:22AM -0600, Nishanth Menon wrote:
BeagleBoard-X15 is the next generation Open Source Hardware
BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ A15
processor. The platform features 2GB DDR3L (w/dual 32bit busses),
eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60), separate LCD
port, video In port, 4GB eMMC, uSD, Analog audio in/out, dual 1G
Ethernet.
For more information, refer to:
BeagleBoard-X15 Wiki:
http://www.elinux.org/Beagleboard:BeagleBoard-X15
AM5728 is part of the Sitara product family whose additional details
will be available: http://www.ti.com/lsds/ti/arm/overview.page
Technical Reference Manual for AM5728 is public domain at:
http://www.ti.com/lit/spruhz6
Just add basic support for the moment, the following updates are needed:
i) Ethernet - depends on SoC dts fixes
ii) USB Client (USB2) - depends on GPIO extcon
ii) HDMI - additional driver fixes pending
iii)Audio - additional driver fixes pending
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Tested with omap2plus_defconfig modified as: http://slexy.org/view/s2DRTzUwjj
boot log: http://slexy.org/raw/s25Grf1uoo
based on 3.18-rc1 tag.
Support for u-boot has been posted as well: (series ending
http://patchwork.ozlabs.org/patch/407552/ )
Side note: this patch generates a few unrelated checkpatch warning for
compatible which probably is part of appropriate driver documentation
fixes (functionality is already present).
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/am57xx-beagle-x15.dts | 405
+++
2 files changed, 406 insertions(+)
create mode 100644 arch/arm/boot/dts/am57xx-beagle-x15.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38c89ca..eee1e4f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -347,6 +347,7 @@ dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
omap5-sbc-t54.dtb \
omap5-uevm.dtb
dtb-$(CONFIG_SOC_DRA7XX) += dra7-evm.dtb \
+ am57xx-beagle-x15.dtb \
dra72-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-d2-network.dtb \
orion5x-lacie-ethernet-disk-mini-v2.dtb \
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
new file mode 100644
index 000..1f1875b
--- /dev/null
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -0,0 +1,405 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include dra74x.dtsi
+#include dt-bindings/clk/ti-dra7-atl.h
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/interrupt-controller/irq.h
+
+/ {
+ model = TI AM5728 BeagleBoard-X15;
+ compatible = ti,am572x-beagle-x15, ti,am5728, ti,dra742,
ti,dra74, ti,dra7;
+
+ aliases {
+ rtc0 = mcp_rtc;
+ rtc1 = tps659038_rtc;
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1GB to start. Target 2GB */
1GiB ? Why would you put this here btw ? u-boot fills this one up.
--
balbi
signature.asc
Description: Digital signature
[beagleboard] Re: [PATCH] ARM: dts: Add am57xx-beagle-x15
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/06/2014 11:32 AM, Felipe Balbi wrote:
On Thu, Nov 06, 2014 at 10:18:22AM -0600, Nishanth Menon wrote:
BeagleBoard-X15 is the next generation Open Source Hardware
BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ
A15 processor. The platform features 2GB DDR3L (w/dual 32bit
busses), eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60),
separate LCD port, video In port, 4GB eMMC, uSD, Analog audio
in/out, dual 1G Ethernet.
For more information, refer to: BeagleBoard-X15 Wiki:
http://www.elinux.org/Beagleboard:BeagleBoard-X15
AM5728 is part of the Sitara product family whose additional
details will be available:
http://www.ti.com/lsds/ti/arm/overview.page
Technical Reference Manual for AM5728 is public domain at:
http://www.ti.com/lit/spruhz6
Just add basic support for the moment, the following updates are
needed: i) Ethernet - depends on SoC dts fixes ii) USB Client
(USB2) - depends on GPIO extcon ii) HDMI - additional driver
fixes pending iii) Audio - additional driver fixes pending
Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by:
Nishanth Menon n...@ti.com ---
Tested with omap2plus_defconfig modified as:
http://slexy.org/view/s2DRTzUwjj boot log:
http://slexy.org/raw/s25Grf1uoo based on 3.18-rc1 tag.
Support for u-boot has been posted as well: (series ending
http://patchwork.ozlabs.org/patch/407552/ )
Side note: this patch generates a few unrelated checkpatch
warning for compatible which probably is part of appropriate
driver documentation fixes (functionality is already present).
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/am57xx-beagle-x15.dts | 405
+++ 2 files changed, 406
insertions(+) create mode 100644
arch/arm/boot/dts/am57xx-beagle-x15.dts
diff --git a/arch/arm/boot/dts/Makefile
b/arch/arm/boot/dts/Makefile index 38c89ca..eee1e4f 100644 ---
a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@
-347,6 +347,7 @@ dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
omap5-sbc-t54.dtb \ omap5-uevm.dtb dtb-$(CONFIG_SOC_DRA7XX) +=
dra7-evm.dtb \ + am57xx-beagle-x15.dtb \ dra72-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-d2-network.dtb \
orion5x-lacie-ethernet-disk-mini-v2.dtb \ diff --git
a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts new file mode 100644
index 000..1f1875b --- /dev/null +++
b/arch/arm/boot/dts/am57xx-beagle-x15.dts @@ -0,0 +1,405 @@ +/* +
* Copyright (C) 2014 Texas Instruments Incorporated -
http://www.ti.com/ + * + * This program is free software; you can
redistribute it and/or modify + * it under the terms of the GNU
General Public License version 2 as + * published by the Free
Software Foundation. + */ +/dts-v1/; + +#include dra74x.dtsi
+#include dt-bindings/clk/ti-dra7-atl.h +#include
dt-bindings/gpio/gpio.h +#include
dt-bindings/interrupt-controller/irq.h + +/ { +model = TI
AM5728 BeagleBoard-X15; + compatible = ti,am572x-beagle-x15,
ti,am5728, ti,dra742, ti,dra74, ti,dra7; + + aliases { +
rtc0 = mcp_rtc; + rtc1 = tps659038_rtc; +}; + + memory
{ +
device_type = memory; +reg = 0x8000 0x4000; /* 1GB
to start. Target 2GB */
1GiB ? Why would you put this here btw ? u-boot fills this one up.
Yes, it should either be the full and correct value or 0x0 (like a
number of PowerPC platforms do) so it's clear something else gives us
the right value here.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJUW6PmAAoJENk4IS6UOR1WV2kQAI7JY0DFR+XsWMAZ2shiGcF6
+ZotxE4m030EQgfi8FnKe+i5u5pvHhJFqazRGX2cpYvj5X0fOnO730cyGLvunuQA
npVDTcu/4RASxOUtEAW88u/wxUqL1BvYTHlcFTOnaeYJbgvt/C+QIO/wK+izAPso
2ckS23d43DCAW2aVRo2Eq/L3CehjZz3dpQSzTyjWdYbQ0gROE4IWQ5J2qnSFYzhO
VO5CQb4gqP0iAVk96Z6RJWtQxaYGfNta9QDCaEkZ6OOo4z+MHvdfk5a5HiJzfzlr
VkRUaRql4UmvFFwUFoeYcsde1Mno8Ka3jXq94soNvnq0LiIYPjdLBI/7ca9exdbV
CnY3TxtZOfYqRsGiSF1mac8wqCF7kBC+u7nGGK1sTdNzhN5dFrIfL0tkfl8/avfH
YYyu/WeZEEZ8MJVk0KruXUgG1kge3FJc2v79AdDaiZtp6xcl5p+pVtCkx8QrCfGg
ofPjEtmGKSatIW/PmnOt0L/qmMQNnzwSbT+zgeUfgUXYLiH3NFK7wAdW5hWS4T3n
v5h1O8t3THZLnmc1Fdv4pfI3ozcoWjSLROlnWhtO1E9JEtVon8XfpyPObJzKV5GA
9CT+5Ivrirz/4TEUJ1kCKBQcxyZUFEmEVKYu9KiMPux2Doz4MI4TZOZ/TcWTJiCJ
hCXCtU398UOpnwVyy//D
=N9bA
-END PGP SIGNATURE-
--
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.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: how to set a static ip address for beagle bone
Dileep: The easiest way to get a static address is to tell your DHCP router to always put the Beaglebone's MAC address on a specific IP address. You can get both the MAC address and current IP address of the Beaglebone by issuing the command line instruction ifconfig . If your DHCP router will not set a fixed IP address, then you can edit the file /etc/network/interfaces For more specific instructions, GOOGLE IS YOUR FRIEND. Google the topic or question you have, and you will usually find the answer. For instance, Google How to set static IP address on Beaglebone and you get multiple answers, all of which will work. For example: http://elinux.org/Beagleboard:Terminal_Shells explains both the ifconfig command and specifics on how to edit /etc/network/interfaces --- Graham --- On Thursday, November 6, 2014 12:09:12 AM UTC-6, Dileep wrote: Hi, Could any one explain how to find out beagle bone ip address how to set a static IP addres. I'm new to Ubuntu Beagle Bone. Regards, Dileep -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Disable UART1 Echo
jimit...@gmail.com wrote: [-- text/plain, encoding 7bit, charset: UTF-8, 26 lines --] Hello All, I am working with the stock Debian distribution of Beagle Bone Black (rev C). I run the following command to enable UART 1 : echo BB-UART1 /sys/devices/bone_capemgr.*/slots and it works fine i.e. I am able to see ttyO1 listed in /dev and also able to transmit commands to a remote terminal. However, when I send anything from the terminal to BBB, I observe that the same data is echoed by BBB back to the terminal! How do I disable this? I went through the stty commands but nothing relevant there. Isn't it 'stty -echo' to turn echo off? -- Chris Green · -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Whci PRU-C-compiler is recommended?
On Tue, Nov 4, 2014 at 11:56 AM, Karl Karpfen karlkarpfe...@gmail.com wrote: OK, I'll try GCC version! Just wanted to collect some information regarding both compilers in this thread... 2014-11-04 17:47 GMT+01:00 dinu...@gmail.com: Hi Karl, The PRU GAS and LD ports should be in a good shape. But the PRU GCC port has not yet reached beta. Judge for yourself: PRU GCC has not been battle tested on a big project. Only two small examples are currently used to sanity check the pru gcc releases. PRU GCC has no known bugs. If you can take a little risk and don't mind checking the compiler-generated assembler, then go ahead and try PRU GCC. If you want an ASAP, no hassles C compiler for PRU, TI's one would be a more suitable choice right now. Regards, Dimitar On Tuesday, November 4, 2014 2:11:23 PM UTC+2, Karl Karpfen wrote: Hi, it seems there are two C-compilers available that are able to generate PRU-code. One from TI and one introduced here in this board. But...which one is recommended to be used? That's what I found out so far, may be somebody can add some missing information to make it easier to choose one: TI's PRU-C-compiler is - available at http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm - BETA - can be used to create ARM-objects (which can be linked to a bare metal application and loaded to PRU on start-up automatically?) The latest version of the C compiler is no longer in beta. Even better, it is a freely redistributable binary. While not as good as redistributable source like the GCC, at least we can easily get it to everyone; http://software-dl.ti.com/codegen/non-esd/downloads/download.htm#PRU I updated the wiki page and http://beagleboard.org/pru. I expect this to be included in upcoming Debian releases, if not the GCC as well. Community/Open Source PRU-C-compiler is - avaialble at https://github.com/dinuxbg/gnupru - BETA - GCC-based and therefore more stable -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/rwNrqudk0Ug/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Bricked BBB
I've managed to really screw up one of my Beaglebone Blacks too. It appears that I have clobbered the partition table on the eMMC, which seems to make U-Boot very unhappy! The AM335x processor skips the eMMC boot and goes directly to uSD boot after power is applied, no matter the position of the boot switch. I have tried booting several eMMC flashers, but none have worked: The latest Debian (5/14/14) shows this in serial console: U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54) ** Partition 1 not valid on device 0 ** spl_register_fat_device: fat register err - -1 ### ERROR ### Please RESET the board ### and reboots every ~48 seconds Angstrom (06/20/13) shows this once: U-Boot SPL 2013.04-dirty (Jun 19 2013 - 09:57:14) musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 OMAP SD/MMC: 0 ** Partition 1 not valid on device 0 ** spl: fat register err - -1 ### ERROR ### Please RESET the board ### I even tried an old BBW A6A image from 11/12/12: U-Boot SPL 2011.09-00053-gb423c52 (Aug 10 2012 - 11:26:55) Texas Instruments Revision detection unimplemented No daughter card present Did not find a recognized configuration, assuming General purpose EVM in Profile 0 with Daughter board I have used the Ubuntu 12.04 Disks tool to wipe the partitions and/or format the uSD card. I have tried Win32 Disk Imager version 0.9 and 0.91 on Windows 7x64. I have tried dd under Ubuntu. I have also tried several different uSD cards. The board is powered via a 24v, 50 watt power supply going to a 5v 50 watt DC-DC converter (the other 7 BBBs running on this power supply are fine). This is a Rev C from Element14. Any other insight? I'm running out of ideasperhaps I can fiddle with U-Boot? Is there a special version, of U-Boot, that will ignore the eMMC, or give me the power to create a partition table? If I can just get a user prompt, that would go a long way. Thanks, Louis On Tuesday, October 28, 2014 10:52:17 AM UTC-5, RobertCNelson wrote: On Tue, Oct 28, 2014 at 7:10 AM, denton@gmail.com javascript: wrote: Hi, So I have done something rather stupid and managed to brick my BBB! I was attempting to copy a bootable SD image using the dd command to the nand flash, and instead of copying the rootfs partition I copied the boot partition! e.g. dd if=/dev/mmcblk0p1 of=/dev/mmcblk1p1 Now the device does not boot, no LED's apart from power. If I look at the serial console output all I get is the letter 'C' repeated every 300m or so. :( Just reflash: http://beagleboard.org/latest-images Regards, -- Robert Nelson http://www.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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: libpruio (fast and easy D/A - I/O)
Hello Nils, thanks for the code. I think about including it in the libpruio examples folder, but your main loop is endless and the user cannot abort the program. (Shouldn't the file get closed?) Perhaps I can adapt it a bit. Regarding the ADC speed I made some further testing and it seems that I mis-interpreted the TRM. The ADC subsystem can sample at least at 200 kS/s. This speed also works for multiple channels. Find an example of four channels at 44.1 kHz in this post http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2F3AFiCNtxGis%2FH7q76xdk8ZQJ. An overall sampling rate of 200 kHz was also possible (four channels). So the limiting in the current libpruio-0.2 is too much on the safe site. If you don't want to wait for the next version, you can adapt the code by yourself (FreeBASIC compiler required). Replace in file pruio_adc.bas in function PruIo.configure(...) the lines d *= (Conf-ADC_CLKDIV + 1) * 417 '417 ≈ 100 / 2400 (= 1 GHz / 2.4 MHz) d += 30 ' PRU cycles for restart [GHz] IF Tmr = d THEN .Errr = @sample rate too big : RETURN .Errr by the following code d = (d * (Conf-ADC_CLKDIV + 1) * 1000) \ 24 IF Tmr = d ORELSE Tmr 5000 THEN _ .Errr = @sample rate too big : RETURN .Errr You may play a bit with the absolute value 5000. On my BBB the timing is OK up to a frequency of 240 kHz (4165). But this may vary from board to board. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Read A/D under Debian Image 2014-05-14
I'm quite new to this, and it was a struggle for me to do a simple thing
like read a channel of the A/D subsystem on my Beaglebone. Many of the
guides on the web seem not to work under Debian Image 2014-05-14. So in
the hope of helping someone else, here is my hard-won cookbook for Debian
users.
Following is a step-by-step guide to reading the A/D channels on my
Beaglebone (white or black) running Debian Image 2014-05-14.
*STEP ONE*
Change uEnv.txt to look like this:
*##Example#cape_disable=capemgr.disable_partno=cape_enable=capemgr.enable_partno=BB-ADC*
(the first two lines above will already be in the file. You add the last
line cape_enable=capemgr.enable_partno=BB-ADC )
This will cause BB-ADC device tree to be installed each time you boot your
board.
*STEP TWO*
With this done, reboot the board. I boot to root@beaglebone:~# so it
will appear below.
Verify that you can now read A/D channel 0 by executing the following from
the command line on your Beaglebone:
*root@beaglebone:~# cat
/sys/bus/iio/devices/iio:device0/in_voltage0_raw*
You should see a number something like 3927. If so, you have access to the
A/D subsystem and you can try things like
*root@beaglebone:~# cat
/sys/bus/iio/devices/iio:device0/in_voltage7_raw*
to read channel 7, and so on.
*STEP THREE*
If you're interested in C/C++, the following short program should read all
eight A/D channels and display their value:
#include iostream
#include cstring
#include fcntl.h //define O_WRONLY and O_RDONLY
using namespace std;
int main()
{
int fd ; //for file handle
char ch[5];//for the A/D value when read
//The next three strings are used to construct a path to the A/D channels
char bufbase[64] = /sys/bus/iio/devices/iio:device0/in_voltage;
//path prefix
char chnlnumber[2];//channel to be read, 0,1,...,7
char bufend[] = _raw;//path suffix
char buf[64] = ;//string to hold full path to A/D channel
int i;//loop index
chnlnumber[1] = 0; //end of string
for (i=0;i8;i++)
{chnlnumber[0] = 48+i;//string containing channel number as a
character
strcat(strcat(strcat(buf,bufbase),chnlnumber),bufend);
//construct the full path
cout Cnl chnlnumber;//display the channel
number being read
fd = open(buf, O_RDONLY);//access the A/D channel as a file
read(fd,ch,4);//
cout ch endl ;//display the current raw
value from the channel
close(fd);
strcpy(buf,);//get ready to do next channel access
usleep(1);//wait for 10ms -- not really needed
}
}
(I'm also new to C++, being more of a assembler guy myself, so this code
may have many shortcomings. Advice on improvements
welcome!)
--
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.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Disable UART1 Echo
My understanding is 'echo' for ssty is just to turn ON/OFF echo of input characters i.e. if '-echo' flag is used it would just prevent the input characters I send via BBB from appearing on my screen. My problem is with the data that BBB receives. Everytime BBB receives a byte, it transmits back the same byte. I shall keep looking. On Monday, November 3, 2014 6:55:09 PM UTC-5, jimi...@gmail.com wrote: Hello All, I am working with the stock Debian distribution of Beagle Bone Black (rev C). I run the following command to enable UART 1 : echo BB-UART1 /sys/devices/bone_capemgr.*/slots and it works fine i.e. I am able to see ttyO1 listed in /dev and also able to transmit commands to a remote terminal. However, when I send anything from the terminal to BBB, I observe that the same data is echoed by BBB back to the terminal! How do I disable this? I went through the stty commands but nothing relevant there. Thanks! -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3.17.1-rc4 sudden reset
*If interested, I can post more details.* Please do Jens, I am sure someone will find the information useful. Did you by chance debug / bug report to the maintainer ? -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Enable UART1
On Mon, Nov 3, 2014 at 4:22 PM, jimit...@gmail.com wrote: Apologies for the delayed response. I work on this project mostly on weekends. I had given up on editing uEnv.txt , but what worked for me was running the below command : echo BB-UART1 /sys/devices/bone_capemgr.*/slots you didn't remove the # 'comment' character in front of the line in /boot/uEnv.txt Regards, -- Robert Nelson http://www.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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Understanding how to partition the eMMC/SD card
On Thu, Nov 6, 2014 at 12:31 AM, david.acca...@gmail.com wrote:
Hi
I've been following the steps at
https://eewiki.net/display/linuxonarm/BeagleBone+Black; Trying build the
latest mainline kernel with the minimum Debian filesystem.
I don't quite understand what is happening in the following steps under
Setup microSD/SD card
sudo dd if=/dev/zero of=${DISK} bs=1M count=10
sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 conv=notrunc bs=128k
sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1 conv=notrunc
bs=384k
Create Partition Layout:
sudo sfdisk --in-order --Linux --unit M ${DISK} -__EOF__
1,,0x83,*
__EOF__
Format Partitions:
for: DISK=/dev/mmcblk0
sudo mkfs.ext4 ${DISK}p1 -L rootfs
I realise the a card is being wiped and then formatted but I'm not sure why.
The default Debian sd card image (and other images I found) Have separate
boot partition, however in this example only one partition is created.
Why is this tutorial different?
It's the same setup used on 'newer' snapshots..
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
Is it just a new feature of U-boot?
it's a feature available to newer ti bootrom's, (omap4 generation + )
which we are utilizing to make it easier for windows users to not
accidentally delete MLO/u-boot.img and soft-bricking there board.
Also after following the all the steps in the tutorial the the beagelbone
black will boot from the SD card but it will hang on the line net eth0: phy
4a101000.mdio:01 not found on slave 1 for about 30 sec before showing the
login prompt but that is probably a question for another thread.
dhcp is still slow, it takes a few seconds for the eth0 to get an ip address.
Regards,
--
Robert Nelson
http://www.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.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Seriously Confused
I'm not sure the kernel source would be beneficial. If you want to understand how the ADC works or get it going manually, with all the clock domain setup and whatnot, then read the reference manual. The kernel source will be doing all of this, in an abstracted and not so easy to understand way. The driver/sysfs interface wont load up until the device tree overlay (that describes the ADC) is loaded. Is the BB-ADC overlay loaded? http://analogdigitallab.org/articles/using-adc-beaglebone-black On Thu, Nov 6, 2014 at 7:41 AM, Curt Carpenter 1cjcarpen...@att.net wrote: Thanks Brandon. Alas, the path used in the c_adc.c software just doesn't seem to exist in the Debian I'm using -- one of the big sources of confusion for me. I'm starting to think the only solution is to try to dig into the kernel source as Joshua suggests -- but that sounds like it might take more years than I have left :-) On Wednesday, November 5, 2014 4:24:01 PM UTC-6, Brandon I wrote: https://github.com/adafruit/adafruit-beaglebone-io-python/ blob/master/source/c_adc.c The adc source for bbio should be useful. Keep in mind that these sysfs interfaces are incredibly slow compared to memory poking since each operation requires opening, reading/writing and closing the file. For example, with GPIO, you're limited to a few hundred khz (regardless of language since it's just file operations). With mmap and python, you can toggle at 3Mhz. C a bit faster. Kernel, 12Mhz. There are python and closing libraries that handle all of the memory poking. Also, check out libpruio. It will setup the pin muxing, and provides quick adc and GPIO support. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/9IRWOZ8b2n4/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Disable UART1 Echo
jimit...@gmail.com wrote: [-- text/plain, encoding 7bit, charset: UTF-8, 38 lines --] My understanding is 'echo' for ssty is just to turn ON/OFF echo of input characters i.e. if '-echo' flag is used it would just prevent the input characters I send via BBB from appearing on my screen. My problem is with the data that BBB receives. Everytime BBB receives a byte, it transmits back the same byte. I shall keep looking. I don't follow what you're saying. The UART/tty 'receives' bytes from whatever is connected to it, that's what 'input' characters are. E.g. you have a terminal of some sort connected to the UART, what you type on the terminal are the 'input' characters and they're echoed back to the terminal as 'output' to the terminal (if echo is turned on). By characters you 'send via the BBB' I assume you mean they are sent by a program of some sort to the UART, if so they are just 'output' characters and you can't turn them off I don't think. What's the point of sending them if you turn them off? -- Chris Green · -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Howto integrate a overlay devicetree into the board devicetree since the manager is gone?
I' running buildroot and my last challenge is to integrate a devicetree file for a can cape into the DT of the kernel. Is it possible by doing an include? -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Disable UART1 Echo
Hello Chris, I am sorry for the confusion. Let me explain the setup and then elaborate the problem. So I have two XBEE/Zigbee devices. One of them is connected to BBB UART1. The other is connected to my PC. On BBB side, I use picocom terminal to transmit data. On PC side, I have the X-CTU GUI provided by XBEE to send data/monitor received data. Now, when I transmit from BBB using picocom, I can see the data being properly received by PC side XBEE. However, when the PC side XBEE transmits data, it receives back the same data after transmission. This is because, for some reason, the BBB on receiving a byte transmits (echoes) back the same byte. Now coming to ssty, I believe the '-echo' option with BBB shall only prevent any character that I type on picocom terminal from appearing there on the terminal screen. On Thursday, November 6, 2014 3:34:05 PM UTC-5, c...@isbd.net wrote: jimi...@gmail.com javascript: wrote: [-- text/plain, encoding 7bit, charset: UTF-8, 38 lines --] My understanding is 'echo' for ssty is just to turn ON/OFF echo of input characters i.e. if '-echo' flag is used it would just prevent the input characters I send via BBB from appearing on my screen. My problem is with the data that BBB receives. Everytime BBB receives a byte, it transmits back the same byte. I shall keep looking. I don't follow what you're saying. The UART/tty 'receives' bytes from whatever is connected to it, that's what 'input' characters are. E.g. you have a terminal of some sort connected to the UART, what you type on the terminal are the 'input' characters and they're echoed back to the terminal as 'output' to the terminal (if echo is turned on). By characters you 'send via the BBB' I assume you mean they are sent by a program of some sort to the UART, if so they are just 'output' characters and you can't turn them off I don't think. What's the point of sending them if you turn them off? -- Chris Green · -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: [PATCH] ARM: dts: Add am57xx-beagle-x15
On 11/06/2014 10:37 AM, Tom Rini wrote: device_type = memory; + reg = 0x8000 0x4000; /* 1GB to start. Target 2GB */ 1GiB ? Why would you put this here btw ? u-boot fills this one up. Yes, it should either be the full and correct value or 0x0 (like a number of PowerPC platforms do) so it's clear something else gives us the right value here. Honest mistake, my bad.. I thought I cleaned up the patch! Sigh!!! i will repost with proper 2GB. it is better that way in case being used with other bootloaders which are not exactly too good like u-boot. -- Regards, Nishanth Menon -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: [PATCH] ARM: dts: Add am57xx-beagle-x15
On 11/06/2014 10:48 AM, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [141106 08:44]: On 11/06/2014 10:37 AM, Tom Rini wrote: device_type = memory; + reg = 0x8000 0x4000; /* 1GB to start. Target 2GB */ 1GiB ? Why would you put this here btw ? u-boot fills this one up. Yes, it should either be the full and correct value or 0x0 (like a number of PowerPC platforms do) so it's clear something else gives us the right value here. Honest mistake, my bad.. I thought I cleaned up the patch! Sigh!!! i will repost with proper 2GB. it is better that way in case being used with other bootloaders which are not exactly too good like u-boot. Can you also describe why all the always-on regulators are needed? yep - will do that similar to https://patchwork.kernel.org/patch/5125431/ - same rationale unless there is any specific voltage rail that you are explicitly interested in that needs additional explanation. Is there additional rails of interest? -- Regards, Nishanth Menon -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] [PATCH] ARM: dts: Add am57xx-beagle-x15
BeagleBoard-X15 is the next generation Open Source Hardware
BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ A15
processor. The platform features 2GB DDR3L (w/dual 32bit busses),
eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60), separate LCD
port, video In port, 4GB eMMC, uSD, Analog audio in/out, dual 1G
Ethernet.
For more information, refer to:
BeagleBoard-X15 Wiki:
http://www.elinux.org/Beagleboard:BeagleBoard-X15
AM5728 is part of the Sitara product family whose additional details
will be available: http://www.ti.com/lsds/ti/arm/overview.page
Technical Reference Manual for AM5728 is public domain at:
http://www.ti.com/lit/spruhz6
Just add basic support for the moment, the following updates are needed:
i)Ethernet - depends on SoC dts fixes
ii) USB Client (USB2) - depends on GPIO extcon
ii) HDMI - additional driver fixes pending
iii) Audio - additional driver fixes pending
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Tested with omap2plus_defconfig modified as: http://slexy.org/view/s2DRTzUwjj
boot log: http://slexy.org/raw/s25Grf1uoo
based on 3.18-rc1 tag.
Support for u-boot has been posted as well: (series ending
http://patchwork.ozlabs.org/patch/407552/ )
Side note: this patch generates a few unrelated checkpatch warning for
compatible which probably is part of appropriate driver documentation
fixes (functionality is already present).
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/am57xx-beagle-x15.dts | 405 +++
2 files changed, 406 insertions(+)
create mode 100644 arch/arm/boot/dts/am57xx-beagle-x15.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38c89ca..eee1e4f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -347,6 +347,7 @@ dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
omap5-sbc-t54.dtb \
omap5-uevm.dtb
dtb-$(CONFIG_SOC_DRA7XX) += dra7-evm.dtb \
+ am57xx-beagle-x15.dtb \
dra72-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-d2-network.dtb \
orion5x-lacie-ethernet-disk-mini-v2.dtb \
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
new file mode 100644
index 000..1f1875b
--- /dev/null
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -0,0 +1,405 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include dra74x.dtsi
+#include dt-bindings/clk/ti-dra7-atl.h
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/interrupt-controller/irq.h
+
+/ {
+ model = TI AM5728 BeagleBoard-X15;
+ compatible = ti,am572x-beagle-x15, ti,am5728, ti,dra742,
ti,dra74, ti,dra7;
+
+ aliases {
+ rtc0 = mcp_rtc;
+ rtc1 = tps659038_rtc;
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1GB to start. Target 2GB */
+ };
+
+ vdd_3v3: fixedregulator-vdd_3v3 {
+ compatible = regulator-fixed;
+ regulator-name = vdd_3v3;
+ vin-supply = regen1;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
+
+ vtt_fixed: fixedregulator-vtt {
+ /* TPS51200 */
+ compatible = regulator-fixed;
+ regulator-name = vtt_fixed;
+ vin-supply = smps3_reg;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ regulator-boot-on;
+ enable-active-high;
+ gpio = gpio7 11 GPIO_ACTIVE_HIGH;
+ };
+
+ leds {
+ compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 = leds_pins_default;
+
+ led@0 {
+ label = beagle-x15:usr0;
+ gpios = gpio7 9 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+
+ led@1 {
+ label = beagle-x15:usr1;
+ gpios = gpio7 8 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = cpu0;
+ default-state = off;
+ };
+
+ led@2 {
+ label = beagle-x15:usr2;
+ gpios = gpio7 14 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = mmc0;
+ default-state = off;
+ };
+
+ led@3 {
+ label = beagle-x15:usr3;
+ gpios = gpio7 15 GPIO_ACTIVE_HIGH;
+
[beagleboard] Re: [PATCH] ARM: dts: Add am57xx-beagle-x15
On 10:53-20141106, Nishanth Menon wrote: On 11/06/2014 10:48 AM, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [141106 08:44]: On 11/06/2014 10:37 AM, Tom Rini wrote: device_type = memory; + reg = 0x8000 0x4000; /* 1GB to start. Target 2GB */ 1GiB ? Why would you put this here btw ? u-boot fills this one up. Yes, it should either be the full and correct value or 0x0 (like a number of PowerPC platforms do) so it's clear something else gives us the right value here. Honest mistake, my bad.. I thought I cleaned up the patch! Sigh!!! i will repost with proper 2GB. it is better that way in case being used with other bootloaders which are not exactly too good like u-boot. Can you also describe why all the always-on regulators are needed? yep - will do that similar to https://patchwork.kernel.org/patch/5125431/ - same rationale unless there is any specific voltage rail that you are explicitly interested in that needs additional explanation. Is there additional rails of interest? Here is what I have in mind: (updated with comments from Felipe/Tom and above) - would you like more details added - if you could point out areas of interest, I can help improve information provided here. 8--- From d73029bc01c9e2193fb769ce5cc6cc5abb14eba5 Mon Sep 17 00:00:00 2001 From: Nishanth Menon n...@ti.com Date: Mon, 18 Aug 2014 12:14:08 -0500 Subject: [PATCH V2] ARM: dts: Add am57xx-beagle-x15 BeagleBoard-X15 is the next generation Open Source Hardware BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ A15 processor. The platform features 2GB DDR3L (w/dual 32bit busses), eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60), separate LCD port, video In port, 4GB eMMC, uSD, Analog audio in/out, dual 1G Ethernet. For more information, refer to: BeagleBoard-X15 Wiki: http://www.elinux.org/Beagleboard:BeagleBoard-X15 AM5728 is part of the Sitara product family whose additional details will be available: http://www.ti.com/lsds/ti/arm/overview.page Technical Reference Manual for AM5728 is public domain at: http://www.ti.com/lit/spruhz6 Just add basic support for the moment, the following updates are needed: i)Ethernet - depends on SoC dts fixes ii) USB Client (USB2) - depends on GPIO extcon ii) HDMI - additional driver fixes pending iii) Audio - additional driver fixes pending NOTE: AM5728 Data Manual (SPRS915L - August 2014) section 4.1.1 states: All unused power supply balls must be supplied with the voltages specified in the Section 5.2, Recommended Operating Conditions. This implies that all unused voltage rails for AM5728 can never be switched off even if the hardware blocks inside that voltage domain is unused. Switching off these unused rails may result in stability issues on other domains and increased leakage and power-on-hour impacts. Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- Changes in V2 since V1: - Fix the missing squash of proper DDR size. V1: https://patchwork.kernel.org/patch/5244801/ Additional references: - Missing ethernet dtsi patch series: http://marc.info/?t=14138858531r=1w=2 - Missing USB Client extcon patch series: http://marc.info/?t=14152016084r=1w=2 Tested with omap2plus_defconfig modified as: http://slexy.org/view/s2DRTzUwjj boot log: http://slexy.org/raw/s25Grf1uoo based on 3.18-rc1 tag. Support for u-boot has been posted as well: (series ending http://patchwork.ozlabs.org/patch/407552/ ) Side note: this patch generates a few unrelated checkpatch warning for compatible which probably is part of appropriate driver documentation fixes (functionality is already present). arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/am57xx-beagle-x15.dts | 405 +++ 2 files changed, 406 insertions(+) create mode 100644 arch/arm/boot/dts/am57xx-beagle-x15.dts diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 38c89ca..eee1e4f 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -347,6 +347,7 @@ dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \ omap5-sbc-t54.dtb \ omap5-uevm.dtb dtb-$(CONFIG_SOC_DRA7XX) += dra7-evm.dtb \ + am57xx-beagle-x15.dtb \ dra72-evm.dtb dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-d2-network.dtb \ orion5x-lacie-ethernet-disk-mini-v2.dtb \ diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts new file mode 100644 index 000..1f1875b --- /dev/null +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts @@ -0,0 +1,405 @@ +/* + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +/dts-v1/; + +#include dra74x.dtsi +#include dt-bindings
[beagleboard] Re: [PATCH] ARM: dts: Add am57xx-beagle-x15
* Nishanth Menon n...@ti.com [141106 08:44]: On 11/06/2014 10:37 AM, Tom Rini wrote: device_type = memory; + reg = 0x8000 0x4000; /* 1GB to start. Target 2GB */ 1GiB ? Why would you put this here btw ? u-boot fills this one up. Yes, it should either be the full and correct value or 0x0 (like a number of PowerPC platforms do) so it's clear something else gives us the right value here. Honest mistake, my bad.. I thought I cleaned up the patch! Sigh!!! i will repost with proper 2GB. it is better that way in case being used with other bootloaders which are not exactly too good like u-boot. Can you also describe why all the always-on regulators are needed? Regards, Tony -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: [PATCH] ARM: dts: Add am57xx-beagle-x15
On Thu, Nov 06, 2014 at 10:18:22AM -0600, Nishanth Menon wrote: BeagleBoard-X15 is the next generation Open Source Hardware BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ A15 processor. The platform features 2GB DDR3L (w/dual 32bit busses), eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60), separate LCD port, video In port, 4GB eMMC, uSD, Analog audio in/out, dual 1G Ethernet. Oh neat, you put a USB3 hub on the board? I really should cleanup and submit my patch to make the system time not run 576ppm too fast on the AM57xx. This will sure be a nice board when you get it released. I will have to get one. -- Len Sorensen -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Launching node application taking long time
Launching a node js application with express js is taking about 2.2 seconds - and including other modules is boosting my time into 20 seconds. I would like my application to get running as quickly as possible after boot up - 20 seconds seems like a long time. Any known ways to speed up node on the bbb? I've tried uglify - but haven't gotten any benefit - I've also tried putting the node app in tmpfs and it's the same time too. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Ubuntu and Midi
Noticed that there are no instructions provided for building the kernel in the Ubuntu wiki http://elinux.org/BeagleBoardUbuntu like there is on the Debian wiki http://elinux.org/BeagleBoardDebian#BeagleBone_Black. Is there a script to run that allows the kernel to be customised before running *build_kernel.sh*? Under great pressure to get the BBB MIDI organ finished in time for Xmas. Ended up being caught off guard by the *sequencer not found* issue which pops up when running *aseqdump -l* (lists all MIDI devices connected and recognised by Linux which is part of the *alsa-utils *package). Did the testing on a Linux desktop thinking that I was all set to do a similar setup on the BBB. Unfortunately Murphy's law kicked in. So incredibly easy for good plans to come unravelled in a blink of an eye. On Tuesday, 3 May 2011 03:24:30 UTC+12, lchile wrote: Tried again, and it works - thank you! -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Ubuntu and Midi
Does kernel 3.17 include MIDI support? On Friday, 7 November 2014 11:06:44 UTC+13, Nick Apperley wrote: Noticed that there are no instructions provided for building the kernel in the Ubuntu wiki http://elinux.org/BeagleBoardUbuntu like there is on the Debian wiki http://elinux.org/BeagleBoardDebian#BeagleBone_Black. Is there a script to run that allows the kernel to be customised before running *build_kernel.sh*? Under great pressure to get the BBB MIDI organ finished in time for Xmas. Ended up being caught off guard by the *sequencer not found* issue which pops up when running *aseqdump -l* (lists all MIDI devices connected and recognised by Linux which is part of the *alsa-utils *package). Did the testing on a Linux desktop thinking that I was all set to do a similar setup on the BBB. Unfortunately Murphy's law kicked in. So incredibly easy for good plans to come unravelled in a blink of an eye. On Tuesday, 3 May 2011 03:24:30 UTC+12, lchile wrote: Tried again, and it works - thank you! -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3.17.1-rc4 sudden reset
On Thursday, November 6, 2014 11:10:37 AM UTC-5, Jens Peter Schroer wrote: I have followed the USB OTG hint as mentioned in my previous post. I patched the dtb for the bbb so that the mini usb port runs as peripheral and not as OTG. The patch was deployed to 7 systems so far and they all are stable (no reboot) since then on any of the systems. The uptime is more than 3 days now. @Jens - thanks for the tip. I tried it: setting usb0 dr_mode = peripheral and usb1 dr_mode = host. I don't use usb0 at all; usb1 has a usb hub with wifi plugs. The BBB ran for about a three hours under heavy load (125K packet captures w/ about 10K dropped) and then silently reset. I'm going to try (1) soaking the BBB with a light load overnight, 2) run power over usb0. Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] TI PRU cape available now for $39
Microcenter BBB deal also available online if you aren't close to a store. I bought 5 for $9.95 shipping. Only bs was tax including on the shipping! On Nov 6, 2014 11:24 AM, Jason Kridner jkrid...@beagleboard.org wrote: There is some software associated with it as well, but I haven't tried it yet. Placed an order for mine---you'd think they'd be smart enough within TI to send me one AHEAD of the announcement, but whatever. I created a project page at http://beagleboard.org/project/prucape/ Also, I was told on G+ that Micro Center has the Element14 BeagleBone Blacks available for $39. I confirmed they had boards at my local store. Not sure why the fire-sale pricing, but I don't see why not to take advantage of it and pick up a couple extra boards! -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: libpruio (fast and easy D/A - I/O)
Hey TJF,
I've got it compiled and working. I can't yet test if the adc keeps up
since I the function generator we've ordered got out of stock However I
changed my code a bit so it would close the files and the whole program has
a end statement. It's currently 1 channel at ~220 kS/s. I haven't pushed it
further because I don't know what will happen. With my understanding of the
PRU I guess the PRU can't break anything on the BBB while doing that, but I
don't know so I don't want to push my luck.
#include unistd.h
#include stdio.h
#include ../c_wrapper/pruio.h
//! The main function.
int main(int argc, char **argv)
{
FILE* oFile;
uint8 bDiv = 4, bStep;
uint32 bSize = 1e6;
uint32 bsSize = bSize/bDiv;
uint8 cycles = 2;
char fName[12];
int i = 0;
pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new
driver structure
pruio_adc_setStep(io, 9, 4, 0, 0, 0); // step 9 for AIN-4
if (pruio_config(io, bSize, 1 9, 4545, 0)){ // '1 9' - step 9,
'6285' ns - 159.1 kHz
printf(config failed (%s)\n, io-Errr);}
else{
pruio_rb_start(io);
sleep(1);
for(i=0; icycles; i++){
sprintf(fName, output.%u,i);
oFile = fopen(fName,wb);
while(bStepbDiv){
while(io-DRam[0] (bStep+1) * bsSize io-DRam[0] bStep *
bsSize){
sleep(1);
}
printf(writing samples %u-%u\n,bStep*bsSize, (bStep+1)*bsSize);
fwrite(io-Adc-Value, sizeof(uint16), 16000, oFile);
bStep++;
}
bStep=0;
fclose(oFile);
}
}
pruio_destroy(io);
return 0;
}
Greetings,
Nils Kohrs
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: BeagleBone Black doesn't sometimes start. Only Power LED is on
Mikkil, Thanks for you detailed answer. U15.1: _1OE = 0V U15.2: 1A= 0V U15.3: 2Y= floating (flickering +-0.000,50V) U15.4: GND = 0V U15.5: 2A = UART0_RX = 3.335V U15.6: 1Y = UART0_TX = 3.195V U15.7: 2OE = 3.352V U15.8: VCC = 3.352V Based on the voltages that when U15 is removed, the UART0_RX is at its proper voltage level (3V3) that is defined in the device tree. The strange thing is that when U15 is there, the UART0_RX is not getting 3V3. _1OE is low and 2OE is high. Then the voltage on the j4.4 should be the same as UART0_RX. But J4.4 is not 3.3V (it was 1.4 on my board) even when R165 is removed, therefore, UART0_RX is not 3.3V. How did you get the 0.58V on J4.4 using 1K resistor? I do not why 0.58V works. To my understanding, the default idle state should be high on both TX and RX lines for UART0. Regards, Shu -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Needed BEAGLEBONE WL1835MOD W/ CHIP ANTENNA
Well, Boardzoo has them listed as In Stock now. http://boardzoo.com/index.php/catalog/product/view/id/146/category/8#.VFwTscmwXeo Thanks, Markus On Wednesday, September 10, 2014 2:01:41 PM UTC-4, Waxengecko wrote: We have been looking for the BEAGLEBONE WL1835MOD W/ CHIP ANTENNA for sometime now without results. Does anyone have a few extra they would be willing to sell and ship to us? Thanks Coy -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Needed BEAGLEBONE WL1835MOD W/ CHIP ANTENNA
On Thu, Nov 6, 2014 at 7:37 PM, 'M Robinson' via BeagleBoard beagleboard@googlegroups.com wrote: Well, Boardzoo has them listed as In Stock now. Thanks! I was waiting for this one. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Launching node application taking long time
You're going to need to be specific, and tell us exactly what it is you're doing. On Thu, Nov 6, 2014 at 2:42 PM, lucidguppy matthew.james.ka...@gmail.com wrote: Launching a node js application with express js is taking about 2.2 seconds - and including other modules is boosting my time into 20 seconds. I would like my application to get running as quickly as possible after boot up - 20 seconds seems like a long time. Any known ways to speed up node on the bbb? I've tried uglify - but haven't gotten any benefit - I've also tried putting the node app in tmpfs and it's the same time too. -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Understanding how to partition the eMMC/SD card
* Also after following the all the steps in the tutorial the the beagelbone* * black will boot from the SD card but it will hang on the line net eth0: phy* * 4a101000.mdio:01 not found on slave 1 for about 30 sec before showing the* * login prompt but that is probably a question for another thread.* * dhcp is still slow, it takes a few seconds for the eth0 to get an ip address.* That is the price you pay for using dhcp apparently. When using a static IP, I've never had this problem. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Disable UART1 Echo
I have resolved this now. Turns out it was a problem with the hardware cape that I had prepared to mount XBEE on BBB. The Rx/Tx pins were swapped due to oversight. Everything works fine now. Thanks everyone!! On Thursday, November 6, 2014 4:08:31 PM UTC-5, jimi...@gmail.com wrote: Hello Chris, I am sorry for the confusion. Let me explain the setup and then elaborate the problem. So I have two XBEE/Zigbee devices. One of them is connected to BBB UART1. The other is connected to my PC. On BBB side, I use picocom terminal to transmit data. On PC side, I have the X-CTU GUI provided by XBEE to send data/monitor received data. Now, when I transmit from BBB using picocom, I can see the data being properly received by PC side XBEE. However, when the PC side XBEE transmits data, it receives back the same data after transmission. This is because, for some reason, the BBB on receiving a byte transmits (echoes) back the same byte. Now coming to ssty, I believe the '-echo' option with BBB shall only prevent any character that I type on picocom terminal from appearing there on the terminal screen. On Thursday, November 6, 2014 3:34:05 PM UTC-5, c...@isbd.net wrote: jimi...@gmail.com wrote: [-- text/plain, encoding 7bit, charset: UTF-8, 38 lines --] My understanding is 'echo' for ssty is just to turn ON/OFF echo of input characters i.e. if '-echo' flag is used it would just prevent the input characters I send via BBB from appearing on my screen. My problem is with the data that BBB receives. Everytime BBB receives a byte, it transmits back the same byte. I shall keep looking. I don't follow what you're saying. The UART/tty 'receives' bytes from whatever is connected to it, that's what 'input' characters are. E.g. you have a terminal of some sort connected to the UART, what you type on the terminal are the 'input' characters and they're echoed back to the terminal as 'output' to the terminal (if echo is turned on). By characters you 'send via the BBB' I assume you mean they are sent by a program of some sort to the UART, if so they are just 'output' characters and you can't turn them off I don't think. What's the point of sending them if you turn them off? -- Chris Green · -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Blink external led test doesn't work
My name is João and it's a pleasure to join this community, so, a big hi to you all. About my problem, it's the first time i'm using BBB and was trying to blink an external led i followed every steps on the page and can't figure it out why the led don't blink, do you think my BBB is deffective? Does anybody have a simple test to try and test if the problem is with the hardware? Thanks in advance for your time. My best regards, João Soares -- 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. For more options, visit https://groups.google.com/d/optout.
RE: [beagleboard] Blink external led test doesn't work
Could be just about anything. Could you tell us what page you are referring to, maybe post the link ? No one could make a greater mistake than he who did nothing because he could do only a little. All that is necessary for the triumph of evil is that good men do nothing Edmond Burke (1729 - 1797) http://www.packtpub.com/building-a-home-security-system-with-beaglebone/book From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of João Soares Sent: Thursday, November 06, 2014 10:29 PM To: beagleboard@googlegroups.com Subject: [beagleboard] Blink external led test doesn't work My name is João and it's a pleasure to join this community, so, a big hi to you all. About my problem, it's the first time i'm using BBB and was trying to blink an external led i followed every steps on the page and can't figure it out why the led don't blink, do you think my BBB is deffective? Does anybody have a simple test to try and test if the problem is with the hardware? Thanks in advance for your time. My best regards, João Soares -- 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. For more options, visit https://groups.google.com/d/optout. No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5315 / Virus Database: 4189/8521 - Release Date: 11/06/14 _ No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5315 / Virus Database: 4189/8521 - Release Date: 11/06/14 -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] beaglebone-black damaged
-- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Blink external led test doesn't work
The test i did was this http://192.168.7.2/Support/BoneScript/demo_blinkled_external/ Thanks Sexta-feira, 7 de Novembro de 2014 3:28:35 UTC, João Soares escreveu: My name is João and it's a pleasure to join this community, so, a big hi to you all. About my problem, it's the first time i'm using BBB and was trying to blink an external led i followed every steps on the page and can't figure it out why the led don't blink, do you think my BBB is deffective? Does anybody have a simple test to try and test if the problem is with the hardware? Thanks in advance for your time. My best regards, João Soares -- 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. For more options, visit https://groups.google.com/d/optout.
RE: [beagleboard] Re: Blink external led test doesn't work
Ok That is the demo that comes with the BBB. Do you see a web page? I think it is called “Getting Started”. I don’t have the BBB in front of me, but I believe there are a number of examples. Does the one that blinks the User LED work ? No one could make a greater mistake than he who did nothing because he could do only a little. All that is necessary for the triumph of evil is that good men do nothing Edmond Burke (1729 - 1797) http://www.packtpub.com/building-a-home-security-system-with-beaglebone/book From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of João Soares Sent: Thursday, November 06, 2014 10:52 PM To: beagleboard@googlegroups.com Subject: [beagleboard] Re: Blink external led test doesn't work The test i did was this http://192.168.7.2/Support/BoneScript/demo_blinkled_external/ Thanks Sexta-feira, 7 de Novembro de 2014 3:28:35 UTC, João Soares escreveu: My name is João and it's a pleasure to join this community, so, a big hi to you all. About my problem, it's the first time i'm using BBB and was trying to blink an external led i followed every steps on the page and can't figure it out why the led don't blink, do you think my BBB is deffective? Does anybody have a simple test to try and test if the problem is with the hardware? Thanks in advance for your time. My best regards, João Soares -- 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. For more options, visit https://groups.google.com/d/optout. No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5315 / Virus Database: 4189/8521 - Release Date: 11/06/14 _ No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5315 / Virus Database: 4189/8521 - Release Date: 11/06/14 -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Cannot ping Eth0 from PC on BeagleBone Black
HeLLO Dmit, I'm working on the same issue of communicating with BBB using the sockets via the etethernet cable. I'm wondering where should I start and could you give me some suggestions? Thanks alot! Wu On Thursday, December 19, 2013 5:48:02 PM UTC-6, dmitr...@gmail.com wrote: Good Afternoon, I am developing an application for communicating with the BBB using sockets via the onboard ethernet port. The strange part is, my client(pc)/server(BBB) application communicated perfectly the first time I ran it, but when I rebooted the BBB, it could not establish an ethernet connection. I tried pinging the IP given by running ifconfig on the BBB 169.254.40.43, but it never replied I also tried changing to a static IP (192.168.1.80) via this post http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/; but I still could not connect. Finally, I tried this on two different BBB's one with stock angstrom, one with the newest flash image. Neither could connect. I did not change to static IP on the stock BBB. I can still connect to usb0, via 192.168.7.2 no problem. In fact I only had a problem with this when I changed eth0 to use static ip 192.168.7.80, somehow this interfered with the 192.168.7.2 IP of usb0 and would not let me ssh into the BBB Please let me know if I am missing something, I tried rebooting many times and turning eth0 on and off, but I could never establish a connection to it since. Thank you, -Dmit -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Understanding how to partition the eMMC/SD card
Thanks that make sense. Once the image is working is there a way to copy the SD card to the eMMC? The scripts at https://github.com/RobertCNelson/tools/blob/master/scripts don't seem to work for the single partition image. Regards David -- 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. For more options, visit https://groups.google.com/d/optout.
