[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.
[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] 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: registering asynchronous events on kernel thread in user space
Hi I too have the same question, have you found any answer ? thanks On Thursday, August 28, 2014 3:14:12 PM UTC+5:30, 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: 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("<1>Hello 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: 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.
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 wrote: > > From: neo > Reply-To: "beagleboard@googlegroups.com" > Date: Saturday, September 13, 2014 at 6:17 AM > To: "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 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 s
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 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 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] 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 wrote: > On Tue, Sep 23, 2014 at 1:00 PM, neo 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 wrote: > On Tue, Sep 23, 2014 at 1:13 PM, neo star 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: Recomended USB Hub
Is there any particular brand you recomend On Thu, Oct 9, 2014 at 11:02 PM, Peter Gregory 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.
