[beagleboard] Device Tree Overlay & GPIO Events
Hello,
I'm using a Beaglebone Black with a custom cape attached to it.
I created a device tree overlay for it (see the attached mycape.dts), which
is almost working fine, except that I won't receive any events using the C
poll() function.
When I load the dts all Inputs/Outpus are muxed and exported automatically
to the sysfs as expected. But only the "edge-file" gives me a none, instead
of both.
I didn't find any documentation for this. I only found the two options
"count-rising-edge" and "count-falling-edge" which should enable the
interrupts for this pin. But so far, it does not work for me...
So is there any way I can tell the device tree that I want to watch for
both edges?
Trying to set the edge manually after loading the device tree overlay only
gives me a write error: "Device or resource busy".
If I remove the GPIO Part:
In0 { //GPIO-1[12]
gpio-name = "Input0";
gpio = <&gpio2 12 0x00>;
input;
active-low;
count-rising-edge;
count-falling-edge;
};Code hier eingeben...
and export & configure the inputs manually, the events are working!
So I think my C-Code should be fine...
I hope anyone can help me with this...
Thank you very much!
With best regards,
Sebastian
--
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.
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
/* identification */
board-name = "MY-CAPE";
part-number = "MY-CAPE";
version = "00A0";
/* Exclusive Pin use */
exclusive-use = "P8.07", "P8.12", "gpio_1_12", "gpio_2_2";
/* Pin-Muxing & Configuration */
fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
//Inputs
input_pins: pinmux_input_pins{
pinctrl-single,pins = <
0x030 0x37 // P8_12 => GPIO-1[12]
>;
};
//Outputs
output_pins: pinmux_output_pins{
pinctrl-single,pins = <
0x090 0x0F // P8_7 => GPIO-2[2]
>;
};
};
};
fragmet@1 {
target = <&ocp>;//OnChipPeripherals
__overlay__ {
my_input_pins {
compatible = "gpio-of-helper";
//gpio-of-helper, bone-pinmux-helper
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&input_pins>;
In0 { //GPIO-1[12]
gpio-name = "Input0";
gpio = <&gpio2 12 0x00>;
input;
active-low;
count-rising-edge;
count-falling-edge;
};
};
gsf_output_pins {
compatible = "gpio-of-helper";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&output_pins>;
Out0 { //GPIO-2[2]
gpio-name = "Output0";
gpio = <&gpio3 2 0x00>;
output;
init-low;
};
};
};
};
};
[beagleboard] Re: debian: release candidate: 2014-12-11
Hi Robert, thanks for all the effort you put into this. I'm trying the 2015-01-06 testing release with the 3.14 kernel and have some issues and questions: 1. Since there are SGX modules availible, does that mean that hardware accelerated graphics are working on this image? 2. I'm having trouble understanding the new devicetree setup. I've had a custom devicetreeoverlay in the old image that was working as expected but I don't know how to activate it with the new kernel. Though I was able to find this <http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb> page, I'm not sure how to interpret the bulletpoints in there to get it working. 3. While playing around with the above mentioned image, I ran into some problems where I don't know if they are bugs or if I did something wrong: 1. After flashing the image to my eMMC, then running the update_kernel.sh script and rebooting, the time and date of my BBB is set somewhere in march 2015 (in the future). This causes errors with some utilities complaining about dates in the future, like apt-get. 2. Also related to apt-get, but have also seen wget complaining about invalid https certificates. Don't know what causes this but it's very annoying and I don't know of a fix to this. 3. The USB wifi dongle I am using (Ralink 2870) is working fine, but sometimes the troughput gets very low (like 5-10kb/s) and dmesg shows TONS of this error message: [10001.306251] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 9 in queue 2 Also, the syslog daemon is shooting up in CPU usage due to these messages coming in every couple milli seconds. Propably related to this problem: When booting up, my BBB is making a 80 second pause while trying to load the firmware for the dongle. Here's a section of my dmesg: [9.984258] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected [9.998530] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 5370 detected [ 10.019158] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 10.024321] usbcore: registered new interface driver rt2800usb [ 90.122572] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' [ 90.140837] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.29 Perhaps you could shed some light on the issues or point me to a tutorial. Thanks, Sebastian -- 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: debian: release candidate: 2014-12-11
> > There are no device-tree overlays with the 3.14 kernel. You'll have to > merge your device-tree changes with the main BBB device tree and build a > new dtb file. > Can you please elaborate a little on that? Can I use my old .dts file or do I need to recreate it somehow? If so, where can I find examples of how it needs to look like? Where do I need to place the dts once it's ready before calling "make" on the dtb-rebuilder? Thanks, Sebastian -- 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] New (Car) Multimedia Cape
Hello everybody, I have just received first sample boards of my CarStreamer cape for Beaglebone. CarStreamer includes: 4x50W(RMS) Class-D Audio Amplifier (FDA450) connected to McASP0 and I2C Stereo Audio Codec with 2x LineOut, 2x LineIn and 1x Mic In (TLV320AIC3104) FM/DAB receiver circuit (with RDS support, ...) connected to McASP1 and UART 5V 3A Step-Down Power Supply Infrared Remote Control receiver My plan is to use it as Car Radio replacement in my classic cars, so I can have high fidelity audio playback and latest media connectivity (via USB, SD-Card and Bluetooth) without destroying the look of my dashboard with one of these ugly aftermarket car radios. But of course the cape can also be used to extend your BeagleBone to a powerful home hifi system. The user interface is displayed on my Smartphone (I have started to develop an Android App for this based on Qt for Android which already works quite well) and I can benefit from, the phone's Navigation and voice recognition feature. Of course I can use CarStreamer as Hands-Free Telephony system with integrated Echo Cancellation and Noise Reduction feature. The hardware was designed according to Automotive OEMs requirements, so should very reliable and ruggedized. Carstreamer firmware is based on kernel 3.8 with an extension to the existing device tree. The main SW is written using the Qt framework for the application part and the audio framework is using PulseAudio. I have written a Plugin that integrates a powerful Audio Equalizing scheme incl. standard filters such as Bass, Mid, Treble, Graphics EQs but also Speaker Frequency Gain correction, Dynamic Bass boost and Limiters. It also integrates the EC/NR for Telephony and handles things like sample rate conversion and Bluetooth AADP audio. Next step for the Application is to integrate a Media Parser and Playback Engine for SD and USB media (any recommendations for libs/frameworks from your side) ? If anybody is interested in working on this project (the Android app or the Linux firmware) or on sample boards, please let me know. If am planning to release schematics and gerber files as soon as I have verified all parts of the boards. Currently more or less all peripherals of the Cape are working as expected (so yes, I can hear DAB radio stations through the speaker outputs of the Class-D amp :-)) but I had to integrate some tweaks and patches to the 3.8 kernel (e.g. enabling multi-serializer support on the McASP). Please let me know if you have any suggestions / proposals for enhancements or if you wish to know more about it. I am really planning to release the cape hardware and a aluminium extrusion housing as complete product in Q3/2014. Regards, Sebastian -- 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/groups/opt_out.
[beagleboard] zram kernel module?
Hi, I've read about the possibility of compressing parts of the ram via zram to fit more into the ram before swapping to disk is needed. I'm running Debian 7.2 with the 3.8.13-bone26 kernel and it looks like the zram module isn't included in that kernel. Are there plans to include that module or is it perhaps already included in a newer kernel update? Or would it be possible for me to somehow relatively easy (I'm a newbie) recompile the kernel to support the module? Or was the module not included as it doesn't really make sense with the BBB cpu? Thanks, Sebastian -- 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/groups/opt_out.
[beagleboard] Re: New (Car) Multimedia Cape
Hi - that's correct - I am planning a CAN transceiver (Low speed CAN) for the next board revision. Am Mittwoch, 4. Dezember 2013 13:03:11 UTC schrieb tee@gmail.com: > > With the CAN network it could be possible to have information as vehicle > speed and engine speed. > > This could allow to adapt the volume with the engine / vehicle speed. > > Le mardi 3 décembre 2013 21:39:20 UTC+1, Sebastian Wendt a écrit : >> >> Hello everybody, >> >> I have just received first sample boards of my CarStreamer cape for >> Beaglebone. >> CarStreamer includes: >> >> 4x50W(RMS) Class-D Audio Amplifier (FDA450) connected to McASP0 and I2C >> Stereo Audio Codec with 2x LineOut, 2x LineIn and 1x Mic In >> (TLV320AIC3104) >> FM/DAB receiver circuit (with RDS support, ...) connected to McASP1 and >> UART >> 5V 3A Step-Down Power Supply >> Infrared Remote Control receiver >> >> My plan is to use it as Car Radio replacement in my classic cars, so I >> can have high fidelity audio playback and latest media connectivity (via >> USB, SD-Card and Bluetooth) without destroying the look of my dashboard >> with one of these ugly aftermarket car radios. >> But of course the cape can also be used to extend your BeagleBone to a >> powerful home hifi system. >> >> The user interface is displayed on my Smartphone (I have started to >> develop an Android App for this based on Qt for Android which already works >> quite well) and I can benefit from, the phone's Navigation and voice >> recognition feature. >> Of course I can use CarStreamer as Hands-Free Telephony system with >> integrated Echo Cancellation and Noise Reduction feature. >> The hardware was designed according to Automotive OEMs requirements, so >> should very reliable and ruggedized. >> >> Carstreamer firmware is based on kernel 3.8 with an extension to the >> existing device tree. >> The main SW is written using the Qt framework for the application part >> and the audio framework is using PulseAudio. I have written a Plugin that >> integrates a powerful Audio Equalizing scheme incl. standard filters such >> as Bass, Mid, Treble, Graphics EQs but also Speaker Frequency Gain >> correction, Dynamic Bass boost and Limiters. >> It also integrates the EC/NR for Telephony and handles things like sample >> rate conversion and Bluetooth AADP audio. >> Next step for the Application is to integrate a Media Parser and Playback >> Engine for SD and USB media (any recommendations for libs/frameworks from >> your side) ? >> >> If anybody is interested in working on this project (the Android app or >> the Linux firmware) or on sample boards, please let me know. >> If am planning to release schematics and gerber files as soon as I have >> verified all parts of the boards. >> >> Currently more or less all peripherals of the Cape are working as >> expected (so yes, I can hear DAB radio stations through the speaker outputs >> of the Class-D amp :-)) but I had to integrate some tweaks and patches to >> the 3.8 kernel (e.g. enabling multi-serializer support on the McASP). >> >> Please let me know if you have any suggestions / proposals for >> enhancements or if you wish to know more about it. >> I am really planning to release the cape hardware and a aluminium >> extrusion housing as complete product in Q3/2014. >> >> >> Regards, >> Sebastian >> >> >> -- 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/groups/opt_out.
Re: [beagleboard] Re: New (Car) Multimedia Cape
Directly from the car battery / the existing car radio supply. As I integrated a Class-D amplifier instead of a Class-AB which is normally built-into existing car radios, I can get more audio output power from the same current consumption, e.g. a 10A current supply will give me ~120W audio output power, a 15A current supply up to 175W. But remember: Normally you don't need these high output power for a longer period (nobody listens to white noise or sinewaves for a longer period of time) - music is normally 10 times lower in terms of energy density. Am Mittwoch, 4. Dezember 2013 18:27:43 UTC schrieb lisarden: > > Sebastian how do you feed the analog amplifier? 150W is damn a lot > 04 дек. 2013 г. 20:27 пользователь "cmicali" > > > написал: > >> Very cool project sebastian - would definitely be interested in >> purchasing a cape and checkout out the firmware. >> >> -c >> >> >> On Tuesday, December 3, 2013 3:39:20 PM UTC-5, Sebastian Wendt wrote: >>> >>> Hello everybody, >>> >>> I have just received first sample boards of my CarStreamer cape for >>> Beaglebone. >>> CarStreamer includes: >>> >>> 4x50W(RMS) Class-D Audio Amplifier (FDA450) connected to McASP0 and I2C >>> Stereo Audio Codec with 2x LineOut, 2x LineIn and 1x Mic In >>> (TLV320AIC3104) >>> FM/DAB receiver circuit (with RDS support, ...) connected to McASP1 and >>> UART >>> 5V 3A Step-Down Power Supply >>> Infrared Remote Control receiver >>> >>> My plan is to use it as Car Radio replacement in my classic cars, so I >>> can have high fidelity audio playback and latest media connectivity (via >>> USB, SD-Card and Bluetooth) without destroying the look of my dashboard >>> with one of these ugly aftermarket car radios. >>> But of course the cape can also be used to extend your BeagleBone to a >>> powerful home hifi system. >>> >>> The user interface is displayed on my Smartphone (I have started to >>> develop an Android App for this based on Qt for Android which already works >>> quite well) and I can benefit from, the phone's Navigation and voice >>> recognition feature. >>> Of course I can use CarStreamer as Hands-Free Telephony system with >>> integrated Echo Cancellation and Noise Reduction feature. >>> The hardware was designed according to Automotive OEMs requirements, so >>> should very reliable and ruggedized. >>> >>> Carstreamer firmware is based on kernel 3.8 with an extension to the >>> existing device tree. >>> The main SW is written using the Qt framework for the application part >>> and the audio framework is using PulseAudio. I have written a Plugin that >>> integrates a powerful Audio Equalizing scheme incl. standard filters such >>> as Bass, Mid, Treble, Graphics EQs but also Speaker Frequency Gain >>> correction, Dynamic Bass boost and Limiters. >>> It also integrates the EC/NR for Telephony and handles things like >>> sample rate conversion and Bluetooth AADP audio. >>> Next step for the Application is to integrate a Media Parser and >>> Playback Engine for SD and USB media (any recommendations for >>> libs/frameworks from your side) ? >>> >>> If anybody is interested in working on this project (the Android app or >>> the Linux firmware) or on sample boards, please let me know. >>> If am planning to release schematics and gerber files as soon as I have >>> verified all parts of the boards. >>> >>> Currently more or less all peripherals of the Cape are working as >>> expected (so yes, I can hear DAB radio stations through the speaker outputs >>> of the Class-D amp :-)) but I had to integrate some tweaks and patches to >>> the 3.8 kernel (e.g. enabling multi-serializer support on the McASP). >>> >>> Please let me know if you have any suggestions / proposals for >>> enhancements or if you wish to know more about it. >>> I am really planning to release the cape hardware and a aluminium >>> extrusion housing as complete product in Q3/2014. >>> >>> >>> Regards, >>> Sebastian >>> >>> >>> -- >> 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/groups/opt_out. >> > -- 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/groups/opt_out.
[beagleboard] Gibberish messages in the terminal window
Hi, I`ve bought a Beagle Board-xM recently..It`s working fine, except that, in the terminal there is some gibberish,some sort of random symbols which we can`t read and it is coming in the first boot itself..is there something to do, please help.. -- 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] how to set up netconsole on 3.8.13? (trying to diagnose occasional system freeze)
Hi, I'm having an issue where my BeagleBoneBlack (running Debian Wheezy) freezes overnight every couple of weeks. User leds 1+2 are on (not sure about the heart beat as I disabled the led 0). I can't even get in via SSH, let alone ping the Beagle and I have to power cycle it completely. The issue usually occurs during my overnight backupninja run and has been happening for the different 3.8.13 kernel updates I've been using throughout the year. Since the logs haven't been of much use to me, I was looking into these instructions <https://www.debian-administration.org/article/492/Debugging_system_freezes> on using netconsole and have it log to my router, which comes with netcat, but no syslog server. The trouble is, the 3.8.13 bone66 kernel I currently use is lacking the netconsole kernel module. Is there a pre-built kernel available with netconsole enabled? If not, is there any other option to get the netconsole module set up or is my only option to compile the kernel from sources? In regards to building a kernel for the BBB, I've found this page <http://elinux.org/Building_BBB_Kernel>, but I'm not sure if that's still current. I'm also not sure on how to transfer / install the compiled kernel and how I could revert it if something went wrong with the install. This <https://github.com/beagleboard/linux/tree/3.8> is the current repository for 3.8.13, correct? I'm really hoping there's a way to get netconsole without me having to compile the kernel myself. Thanks for any suggestions you can offer. Sebastian -- 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] stable replacement for 3.8.13 kernel on BBB
Hi there, On the 3.8.13 kernel (currently using bone66, but it happened in previous versions too) I'm experiencing an occasional kernel panic that I can't see to avoid. If you're interested in details, I reported it here <https://github.com/beagleboard/linux/issues/12>. The issue is supposedly fixed in the 3.12 kernel (according to this report <https://github.com/archlinuxarm/PKGBUILDs/issues/749>). With the wide variety of kernel releases, I'm not sure which one is the most stable as the Beagle is running as a headless server where I'd like to have as little downtime as possible, especially since with the current issue, I have to be physically present and manually power cycle it as it won't reboot on its own. The Beagle boots from the eMMC and has an SD card for storage. The network port is a key component in my set up. Then there's also a USB thumb drive attached where tmp and log files are stored, plus there's a swap partition on it in case more memory is needed. I don't need any cape support, but would like to have basic ACPI support so I can initiate a Debian shutdown with the power button on the BBB, and on finished shutdown, the Beagle should power down on its own. Which kernel release would you recommend? I'd also appreciate a few thoughts on why you'd recommend a particular release. Thanks for your help. Sebastian -- 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] stable replacement for 3.8.13 kernel on BBB
After updating to the kernel 3.14.19-ti-r27 I can't boot my BBB anymore. User leds light up all 4 and then I mostly just see the heatbeat led and not much other activity and I can't SSH into it. I don't have a serial cable so I don't have access to any more details than that. Searching the net, I came across this thread where someone had a similar issue: https://groups.google.com/forum/embed/?place=forum/beagleboard&showsearch=true&showpopout=true&showtabs=true&hideforumtitle=true&parenturl=http%3A%2F%2Fbeagleboard.org%2FCommunity%2FForums#!searchin/beagleboard/Image$20Name$3A$20$20$203.14.19/beagleboard/rkiFSA1cXvU/mua-2y7zg8IJ Could this be an issue with my uEnv.txt file as well? Since I set up the Debian on the eMMC back in September 2013, I haven't reflashed the system and only updated it via apt-get. Any way to update the file without having to reflash the eMMC so I don't have to reinstall the system? Here's what's in my uEnv.txt http://pastebin.com/aVWXYtWH If I roll back to a backup with the 3.8.13 kernel, is there anything I should before running the kernel update to avoid this issue? Thanks, Sebastian On Monday, October 6, 2014 2:25:25 AM UTC+2, RobertCNelson wrote: > > > Information about the one i'm working on to replace the v3.8.13 tree is > here: > > http://elinux.org/Beagleboard:Capes_3.8_to_3.14 > > There's still issue with it randomly rebooting and the power button > doesn't shut it down fully yet. > > 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] stable replacement for 3.8.13 kernel on BBB
I changed the addresses, but the BBB still won't boot up. Now it's in a bootloop - At first the heartbeat lights up for half a second before all 4 leds light up. Then the leds go dark and it repeats itself. Here's my revised uEnv.txt: http://pastebin.com/E6QnFSU0 Did I make a mistake or is there still anything missing? I wonder if perhaps the hard coded address in the last line might be the culprit? Thanks, Sebastian On Wednesday, October 8, 2014 3:22:00 AM UTC+2, RobertCNelson wrote: > > On Tue, Oct 7, 2014 at 7:52 PM, Sebastian H > wrote: > > After updating to the kernel 3.14.19-ti-r27 I can't boot my BBB anymore. > > User leds light up all 4 and then I mostly just see the heatbeat led and > not > > much other activity and I can't SSH into it. I don't have a serial cable > so > > I don't have access to any more details than that. > > > > Searching the net, I came across this thread where someone had a similar > > issue: > > > https://groups.google.com/forum/embed/?place=forum/beagleboard&showsearch=true&showpopout=true&showtabs=true&hideforumtitle=true&parenturl=http%3A%2F%2Fbeagleboard.org%2FCommunity%2FForums#!searchin/beagleboard/Image$20Name$3A$20$20$203.14.19/beagleboard/rkiFSA1cXvU/mua-2y7zg8IJ > > > > > Could this be an issue with my uEnv.txt file as well? > > Since I set up the Debian on the eMMC back in September 2013, I haven't > > reflashed the system and only updated it via apt-get. Any way to update > the > > file without having to reflash the eMMC so I don't have to reinstall the > > system? > > > > Here's what's in my uEnv.txt > > http://pastebin.com/aVWXYtWH > > > > If I roll back to a backup with the 3.8.13 kernel, is there anything I > > should before running the kernel update to avoid this issue? > > conf_loadaddr="0x8200" > conf_fdtaddr="0x8800" > conf_initrdaddr="0x8808" > > Change your load addrees's it's overlapping with the kernel.. > > 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] stable replacement for 3.8.13 kernel on BBB
Ah, I missed that the hard coded address in the last line also was also a fdtaddr occurrence that I still needed to fix. However, it still didn't work afterwards, so I got rid of the variables I had set up and replaced them all with the new hard coded addresses. That did the trick - phew! Thanks again for your help! On Wednesday, October 8, 2014 12:25:30 PM UTC+2, Sebastian H wrote: > > I changed the addresses, but the BBB still won't boot up. Now it's in a > bootloop - At first the heartbeat lights up for half a second before all 4 > leds light up. Then the leds go dark and it repeats itself. > Here's my revised uEnv.txt: > http://pastebin.com/E6QnFSU0 > > Did I make a mistake or is there still anything missing? > > I wonder if perhaps the hard coded address in the last line might be the > culprit? > > Thanks, > Sebastian > > On Wednesday, October 8, 2014 3:22:00 AM UTC+2, RobertCNelson wrote: >> >> On Tue, Oct 7, 2014 at 7:52 PM, Sebastian H wrote: >> > After updating to the kernel 3.14.19-ti-r27 I can't boot my BBB >> anymore. >> > User leds light up all 4 and then I mostly just see the heatbeat led >> and not >> > much other activity and I can't SSH into it. I don't have a serial >> cable so >> > I don't have access to any more details than that. >> > >> > Searching the net, I came across this thread where someone had a >> similar >> > issue: >> > >> https://groups.google.com/forum/embed/?place=forum/beagleboard&showsearch=true&showpopout=true&showtabs=true&hideforumtitle=true&parenturl=http%3A%2F%2Fbeagleboard.org%2FCommunity%2FForums#!searchin/beagleboard/Image$20Name$3A$20$20$203.14.19/beagleboard/rkiFSA1cXvU/mua-2y7zg8IJ >> >> > >> > Could this be an issue with my uEnv.txt file as well? >> > Since I set up the Debian on the eMMC back in September 2013, I haven't >> > reflashed the system and only updated it via apt-get. Any way to update >> the >> > file without having to reflash the eMMC so I don't have to reinstall >> the >> > system? >> > >> > Here's what's in my uEnv.txt >> > http://pastebin.com/aVWXYtWH >> > >> > If I roll back to a backup with the 3.8.13 kernel, is there anything I >> > should before running the kernel update to avoid this issue? >> >> conf_loadaddr="0x8200" >> conf_fdtaddr="0x8800" >> conf_initrdaddr="0x8808" >> >> Change your load addrees's it's overlapping with the kernel.. >> >> 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: Beaglebone Black Rebooting Several Times Every Day
I switched over from kernel 3.8.13 to 3.14.19-ti-r28 (compiled with netconsole support) and after a little over 24 hours uptime, my BBB rebooted without any entries in the netconsole log or any logs on the BBB that I could find. Did anyone have any luck in troubleshooting this issue any further? In the meantime, I guess I'll try your suggestion of disabling the watchdog for now. On Thursday, September 18, 2014 11:48:22 AM UTC+2, William Hermans wrote: > > Short term, you can disable the hardware watchdog in kernel config. That > should temporarily fix your problem, and if it does not . . . bigger > mystery. > > Long term, it would be good to figure out what is triggering the watchdog. > strace on the watchdog PID will not work - I tested this myself. > > The only one thing I can think of off hand is perhaps modifying the > watchdog module to output a debug message before rebooting the system. As > to which process triggered a shutdown, and why. If possible . . . > > Will research more tomorrow it is very late ( actually early ) here. > > On Thu, Sep 18, 2014 at 12:57 AM, Thomas Olofsson > wrote: > >> >>> Forget about claiming its a hardware issue. Because it is not. We've had >>> two beaglebone blacks for close to a year, and a half now. Both are rock >>> solid, running off barrel jack power, or USB( one of each ). >>> >>> Ok well just stating facts that bbw is not rebooting and BBB is with the >> same kernel >> >> Ok i would be happy to stop guessing and actually find the problem. Could >> you give me some real advise on HOW to use the serial module appropriately. >> i do have it connected to the serial console and i have event built a >> kernel with verbosed debugging on i am just not seeing anything. >> >> So if you would like any information or dumps or whatever i am happy to >> provide that. >> >> >> -- >> 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.
[beagleboard] troubleshooting hung up SD card - processes trying to access SD card just hang
Hi, After working around the random reboot issue with kernel 3.14.19-ti-r28 by compiling the kernel without watchdog support (details here <https://groups.google.com/forum/embed/?place=forum%2Fbeagleboard&showsearch=true&showpopout=true&showtabs=true&hideforumtitle=true&parenturl=http%3A%2F%2Fbeagleboard.org%2FCommunity%2FForums&afterlogin=#!category-topic/beagleboard/beaglebone-black/vgeh336p0P4>), I ran into a different issue on my BBB (rev. A5C) today. From what I can tell, during my overnight backup last night, the SD card somehow locked up (with user led1 permanently lit) and any process that had tried to access the SD card was locked up as well. Trying to kill any of the hung processes with "sudo kill pid" wouldn't work in most cases and only resulted in an unkillable process, because after I did that, "sudo kill -9 pid" would be useless as well. So I killed most of the processes with kill -9, but I still ended up with a bunch completely hosed. The SD access was completely busted so not even a simple ls command worked anymore. That would just hang as well and I'd have to kill -9 it. The rest of the BBB was working just fine, as long as I didn't access the SD. The CPU was pretty much idle, except for postgresql process that tried to access the database that is also on the SD, but obviously couldn't anymore. I also discovered that my eMMC (from which I boot my Debian 7 while the SD card is used for storage), was almost out of space. That was mostly due to me installing a number of kernel versions over the last couple of days, which contributed to a shortage in space. Note that my tmp and log folder are on a USB drive and thus the system eMMC wasn't completely filled up and was still working. While I initially thought the low available memory to be the cause of the problem, and I certainly wish for that to be the answer, I fear it might be happening again. I do have netconsole logging running and of course, nothing was in the log. The SD card I use is a SanDisk Ultra 32GB Micro SDHC. So I'm wondering if you have any suggestions on what I can do to gather more information on the issue, should it arise again? Would I be able to do some sort of process dump, e.g. of the process handling the SD card? If so, could anyone point me to information on how that is done and what process I would have to run it on? I kind of guess that it might be the mmcqd/0 process? That's one I've seen causing an issue on the 3.8.13 kernel where it randomly froze up and I do recall that on these occasions, the usr LED1 also was always lit. My report of that issue (and the kernel panic details) can be found here <https://github.com/beagleboard/linux/issues/12>. I appreciate any pointers and assistance you can offer. Sebastian -- 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: troubleshooting hung up SD card - processes trying to access SD card just hang
Early this morning I had this <http://pastebin.com/ekrc6eYt> in my netconsole log. The Beagle was still up and running fine. I unmounted the SD card and ran e2fsck -cvf /dev/mmcblk0p2 which didn't turn up any issues <http://pastebin.com/anBuD6yU>. Any ideas what this is about? On Saturday, October 11, 2014 10:02:45 PM UTC+2, Sebastian H wrote: > > Hi, > > After working around the random reboot issue with kernel 3.14.19-ti-r28 by > compiling the kernel without watchdog support (details here > <https://groups.google.com/forum/embed/?place=forum%2Fbeagleboard&showsearch=true&showpopout=true&showtabs=true&hideforumtitle=true&parenturl=http%3A%2F%2Fbeagleboard.org%2FCommunity%2FForums&afterlogin=#!category-topic/beagleboard/beaglebone-black/vgeh336p0P4>), > > I ran into a different issue on my BBB (rev. A5C) today. From what I can > tell, during my overnight backup last night, the SD card somehow locked up > (with user led1 permanently lit) and any process that had tried to access > the SD card was locked up as well. > Trying to kill any of the hung processes with "sudo kill pid" wouldn't > work in most cases and only resulted in an unkillable process, because > after I did that, "sudo kill -9 pid" would be useless as well. So I killed > most of the processes with kill -9, but I still ended up with a bunch > completely hosed. > > The SD access was completely busted so not even a simple ls command worked > anymore. That would just hang as well and I'd have to kill -9 it. > > The rest of the BBB was working just fine, as long as I didn't access the > SD. The CPU was pretty much idle, except for postgresql process that tried > to access the database that is also on the SD, but obviously couldn't > anymore. > > I also discovered that my eMMC (from which I boot my Debian 7 while the SD > card is used for storage), was almost out of space. That was mostly due to > me installing a number of kernel versions over the last couple of days, > which contributed to a shortage in space. Note that my tmp and log folder > are on a USB drive and thus the system eMMC wasn't completely filled up and > was still working. > While I initially thought the low available memory to be the cause of the > problem, and I certainly wish for that to be the answer, I fear it might be > happening again. > > I do have netconsole logging running and of course, nothing was in the > log. > > The SD card I use is a SanDisk Ultra 32GB Micro SDHC. > > So I'm wondering if you have any suggestions on what I can do to gather > more information on the issue, should it arise again? Would I be able to do > some sort of process dump, e.g. of the process handling the SD card? If so, > could anyone point me to information on how that is done and what process I > would have to run it on? I kind of guess that it might be the mmcqd/0 > process? That's one I've seen causing an issue on the 3.8.13 kernel where > it randomly froze up and I do recall that on these occasions, the usr LED1 > also was always lit. My report of that issue (and the kernel panic details) > can be found here <https://github.com/beagleboard/linux/issues/12>. > > I appreciate any pointers and assistance you can offer. > > Sebastian > -- 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 Rebooting Several Times Every Day
The issue still happened even using the kernel compiled without any watchdog support. The netconsole log didn't include any details. It just rebooted again without any indication why. That was about 24 hours after the last restart. I still had the watchdog package installed (but with even the software watchdog disabled in the kernel, I didn't think it would do anything). Well, I now removed that, but I'm not convinced that it did cause the reboot. On Thursday, October 9, 2014 5:54:40 PM UTC+2, Sebastian H wrote: > > I switched over from kernel 3.8.13 to 3.14.19-ti-r28 (compiled with > netconsole support) and after a little over 24 hours uptime, my BBB > rebooted without any entries in the netconsole log or any logs on the BBB > that I could find. > > Did anyone have any luck in troubleshooting this issue any further? > > In the meantime, I guess I'll try your suggestion of disabling the > watchdog for now. > > > On Thursday, September 18, 2014 11:48:22 AM UTC+2, William Hermans wrote: >> >> Short term, you can disable the hardware watchdog in kernel config. That >> should temporarily fix your problem, and if it does not . . . bigger >> mystery. >> >> Long term, it would be good to figure out what is triggering the >> watchdog. strace on the watchdog PID will not work - I tested this myself. >> >> The only one thing I can think of off hand is perhaps modifying the >> watchdog module to output a debug message before rebooting the system. As >> to which process triggered a shutdown, and why. If possible . . . >> >> Will research more tomorrow it is very late ( actually early ) here. >> >> On Thu, Sep 18, 2014 at 12:57 AM, Thomas Olofsson >> wrote: >> >>> >>>> Forget about claiming its a hardware issue. Because it is not. We've >>>> had two beaglebone blacks for close to a year, and a half now. Both are >>>> rock solid, running off barrel jack power, or USB( one of each ). >>>> >>>> Ok well just stating facts that bbw is not rebooting and BBB is with >>> the same kernel >>> >>> Ok i would be happy to stop guessing and actually find the problem. >>> Could you give me some real advise on HOW to use the serial module >>> appropriately. i do have it connected to the serial console and i have >>> event built a kernel with verbosed debugging on i am just not seeing >>> anything. >>> >>> So if you would like any information or dumps or whatever i am happy to >>> provide that. >>> >>> >>> -- >>> 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: Beaglebone Black Rebooting Several Times Every Day
For the record, even with the watchdog package removed, my BBB rebooted on me again after just 7 hours of uptime. :-( Here <http://pastebin.com/UwF2fsRB>'s the kernel config I used. Searching for watchdog, there are only two entries. This is the one still enabled: CONFIG_OMAP_REMOTEPROC_WATCHDOG=y Should I disable that as well? On Sunday, October 12, 2014 6:29:26 PM UTC+2, Sebastian H wrote: > > The issue still happened even using the kernel compiled without any > watchdog support. The netconsole log didn't include any details. It just > rebooted again without any indication why. That was about 24 hours after > the last restart. > I still had the watchdog package installed (but with even the software > watchdog disabled in the kernel, I didn't think it would do anything). > Well, I now removed that, but I'm not convinced that it did cause the > reboot. > > > On Thursday, October 9, 2014 5:54:40 PM UTC+2, Sebastian H wrote: >> >> I switched over from kernel 3.8.13 to 3.14.19-ti-r28 (compiled with >> netconsole support) and after a little over 24 hours uptime, my BBB >> rebooted without any entries in the netconsole log or any logs on the BBB >> that I could find. >> >> Did anyone have any luck in troubleshooting this issue any further? >> >> In the meantime, I guess I'll try your suggestion of disabling the >> watchdog for now. >> >> >> On Thursday, September 18, 2014 11:48:22 AM UTC+2, William Hermans wrote: >>> >>> Short term, you can disable the hardware watchdog in kernel config. That >>> should temporarily fix your problem, and if it does not . . . bigger >>> mystery. >>> >>> Long term, it would be good to figure out what is triggering the >>> watchdog. strace on the watchdog PID will not work - I tested this myself. >>> >>> The only one thing I can think of off hand is perhaps modifying the >>> watchdog module to output a debug message before rebooting the system. As >>> to which process triggered a shutdown, and why. If possible . . . >>> >>> Will research more tomorrow it is very late ( actually early ) here. >>> >>> On Thu, Sep 18, 2014 at 12:57 AM, Thomas Olofsson >>> wrote: >>> >>>> >>>>> Forget about claiming its a hardware issue. Because it is not. We've >>>>> had two beaglebone blacks for close to a year, and a half now. Both are >>>>> rock solid, running off barrel jack power, or USB( one of each ). >>>>> >>>>> Ok well just stating facts that bbw is not rebooting and BBB is with >>>> the same kernel >>>> >>>> Ok i would be happy to stop guessing and actually find the problem. >>>> Could you give me some real advise on HOW to use the serial module >>>> appropriately. i do have it connected to the serial console and i have >>>> event built a kernel with verbosed debugging on i am just not seeing >>>> anything. >>>> >>>> So if you would like any information or dumps or whatever i am happy to >>>> provide that. >>>> >>>> >>>> -- >>>> 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: Beaglebone Black Rebooting Several Times Every Day
@Micka: I'm not sure how to check for increased memory usage as it's completely unpredictable when it's going to reboot. Is there some kind of logging I can enable for memory usage so it would get logged to my netconsole? As for logs, the netconsole log has nothing before the reboot occurs (just like the previous reports on this thread, including the one from RobertCNelson). Here <http://pastebin.com/P2zuPbAJ>'s the kernel log from when it booted up after the sudden reboot. I also checked the syslog and there's nothing out of the ordinary in it. It appears as if some killed the power for a second and the system just boots up again. Is there any other log I could look for? @lisarden: How would I go about checking the PMIC? Looking at the kernel log from the boot I can only see this: [5.761536] sr_init: No PMIC hook to init smartreflex [5.767135] sr_init: platform driver register failed for SR I've also checked my past kernel logs and it's always the same line. Checking the kernel config, I'm not seeing any obvious setting to enable. Can you point me in the correct direction? Thanks to both of you for your replies. On Monday, October 13, 2014 10:55:40 AM UTC+2, Mickae1 wrote: > > Did you check if memory usage is increasing ? Log file ? > > Micka, > > On Mon, Oct 13, 2014 at 10:49 AM, Sebastian H > wrote: > >> For the record, even with the watchdog package removed, my BBB rebooted >> on me again after just 7 hours of uptime. :-( >> Here <http://pastebin.com/UwF2fsRB>'s the kernel config I used. >> Searching for watchdog, there are only two entries. This is the one still >> enabled: >> CONFIG_OMAP_REMOTEPROC_WATCHDOG=y >> Should I disable that as well? >> >> On Sunday, October 12, 2014 6:29:26 PM UTC+2, Sebastian H wrote: >>> >>> The issue still happened even using the kernel compiled without any >>> watchdog support. The netconsole log didn't include any details. It just >>> rebooted again without any indication why. That was about 24 hours after >>> the last restart. >>> I still had the watchdog package installed (but with even the software >>> watchdog disabled in the kernel, I didn't think it would do anything). >>> Well, I now removed that, but I'm not convinced that it did cause the >>> reboot. >>> >>> >>> On Thursday, October 9, 2014 5:54:40 PM UTC+2, Sebastian H wrote: >>>> >>>> I switched over from kernel 3.8.13 to 3.14.19-ti-r28 (compiled with >>>> netconsole support) and after a little over 24 hours uptime, my BBB >>>> rebooted without any entries in the netconsole log or any logs on the BBB >>>> that I could find. >>>> >>>> Did anyone have any luck in troubleshooting this issue any further? >>>> >>>> In the meantime, I guess I'll try your suggestion of disabling the >>>> watchdog for now. >>>> >>>> >>>> On Thursday, September 18, 2014 11:48:22 AM UTC+2, William Hermans >>>> wrote: >>>>> >>>>> Short term, you can disable the hardware watchdog in kernel config. >>>>> That should temporarily fix your problem, and if it does not . . . bigger >>>>> mystery. >>>>> >>>>> Long term, it would be good to figure out what is triggering the >>>>> watchdog. strace on the watchdog PID will not work - I tested this myself. >>>>> >>>>> The only one thing I can think of off hand is perhaps modifying the >>>>> watchdog module to output a debug message before rebooting the system. As >>>>> to which process triggered a shutdown, and why. If possible . . . >>>>> >>>>> Will research more tomorrow it is very late ( actually early ) here. >>>>> >>>>> On Thu, Sep 18, 2014 at 12:57 AM, Thomas Olofsson >>>>> wrote: >>>>> >>>>>> >>>>>>> Forget about claiming its a hardware issue. Because it is not. We've >>>>>>> had two beaglebone blacks for close to a year, and a half now. Both are >>>>>>> rock solid, running off barrel jack power, or USB( one of each ). >>>>>>> >>>>>>> Ok well just stating facts that bbw is not rebooting and BBB is with >>>>>> the same kernel >>>>>> >>>>>> Ok i would be happy to stop guessing and actually find the problem. >>>>>> Could you give me some real advise on HOW to use the se
Re: [beagleboard] Re: Beaglebone Black Rebooting Several Times Every Day
Searching around a bit, I wonder if an old u-boot version might have anything to do with it? From what I can tell, I'm still using an u-boot release from 2013.07 . Should I be updating this? If so, what would be the safest way to do so? In /boot/uboot/tools, I noticed a couple of scripts (bootloader_update, update and update_boot_files). Would any of these work or should I get a more recent version? On Monday, October 13, 2014 12:23:29 PM UTC+2, Sebastian H wrote: > > @Micka: > I'm not sure how to check for increased memory usage as it's completely > unpredictable when it's going to reboot. Is there some kind of logging I > can enable for memory usage so it would get logged to my netconsole? > As for logs, the netconsole log has nothing before the reboot occurs (just > like the previous reports on this thread, including the one from > RobertCNelson). Here <http://pastebin.com/P2zuPbAJ>'s the kernel log from > when it booted up after the sudden reboot. > I also checked the syslog and there's nothing out of the ordinary in it. > It appears as if some killed the power for a second and the system just > boots up again. > Is there any other log I could look for? > > @lisarden: > How would I go about checking the PMIC? Looking at the kernel log from the > boot I can only see this: > [5.761536] sr_init: No PMIC hook to init smartreflex > [5.767135] sr_init: platform driver register failed for SR > I've also checked my past kernel logs and it's always the same line. > > Checking the kernel config, I'm not seeing any obvious setting to enable. > Can you point me in the correct direction? > > Thanks to both of you for your replies. > > On Monday, October 13, 2014 10:55:40 AM UTC+2, Mickae1 wrote: >> >> Did you check if memory usage is increasing ? Log file ? >> >> Micka, >> >> On Mon, Oct 13, 2014 at 10:49 AM, Sebastian H wrote: >> >>> For the record, even with the watchdog package removed, my BBB rebooted >>> on me again after just 7 hours of uptime. :-( >>> Here <http://pastebin.com/UwF2fsRB>'s the kernel config I used. >>> Searching for watchdog, there are only two entries. This is the one still >>> enabled: >>> CONFIG_OMAP_REMOTEPROC_WATCHDOG=y >>> Should I disable that as well? >>> >>> On Sunday, October 12, 2014 6:29:26 PM UTC+2, Sebastian H wrote: >>>> >>>> The issue still happened even using the kernel compiled without any >>>> watchdog support. The netconsole log didn't include any details. It just >>>> rebooted again without any indication why. That was about 24 hours after >>>> the last restart. >>>> I still had the watchdog package installed (but with even the software >>>> watchdog disabled in the kernel, I didn't think it would do anything). >>>> Well, I now removed that, but I'm not convinced that it did cause the >>>> reboot. >>>> >>>> >>>> On Thursday, October 9, 2014 5:54:40 PM UTC+2, Sebastian H wrote: >>>>> >>>>> I switched over from kernel 3.8.13 to 3.14.19-ti-r28 (compiled with >>>>> netconsole support) and after a little over 24 hours uptime, my BBB >>>>> rebooted without any entries in the netconsole log or any logs on the BBB >>>>> that I could find. >>>>> >>>>> Did anyone have any luck in troubleshooting this issue any further? >>>>> >>>>> In the meantime, I guess I'll try your suggestion of disabling the >>>>> watchdog for now. >>>>> >>>>> >>>>> On Thursday, September 18, 2014 11:48:22 AM UTC+2, William Hermans >>>>> wrote: >>>>>> >>>>>> Short term, you can disable the hardware watchdog in kernel config. >>>>>> That should temporarily fix your problem, and if it does not . . . >>>>>> bigger >>>>>> mystery. >>>>>> >>>>>> Long term, it would be good to figure out what is triggering the >>>>>> watchdog. strace on the watchdog PID will not work - I tested this >>>>>> myself. >>>>>> >>>>>> The only one thing I can think of off hand is perhaps modifying the >>>>>> watchdog module to output a debug message before rebooting the system. >>>>>> As >>>>>> to which process triggered a shutdown, and why. If possible . . . >>>>>> >>>>>&
[beagleboard] Re: troubleshooting hung up SD card - processes trying to access SD card just hang
I just managed to cause the issue again by running: sudo du -s * while in the main directory of the SD card. So this seems to be connected to intensive SD card use. Again, nothing in the logs that I could identify. Since the shutdown didn't work as expected I had to cut power. On Sunday, October 12, 2014 12:08:01 PM UTC+2, Sebastian H wrote: > > Early this morning I had this <http://pastebin.com/ekrc6eYt> in my > netconsole log. The Beagle was still up and running fine. I unmounted the > SD card and ran e2fsck -cvf /dev/mmcblk0p2 which didn't turn up any issues > <http://pastebin.com/anBuD6yU>. > > Any ideas what this is about? > > On Saturday, October 11, 2014 10:02:45 PM UTC+2, Sebastian H wrote: >> >> Hi, >> >> After working around the random reboot issue with kernel 3.14.19-ti-r28 >> by compiling the kernel without watchdog support (details here >> <https://groups.google.com/forum/embed/?place=forum%2Fbeagleboard&showsearch=true&showpopout=true&showtabs=true&hideforumtitle=true&parenturl=http%3A%2F%2Fbeagleboard.org%2FCommunity%2FForums&afterlogin=#!category-topic/beagleboard/beaglebone-black/vgeh336p0P4>), >> >> I ran into a different issue on my BBB (rev. A5C) today. From what I can >> tell, during my overnight backup last night, the SD card somehow locked up >> (with user led1 permanently lit) and any process that had tried to access >> the SD card was locked up as well. >> Trying to kill any of the hung processes with "sudo kill pid" wouldn't >> work in most cases and only resulted in an unkillable process, because >> after I did that, "sudo kill -9 pid" would be useless as well. So I killed >> most of the processes with kill -9, but I still ended up with a bunch >> completely hosed. >> >> The SD access was completely busted so not even a simple ls command >> worked anymore. That would just hang as well and I'd have to kill -9 it. >> >> The rest of the BBB was working just fine, as long as I didn't access the >> SD. The CPU was pretty much idle, except for postgresql process that tried >> to access the database that is also on the SD, but obviously couldn't >> anymore. >> >> I also discovered that my eMMC (from which I boot my Debian 7 while the >> SD card is used for storage), was almost out of space. That was mostly due >> to me installing a number of kernel versions over the last couple of days, >> which contributed to a shortage in space. Note that my tmp and log folder >> are on a USB drive and thus the system eMMC wasn't completely filled up and >> was still working. >> While I initially thought the low available memory to be the cause of the >> problem, and I certainly wish for that to be the answer, I fear it might be >> happening again. >> >> I do have netconsole logging running and of course, nothing was in the >> log. >> >> The SD card I use is a SanDisk Ultra 32GB Micro SDHC. >> >> So I'm wondering if you have any suggestions on what I can do to gather >> more information on the issue, should it arise again? Would I be able to do >> some sort of process dump, e.g. of the process handling the SD card? If so, >> could anyone point me to information on how that is done and what process I >> would have to run it on? I kind of guess that it might be the mmcqd/0 >> process? That's one I've seen causing an issue on the 3.8.13 kernel where >> it randomly froze up and I do recall that on these occasions, the usr LED1 >> also was always lit. My report of that issue (and the kernel panic details) >> can be found here <https://github.com/beagleboard/linux/issues/12>. >> >> I appreciate any pointers and assistance you can offer. >> >> Sebastian >> > -- 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: troubleshooting hung up SD card - processes trying to access SD card just hang
It's good to hear that the power down issue is fixed. However, I think I wasn't very clear in my last message. The system couldn't do a proper shutdown as the SD card had locked up, which resulted in hanging every process attempting to access the card or its contents. That's what prevented Debian from shutting down (completely unrelated to the power of the Beagle not turning off). I believe the issue I'm seeing is a different version of the one I reported on github <https://github.com/beagleboard/linux/issues/12> with the 3.8.13 kernel. This may be an issue with just my BBB, the SD card I use or perhaps an incompatibility with the both not working together properly. For now, I've rolled back to the 3.8.13 kernel as at least there I didn't used to have the random reboots the 3.14 kernel is giving me. On Monday, October 13, 2014 7:09:31 PM UTC+2, RobertCNelson wrote: > > On Mon, Oct 13, 2014 at 12:08 PM, Sebastian H > wrote: > > I just managed to cause the issue again by running: > > sudo du -s * > > while in the main directory of the SD card. So this seems to be > connected to > > intensive SD card use. > > > > Again, nothing in the logs that I could identify. Since the shutdown > didn't > > work as expected I had to cut power. > > Shutdown just got fixed, pushed out as r30, currently building.. > > 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] flash eMMC without SD card (replacing Angstrom with Debian)
Hi, I'm having an issue trying to flashed my BBB eMMC thorugh doing the common sd-card process. Here's what I've been doing: - I downloaded the latest debían from here <https://rcn-ee.net/deb/flasher/wheezy/BBB-eMMC-flasher-debian-7.6-console-armhf-2014-08-13-2gb.img.xz> - I wrote the image to my sd-card (8GB size sd-card) * unxz BBB-eMMC-flasher-debian-7.6-console-armhf-2014-08-13-2gb.img.xz* * dd if=./BBB-eMMC-flasher-debian-7.6-console-armhf-2014-08-13-2gb.img of=/dev/sdb* - Inserted the sd-card into the board, pressed/hold S2 button, apply power. - Nothing happens. Only a bunch of "C" as if the sd-card was never connected. Through uboot, I couldn't get to detect SD, nor thorugh the currently installed Angstrom distribution. Could the sd slot module have died? BTW: I was able to flash eMMC a few months ago, so I know it worked at least once. Is there a way to flash eMMC without the sd-card? I mean, is it posible to download a Debian image and copy it to the eMMC with using dd command? I found other people that does this here <http://avedo.net/653/flashing-ubuntu-13-04-or-debian-wheezy-to-the-beaglebone-black-emmc>. They copied the image to the eMMC like this. xzcat debian-wheezy-7.0.0-armhf-minfs-3.8.12-bone17.img.xz | dd of=/dev/mmcblk1 bs=1M Could I repeat this command from my Angstrom distribution in order to flash the eMMC? Thanks for your help and time Sebastian -- 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] flash eMMC without SD card (replacing Angstrom with Debian)
Thanks for the reply Robert, I've tried several times dd'ing the card (also tried Wind32 disk imager). I've noticed that even uboot nor the Angstrom distro cannot detect the card when I plug it into the board. I tried "lsblk -l" with no success. That is why I was asking, since the microSD will not be present, if I could just dd the image to the emmc directly. What do you mean about "the current setup"? On Sunday, October 19, 2014 5:53:26 PM UTC-6, RobertCNelson wrote: > On Sun, Oct 19, 2014 at 6:40 PM, Lopez Gonzalez Sebastian > > wrote: > > Hi, > > > > I'm having an issue trying to flashed my BBB eMMC thorugh doing the > common > > sd-card process. Here's what I've been doing: > > > >- I downloaded the latest debían from here > >- I wrote the image to my sd-card (8GB size sd-card) > > unxz > BBB-eMMC-flasher-debian-7.6-console-armhf-2014-08-13-2gb.img.xz > > dd > if=./BBB-eMMC-flasher-debian-7.6-console-armhf-2014-08-13-2gb.img > > of=/dev/sdb > > > >- Inserted the sd-card into the board, pressed/hold S2 button, apply > > power. > >- Nothing happens. Only a bunch of "C" as if the sd-card was never > > connected. > > > > Through uboot, I couldn't get to detect SD, nor thorugh the currently > > installed Angstrom distribution. > > > > Could the sd slot module have died? > > Just try dd'ing the card again.. > > > > > BTW: I was able to flash eMMC a few months ago, so I know it worked at > least > > once. > > > > Is there a way to flash eMMC without the sd-card? I mean, is it posible > to > > download a Debian image and copy it to the eMMC with using dd command? > > > > I found other people that does this here. They copied the image to the > eMMC > > like this. > > > >xzcat debian-wheezy-7.0.0-armhf-minfs-3.8.12-bone17.img.xz | dd > > of=/dev/mmcblk1 bs=1M > > > > Could I repeat this command from my Angstrom distribution in order to > flash > > the eMMC? > > Just a tiny problem with the kernel dynamically naming /dev/mmcblkXY > based on the presence of the microSD card. > > The current setup is just more reliable and easier for end users to > just use their device and have easily accessible storage on the > microSD not mess up the boot.. > > 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] flash eMMC without SD card (replacing Angstrom with Debian)
Thanks Jason, Despite Robert and your warnings, I just couldn't resist to dd the image from the Angstrom image to the eMMC. (I know youre probably saying WHY?!?). True is that I didn't considered USB flashing until now. But hey! something weird but good happened. - As Robert said, after dd'ing the image to the eMMC, there was an issue with the image trying to boot from mmcblk1p1 (the sd card boot partition), but since no SD was present, no Debian image was booted, but instead, a minimal image was booted. - With this virtual image I was able to mount the contents of the eMMC (mmcblk0) and see what the dd command did on it. It seems that the dd cmd was able to copy the Debian image to the eMMC. - I modified the uEnv.txt from the mmcblk0p1 (boot part) to use the /dev/mmcblk0p2 as root on the mmcargs definition (root=/dev/mmcblk0p2). - When I rebooted, this time the Debian image was booted, but not entirely. Apparently some init scripts (which the virtual image had on /scripts/init-*) kept looking for mmcblk1, causing a kernel panic. - after restablishing the uEnv.txt (loading a non-modified uEnv.txt through uboot), I rebooted, commented out the line in the boot/uEnv.txt where it defines the cmdline to run the init_flasher script, rebooted again, when out for lunch and when I came back I had the Debian image working. - What happen? I feel bad saying, I actually don't know for sure. Now I don't know if this image is stable (I was afraid to reboot when I first got it working). I will re-flash it again through USB once I make some research on what really happen. I'm not telling you this to demonstrate that my procedure worked, but instead I wanted to get your opinion. One thing is sure, this is not the correct procedure. The USB flashing, as you pointed out, seems the right way to do it when no SD card slot is available. I appreciate your comments on this Thanks a lot Sebastian -- 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] Enabling GPIO-Pin P8_20
I have been trying to use the different GPIO-Pins reserved for eMMC and tried to use them as GPIO input Pins. Specifically I have been trying to enable P8_20(Pin 63) as input Pin. My current problem is that even with no input connection this pin is constantly high and after connecting it to a circuit with a test LED, the LED started to glow. I have been following these two tutorials in order to enable the conflicting PINS: - https://github.com/modmaker/BeBoPr/wiki/BeBoPr-goes-Black - http://blog.machinekit.io/2013/06/black-is-white-is-grey.html Specifically my steps were the following; - Create a bootable SD-card with the latest offical linux image(3.8.13-bone70) - Enable the eMMC hardware reset pin while logged onto the Beaglebone eMMC using the mmc-utils-program,from git clone https://kernel.googlesource.com/pub/scm/linux/kernel/git/cjb/mmc-utils. I chose /dev/mmcblk0 as device for the command, not sure if that was the right one - Disabled the boot on the beaglebone with the command " sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1024 count=1024", executed while logged in on the Beaglebone - Disabled the eMMC and HDMI cape through the command in the uEntv.txt on the SD-card (found the uEntv.txt file in /boot, uboot is an empty folder on the SD-card) - Added "mmc dev 1\n mmc rstn 1\n gpio set 52" to the beginning of the uEntv.txt file(\n just inserted here to save space the uEntv.txt file has newlines instead) - Wrote a Device Tree overlay file that sets the status of Pin 63(33in pins file) to 37 (from the original 32) - Loaded my Device Tree Overlay into the Slots file in capemngr - Echoed 63 to the export file in gpios After all these steps the Pin is still displaying a high value without any kind of circuitry attached. The Beaglebone is booting correctly from SD and the Slots file shows that the eMMC cape has been disabled. The Pins file displays 37 as value for Pin 33. The exported direction is set to input. I have executed reboots between most of the above mentioned steps. I have also decompiled the am335x-boneblack.dtb file and ensured that the status of mmc2 is set to disabled. I am unfortunatly a Computer Scientist with limited background on electronics, so I am unsure if I have to connect something to the Beaglebone or if I have to set anymore values. I also can not use different Pins as I am working with a Cape that requires this Pin and some additional ones as input Pins. Any feedback or tipps are appreciated. Best regards Sebastian -- 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] Enabling GPIO Pin 1_31 on Beaglebone Black
Hello everyone, I have been trying to configure the GPIO Pin 1_31 on the Beaglebone Black to recieve input signals. I have followed the following tutorials: - http://blog.machinekit.io/2013/06/black-is-white-is-grey.html - https://github.com/modmaker/BeBoPr/wiki/BeBoPr-goes-Black My specific steps were the following: - Enable Reset line on the Beglebone Black with the program mmc-utils(https://kernel.googlesource.com/pub/scm/linux/kernel/git/cjb/mmc-utils) executed on mmcblk0 as argument - Disable boot on the Beaglebone - Boot from SD-card - Changed uEnv.txt - Added gpio set 52 - Added mmc dev 1 - Added mmc rstn 1 - Disabled loading of the mmc and hdmi overlays - Set Pin 33 to mode 37 with a custom device tree overlay - Export the Pin for input mode Applying these steps results in the Input being high constantly even with no connected curcuit. Connecting a curcuit with an LED results in the LED glowing. Using the Pin as Output works fine. Using a pre-built device tree overlay results in the Pin constantly being low even if a current is applied. The curcuit used works with other none mmc allocated pins. I am grateful for any kind of feedback or tips Best Regards Sebastian -- 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] Enabling GPIO1_31 for usage as input pin
Hello everyone, I have been trying to configure the GPIO Pin 1_31 on the Beaglebone Black to recieve input signals. I have followed the following tutorials: - http://blog.machinekit.io/2013/06/black-is-white-is-grey.html - https://github.com/modmaker/BeBoPr/wiki/BeBoPr-goes-Black My specific steps were the following: - Enable Reset line on the Beglebone Black with the program mmc-utils(https://kernel.googlesource.com/pub/scm/linux/kernel/git/cjb/mmc-utils) executed on mmcblk0 as argument - Disable boot on the Beaglebone - Boot from SD-card - Changed uEnv.txt - Added gpio set 52 - Added mmc dev 1 - Added mmc rstn 1 - Disabled loading of the mmc and hdmi overlays - Set Pin 33 to mode 37 with a custom device tree overlay - Export the Pin for input mode Applying these steps results in the Input being high constantly even with no connected curcuit. Connecting a curcuit with an LED results in the LED glowing. Using the Pin as Output works fine. Using a pre-built device tree overlay results in the Pin constantly being low even if a current is applied. The curcuit used works with other none mmc allocated pins. I am grateful for any kind of feedback or tips Best Regards Sebastian -- 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: No USB connection... and no wifi no more
I have the same problem on both windows and Linux. I bought two Beaglebone Blues at the same tome. On the first Beaglebone, the USB works fine but on the second Beaglebone, the USB does not work. Searching the internet for a resolutitime. Anyone on this thread find a resolution? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/0524253c-fde0-4573-9f63-56b6e7c5028c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: No USB connection... and no wifi no more
I booted the Beaglebone with UART0 (like Graham suggested) and found out the disk wasn't cleanly unmounted. Ran fsck and now the USB works again. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/4438d04d-613c-43d0-9b96-9151168f422a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
