Re: [beagleboard] Re: Recomended USB Hub
Is there any particular brand you recomend On Thu, Oct 9, 2014 at 11:02 PM, Peter Gregory talkto...@gmail.com wrote: If you are planning on plugging in multiple devices I'd suggest getting a powered hub. I've had good luck with a plugable USB 2.0 4 port hub. $17 on amazon with free shipping. It comes with a 2.5 amp power supply that can run the Beaglebone Black and the hub (splice in power lines plug) -- 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/kdvK71ePQuw/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.
Re: [beagleboard] OMAP related patches to be applied on top of vanilla Linux Kernel
So they are part of the vanilla kernel ? If so what customizations are done to the vanilla kernel before releasing an image for BBB On Tue, Sep 23, 2014 at 11:33 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Sep 23, 2014 at 1:00 PM, neo prag.in...@gmail.com wrote: Hi I like to know the location of OMAP related patches like for example GPIO drivers, UART, I2C are maintained and updated ? This i am asking because i like to know how they are written. I am assuming that when an updated kernel for BBB is released maintainers take the vanilla Kernel and apply the above patch for these drivers and release it. This is correct ? GPIO/UART/I2C are all mainline for the OMAP. 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 a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/Ue4L6-QsP7k/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.
Re: [beagleboard] OMAP related patches to be applied on top of vanilla Linux Kernel
So for my understanding https://github.com/beagleboard/linux is the location of kernel used in BBB and 3.8 (current stable) https://github.com/RobertCNelson/linux-stable-rcn-ee/compare/v3.8.13...3.8.13-bone66 3.14 (next stable) https://github.com/RobertCNelson/linux-stable-rcn-ee/compare/v3.14.19...3.14.19-ti-r25 contains patches still not in the main line kernel AKA development branch. On Tue, Sep 23, 2014 at 11:58 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Sep 23, 2014 at 1:13 PM, neo star prag.in...@gmail.com wrote: So they are part of the vanilla kernel ? If so what customizations are done to the vanilla kernel before releasing an image for BBB Well you can look this up yourself, as everything is located here: https://github.com/beagleboard/linux 3.8 (current stable) https://github.com/RobertCNelson/linux-stable-rcn-ee/compare/v3.8.13...3.8.13-bone66 3.14 (next stable) https://github.com/RobertCNelson/linux-stable-rcn-ee/compare/v3.14.19...3.14.19-ti-r25 This of course, doesn't showcase the fact you can run mainline just fine, everything above is patches being submitted/worked on/etc. 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 a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/Ue4L6-QsP7k/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.
Re: [beagleboard] Re: BeagleBone Black switching to 3.14 kernel
Hi Charles the BBB is a single core Soc On Thu, Sep 18, 2014 at 10:47 PM, Charles Steinkuehler char...@steinkuehler.net wrote: On 9/18/2014 11:40 AM, Robert Nelson wrote: sudo apt-get update sudo apt-get install linux-image-3.14.19-ti-r22 has: CONFIG_PREEMPT_VOLUNTARY In the past, preempt broke a lot of things. So i'm always hesitant to enable it by default across the board. PREEMPT has a tendency to tickle obscure bugs in non-SMP safe kernel code. Many nasty bugs were uncovered as the PREEMPT code got merged into the kernel. Now the core kernel is very SMP safe, but there are still a lot of drivers (ie: vendor-supplied code for single-core SoCs) that are not SMP clean. As multi-core ARM systems become more common, the situation should improve (as it did with the x86 over time). -- Charles Steinkuehler char...@steinkuehler.net -- 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/4eDQvQOkUkc/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.
Re: [beagleboard] Re: Only pwr led lits
Also have a look at the link http://blog.lemoneerlabs.com/3rdParty/Darling_BBB_30fps_DRAFT.html#x1-6000doc On Fri, Sep 19, 2014 at 1:38 AM, neo prag.in...@gmail.com wrote: So for my understanding you flashed the eMMC from the sdcard and it did not work ? On Thursday, September 18, 2014 3:29:12 PM UTC+5:30, Benedek wrote: Hi, I updated the Angstrom Distribution 2013-09-04 image on my BBB. The process seem to run well. After it ended, I get the SD card out from the BBB, and restarted it, with plugging in again the BBB via USB. But then only the power led lits, and nothing else. I've repeated the process many times, even with Debian 2014-05-04, but the result is the same. Could anyone help me? Thanks, Ben -- 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/rbyjinbNGYo/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.
Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space
Hi John Thanks for the link. On Sun, Sep 14, 2014 at 3:44 AM, John Syn john3...@gmail.com wrote: From: neo prag.in...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Saturday, September 13, 2014 at 6:17 AM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space Hi Brandon I am learning to use the BBB to interface a 802.15.4 radio to BBB without a MCU between BBB and CC2500. I want to remove the MCU and interface directly to the Kernel. Are you referring to the CC2520? If so, there is a driver in the linux-wpan repo: https://github.com/linux-wpan If you want support, send “subscribe linux-wpan” e-mail to: majord...@vger.kernel.org Regards, John So for this i have to service interrupts which will be a gpio interrupt to BBB if a new packet arrives. So that the reason for the Doubts n questions. And also the reason why i want to know which method is faster or better. But I think that i have to do some profiling as u pointed out. Will post the results ASAP here. Thanks for the reply On Friday, September 12, 2014 1:19:26 AM UTC+5:30, Brandon I wrote: OK, one more time. All userspace interrupts work the same, pru, network driver, *anything*. The process blocks until the interrupt handler unblocks the process with a semaphore or completion in the kernel. For example, when you read data for a socket connection, it blocks. When data comes in, the data is copied to userspace, the read function unblocks. Again, this is all explained in that LDD3 chapter I linked. There's no other way to do it, except going around the kernel and polling memory. 1. This isn't a realtime kernel. You will always have jitter. Does it matter? I don't know what you're doing. You don't need to use polling. UIO and select doesn't use polling. 2. Using select (and even poll() since it's just a wrapper for select()) on the gpio doesn't poll. It's interrupt driven. Same method as described. 3. Same method as described. If you use the PRU, it will be the same method to notify your userspace application with the same shortcomings, unless you put all of your code into the pru. If you want deterministic timing, you either need a realtime kernel, or put all your code on the pru. But, I can guarantee you don't need deterministic timing, and I can guess that you're worrying about nothing Seriously, do some benchmarks with sysfs. It's only a few lines of code. And, there are all sorts of userspace hardware drivers that use userspace interrupts out there including graphics and network. If you only need to know when a gpio event happened, and process it later (it will always be later since this isn't a realtime kernel or in the pru), you can timestamp the event. I believe you can do this with the enhanced timers, and I know you can do this in the pru. So it would go, event happens, pru/etimer hardware timestamps the event, sends interrupt, userspace gets interupt using the only way possible, userspace reads timestamp from hardware, pretends that the event happened at the timestamp for any calculations. If you explained what you were doing, we could advise you better. Good luck! On Thursday, September 11, 2014, neo prag@gmail.com wrote: Hi Brandon I agree with jitter involved with processing interrupts and 100% cpu usage during polling for the same, so is there no way to let the user-space know that interrupt has occurred apart from polling ? The reason why i said pseudo-interrupt is because we are polling and waiting there which is same as watching a flag in a UART register for RX flag to set. I am curious as to how interrupts for Ethernet and usb are written. I am guessing that the ISR will use the DMA to transfer bytes to user-space. But even in that case the userspace should know that a new data has arrived. Then hoe to synchronize the kernel space and user-space if there are to share a data ? Thanks... On Thursday, September 11, 2014 2:26:15 AM UTC+5:30, Brandon I wrote: pseudo-interrupt from user space There's nothing pseudo about it. Again, any usual way to have a userspace application respond to an interrupt will be the exact same. The kernel will block the userspace process until the interrupt is seen. The only real alternative is burning up the cpu with memory polling, which appears to be what the BBIOlib method uses. So, your latency is limited to your poll speed (which can be faster than interrupts). But, if you have a constant poll for minimum latency, lets hope you're not trying to do something important elsewhere since your cpu usage will be at 100%, and you'll be maximizing process to process context switching! For 4, The only difference between a userspace and kernel space interrupt handler is where the code is that responds to the interrupt. You will only benefit from writing your own
[beagleboard] Re: registering asynchronous events on kernel thread in user space
Hi Brandon I read through the link, very informative thanks.I can create a thread to do the polling and signal me when its ready. But how to really write an ISR in arm. I see a lot of guides but they say that it will work in Intel processors but they are not sure about ARM. For sure from my readings i see that i need a kernel object to handle an ISR, But how to really do that. One example about how to handle interrupts is in http://stackoverflow.com/questions/15245626/simple-interrupt-handler-request-irq-returns-error-code-22 The other one is request_threaded_irq() as mentioned by Kavita in the above post. Is there any How to and guide to writing one. Any links. Thanks. On Wednesday, September 10, 2014 12:59:08 AM UTC+5:30, Brandon I wrote: See UIO: https://www.kernel.org/doc/htmldocs/uio-howto/ The uio_pruss.c driver that comes with the pru package is a good example. I have written a kernel module that registers interrupts on the rising edge on a GPIO pin and want to relay this message to user space. The sysfs gpio interface already does this. Check out the code. On Thursday, August 28, 2014 2:44:12 AM UTC-7, sid...@gmail.com wrote: I have read online that we can't handle interrupts from user space. Instead - 1) We can write a kernel thread and have that thread wait on an event. 2) Once the interrupt occurs, send one asynchronous event from the kernel module/driver to user space where we will have one signal handler with FASYNC to tackle this I have written a kernel module that registers interrupts on the rising edge on a GPIO pin and want to relay this message to user space. How do I go about implementing the above? 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: Peripheral Interrupt on PRU-ICSS
Hi rakesh i want to know what you mean by I have PWM interrupts generated on ARM side and validated though a kernel ISR on linux side in AM335x This is a question not related to the topic but can you help me here to understand. Thanks. On Wednesday, August 20, 2014 2:11:33 PM UTC+5:30, rakesh.safir wrote: Hi, I have PWM interrupts generated on ARM side and validated though a kernel ISR on linux side in AM335x. I want to route the PWM interrupts to PRU-ICSS. Any information on how can this be achived will be hugely appreciated. Cheers !! Rakesh -- 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: detecting interrupt on GPIO in kernel module
Hi
I see that some function definitions are missing in your code. Can you
share those as well, so that i too can try and figure out the problem.
Especially the functions like gpio_to_irq() ...
Thanks.
On Tuesday, August 26, 2014 7:38:01 PM UTC+5:30, Siddarth Sharma wrote:
I am toggling the input into a GPIO line on my BeagleBone from high to low
every 500 ms using an Atmel uC. I have registered a handler for this in my
Linux Kernel Module, but the handler is not being called for some reason.
My module code is -
#define GPIO 54
#define GPIO_INT_NAME gpio_int
#define GPIO_HIGH gpio_get_value(GPIO)
#define GPIO_LOW (gpio_get_value(GPIO) == 0)
short int irq_any_gpio= 0;
int count =0;
enum { falling, rising } type;
static irqreturn_t r_irq_handler(int irq, void *dev_id)
{
count++;
printk(KERN_DEBUG interrupt received (irq: %d)\n, irq);
if (irq == gpio_to_irq(GPIO))
{
type = GPIO_LOW ? falling : rising;
if(type == falling)
{
printk(gpio pin is low\n);
}
else
printk(gpio pin is high\n);
}
return IRQ_HANDLED;
}
void r_int_config(void) {
if (gpio_request(GPIO, GPIO_INT_NAME ))
{
printk(GPIO request failure: %s\n, GPIO_INT_NAME );
return;
}
if ( (irq_any_gpio = gpio_to_irq(GPIO)) 0 ) {
printk(GPIO to IRQ mapping failure %s\n,GPIO_INT_NAME );
return;
}
printk(KERN_NOTICE Mapped int %d\n, irq_any_gpio);
if (request_irq(irq_any_gpio,(irq_handler_t ) r_irq_handler,
IRQF_TRIGGER_HIGH, GPIO_INT_NAME, NULL))
{
printk(Irq Request failure\n);
return;
}
return;
}
void r_int_release(void) {
free_irq(gpio_to_irq(GPIO), NULL);
gpio_free(GPIO);;
return;
}
int init_module(void)
{
printk(1Hello World\n);
r_int_config();
return 0;
}
On calling insmod interrupt_test.ko, i get the following message
[ 76.594543] Hello World
[ 76.597137] Mapped int 214
But now when I start toggling the input into this gpio pin, the interrupt
handler doesn't get called and the message - interrupt received is not
being displayed.
How do I solve this ? What's causing the 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: uboot/drivers/mtd/nand: how to enable on-die-ecc on a flash chip / how to send command to flash chip
Am Dienstag, 4. Februar 2014 16:42:28 UTC+1 schrieb st...@gmx.li:
Can someone please give me a hint howto send a command to a flash chip, in
my case to enable on-die-ecc?
I found at some place how to read the byte, but I don't understand how to
modify it for write (chip-write_byte isn't the way):
* ## */
/* MICRON: Test on-die ECC status; return: 1/On or 0/Off */
int test_on_die_ecc(struct mtd_info *mtd)
{
struct nand_chip *chip = mtd-priv;
int addr = 0x90;
uint8_t data, data_;
chip-cmdfunc(mtd,NAND_CMD_GET_FEATURES,addr,-1);
ndelay(2000);
data = chip-read_byte(mtd);
return((data 0x08) ? 1 : 0 );
}
---
Can you help me what do I have to do send this below?
ECC can be enabled using the following sequence:
EFh(cmd)-90h(addr)-08h(data)-00h(data)-00h(data)-00h(data)-wait(tFEAT).
ECC can be disabled using the following sequence:
EFh(cmd)-90h(addr)-00h(data)-00h(data)-00h(data)-00h(data)-wait(tFEAT).
- 2 days later:
I could solve it on my own. :)
int set_on_die_ecc(struct mtd_info *mtd)
{
struct nand_chip *chip = mtd-priv;
int addr = 0x90;
uint8_t buf[8] = {8,0,0,0,0,0,0,0};
chip-cmdfunc(mtd,NAND_CMD_SET_FEATURES,addr,-1);
ndelay(1000);
chip-write_buf(mtd, buf, 8);
printf(set_on_die_ecc\n);
OnDieECC_enabled = 1;
return ( 0 );
}
--
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] uboot/drivers/mtd/nand: how to enable on-die-ecc on a flash chip / how to send command to flash chip
Can someone please give me a hint howto send a command to a flash chip, in
my case to enable on-die-ecc?
I found at some place how to read the byte, but I don't understand how to
modify it for write (chip-write_byte isn't the way):
* ## */
/* MICRON: Test on-die ECC status; return: 1/On or 0/Off */
int test_on_die_ecc(struct mtd_info *mtd)
{
struct nand_chip *chip = mtd-priv;
int addr = 0x90;
uint8_t data, data_;
chip-cmdfunc(mtd,NAND_CMD_GET_FEATURES,addr,-1);
ndelay(2000);
data = chip-read_byte(mtd);
return((data 0x08) ? 1 : 0 );
}
---
Can you help me what do I have to do send this below?
ECC can be enabled using the following sequence:
EFh(cmd)-90h(addr)-08h(data)-00h(data)-00h(data)-00h(data)-wait(tFEAT).
ECC can be disabled using the following sequence:
EFh(cmd)-90h(addr)-00h(data)-00h(data)-00h(data)-00h(data)-wait(tFEAT).
--
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.
