reboot fail when using nandflash
Hi, Does anybody face the following problem? Any comment? Thanks a lot. Steve I storage kernel and ramdisk on nandflash and boot evm form it, but I can't reboot my system by submit shutdown –f –r now or halt -f both and system will show system is reboot now or Booting PSP Boot Loader and then no any response. As I know, Booting PSP Boot Loader was printed by boot loader, but I don't know why it's not go on. Any commands? P.S halt and shutdown were copy form evm hard disk (under /sbin) not soft link to busybox, any I copy all /etc form evm hard disk to my ramdisk. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: reboot fail when using nandflash
Hm, DaVinci soft reset is implemented as a watchdog timer reset (see /include/asm/arch/system.h and arch/arm/mach-davinci/time.c: davinci_watchdog_reset()) I don't know whether this watchdog reset resets MMU and if it doesn't, whether the TI UBL takes steps to disable MMU before trying to access NAND address space... By the way, we recently stopped using TI UBL, as we manufactured some Davinci boards with STM 512R3A NAND and it had trouble booting from them. Basically the replacement NAND part has the same geometry as Samsung K9K1208Q0C (NAND on the DaVinci EVM), however manufacturer is STM (not Samsung). Since STM manufacturer code (0x20) is different from Samsung's (0xec) and TI UBL checks not only the model id but also the manufacturer id, the UBL is unable to boot. This is very frustrating as this STM NAND flash that has the same geometry, functionality and interface as Samsung's. Btw did TI release sources of their UBL? We implemented our own, but it doesn't follow TI's NAND partitioning scheme (as we didn't write the whole bootloader from scratch, but ported it from an existing codebase). We wanted to patch the official UBL, but our TI contacts refused to disclose the UBL source code :( Ivan Steve Yeh wrote: Hi, Does anybody face the following problem? Any comment? Thanks a lot. Steve I storage kernel and ramdisk on nandflash and boot evm form it, but I can't reboot my system by submit shutdown –f –r now or halt -f both and system will show system is reboot now or Booting PSP Boot Loader and then no any response. As I know, Booting PSP Boot Loader was printed by boot loader, but I don't know why it's not go on. Any commands? P.S halt and shutdown were copy form evm hard disk (under /sbin) not soft link to busybox, any I copy all /etc form evm hard disk to my ramdisk. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source begin:vcard fn:Ivan Tonchev n:Tonchev;Ivan org:Multimedia Solutions (MMS);IT adr:;;Tintiava 15;Sofia;Sofia;1113;Bulgaria email;internet:[EMAIL PROTECTED] title:Network Administrator tel;work:+359 2 868 9186 tel;cell:+359 88 608 9664 url:http://www.mm-sol.com version:2.1 end:vcard ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: reboot fail when using nandflash
Steve - some more questions to help us track this down :- Is this on standard evm or custom hardware? Which version of Uboot are you using? - Is it the latest from the ti extranet? Which version of linux kernel? - the one that comes with dvevm v1.10? Does reboot work successfully from NOR or is it also failing from NOR? Does reboot work successfully when using the MV filesystem, rather than your ramdisk? ~roger From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Yeh Sent: 02 March 2007 10:41 To: davinci-linux-open-source@linux.davincidsp.com Subject: reboot fail when using nandflash Hi, Does anybody face the following problem? Any comment? Thanks a lot. Steve I storage kernel and ramdisk on nandflash and boot evm form it, but I can't reboot my system by submit shutdown -f -r now or halt -f both and system will show system is reboot now or Booting PSP Boot Loader and then no any response. As I know, Booting PSP Boot Loader was printed by boot loader, but I don't know why it's not go on. Any commands? P.S halt and shutdown were copy form evm hard disk (under /sbin) not soft link to busybox, any I copy all /etc form evm hard disk to my ramdisk. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Cache coherency issue?
FWIW, I'm planning on distributing the sources to at least the skeletons
in future version of Codec Engine. You can then see the cache
operations in all their glory.
Not sure which version of CE you have, but here is a snippet of the
SPHENC skeleton (DSP-side). In red, I've highlighted the cacheWbInv
call(s) _right after_ it invokes the codec's process() call. This is
from Codec Engine 1.02:
/* invalidate cache for all input and output buffers */
for (i = 0; i inBufs.numBufs; i++) {
Memory_cacheInv(inBufs.bufs[i], inBufs.bufSizes[i]);
}
for (i = 0; i outBufs.numBufs; i++) {
Memory_cacheInv(outBufs.bufs[i], outBufs.bufSizes[i]);
}
/* unmarshall outArgs based on the size of inArgs */
pOutArgs = (ISPHENC_OutArgs
*)((UInt)((msg-cmd.process.inArgs)) +
msg-cmd.process.inArgs.size);
/* make the process call */
msg-visa.status = SPHENC_process(handle,
inBufs, outBufs,
(msg-cmd.process.inArgs), pOutArgs);
/* flush cache for all output buffers */
for (i = 0; i outBufs.numBufs; i++) {
Memory_cacheWbInv(outBufs.bufs[i], outBufs.bufSizes[i]);
}
So, yes, the Codec Engine framework should be managing your outBufs'
cache for you.
Perhaps you can double-check that your outBufs.numBufs and
outBufs.bufSizes[] is correct? outBufs.bufSizes[] should be the size of
the _buffer_ not necessarily the size of the _contents_ of the buffer.
And the codec shouldn't be changing either of these values - they're
read-only from the codec's perspective.
It might be interesting to turn on trace as Scott describes below - it
should show exactly what cache operations are going on. It'll be dumped
into DSP-side memory, and can be 'scooped out' and displayed by the ARM
using either TraceUtils (preferred) or, if your app isn't using
TraceUtils, Engine_fwriteTrace().
Hope that helps.
Chris
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Andy Ngo
Sent: Friday, March 02, 2007 2:45 AM
To: Gary, Scott; Adam Dawidziuk
Cc: davinci-linux-open-source @linux.davincidsp.com
Subject: Re: Cache coherency issue?
Nope, that didn't help. I tried allocating 1024 bytes for the
output buffer (I only needed 105 bytes as stated
in my previous email) and I still have the stale data problem
unless I explicitly do a writeback
invalidate. So that eliminates the integral number of cache
lines requirement as the culprit
for my cache problem. I used Memory_contigAlloc so that should
take care of the contiguous
requirement, how do you ensure the cache-line alignment
requirement?
My DSP codec is not writing to the IN buffers and the OUT
buffers are not written to by my ARM application
so that eliminates Scott's points 2 and 3 as the culprit.
Regards,
Andy
- Original Message
From: Andy Ngo [EMAIL PROTECTED]
To: Gary, Scott [EMAIL PROTECTED]; Adam Dawidziuk
[EMAIL PROTECTED]
Cc: davinci-linux-open-source @linux.davincidsp.com
davinci-linux-open-source@linux.davincidsp.com
Sent: Thursday, March 1, 2007 10:02:59 PM
Subject: Re: Cache coherency issue?
Scott,
Thanks for your response. On the ARM side, I used
Memory_contigAlloc to allocate the input and output buffers;
doesn't Memory_contigAlloc automatically handle the contiguous
and cache-line alignment requirements? You
say the buffers must be sized as an integral number of cache
lines; how do I know what is that number of
cache lines or where do I find that out? I think the integral
number may be my problem since I only allocate
just enough data that I used for the output buffer; the size of
my output buffer is 105 bytes, which I doubt is an
integral number. Thanks for your advice, I'll try it out soon
and let you know.
Regards,
Andy
- Original Message
From: Gary, Scott [EMAIL PROTECTED]
To: Andy Ngo [EMAIL PROTECTED]; Adam Dawidziuk
[EMAIL PROTECTED]
Cc: davinci-linux-open-source @linux.davincidsp.com
davinci-linux-open-source@linux.davincidsp.com
Sent: Thursday, March 1, 2007 8:15:51 PM
Subject: RE: Cache coherency issue?
Andy,
The framework should indeed be handling the necessary buffer
invalidates before, and writebacks after, calling the algorithm's
process function.
To verify this you could try turning on trace, (as in the
archived message), and you should see similar statements indicating the
operations on the specific buffers. The mask
Re: Cache coherency issue?
Thank you Chris After going through my ARM code carefully, per
your suggestion, I found out I had assigned outBufs.bufSizes to 0!
I recently did a lot of cleaning up the code and renaming and replacing
constants to make stuff more readable; one of my replacements had
forced outBufs.bufSizes to 0, duh! That's the reason I was getting stale data
and an explicit call to Memory_cacheWbInv was required (or
apparently by just including a call to GT_trace). Thank you so much for yours
and Scott's help. Hopefully this was a lesson learned
that I share with others who may be having the same problem.
I have a newbie question about TraceUtil, I'm new to using it so please forgive
me. I have the following in my ARM configuration .cfg file.
var TraceUtil = xdc.useModule('ti.sdo.ce.utils.trace.TraceUtil');
TraceUtil.attrs = TraceUtil.DEFAULT_TRACING
This only turns on log warning (GT_6CLASS) and error (GT_7CLASS) messages.
How do I enable other level tracing (GT_CLASS 0 to 5)
on the fly. Scott mentioned about setting TRACEUTIL_DSP0TRACEMASK=OM=012.
Where is that set, the runtime environment shell or
in some configuration file? Thanks.
Regards,
Andy
- Original Message
From: Ring, Chris [EMAIL PROTECTED]
To: Andy Ngo [EMAIL PROTECTED]; Gary, Scott [EMAIL PROTECTED]; Adam
Dawidziuk [EMAIL PROTECTED]
Cc: davinci-linux-open-source @linux.davincidsp.com
davinci-linux-open-source@linux.davincidsp.com
Sent: Friday, March 2, 2007 9:19:04 AM
Subject: RE: Cache coherency issue?
DIV {
MARGIN:0px;}
FWIW, I'm planning on distributing the sources to at
least the skeletons in future version of Codec Engine. You can then see
the cache operations in all their glory.
Not sure which version of CE you have, but here is a
snippet of the SPHENC skeleton (DSP-side). In red, I've
highlighted the cacheWbInv call(s) _right after_ it invokes the
codec's process() call. This is from Codec Engine
1.02:
/* invalidate cache for all input and output buffers
*/
for (i
= 0; i inBufs.numBufs; i++)
{
Memory_cacheInv(inBufs.bufs[i],
inBufs.bufSizes[i]);
}
for (i =
0; i outBufs.numBufs; i++)
{
Memory_cacheInv(outBufs.bufs[i],
outBufs.bufSizes[i]);
}
/* unmarshall outArgs based on the size of inArgs
*/
pOutArgs = (ISPHENC_OutArgs *)((UInt)((msg-cmd.process.inArgs))
+
msg-cmd.process.inArgs.size);
/* make the process call
*/
msg-visa.status =
SPHENC_process(handle,
inBufs,
outBufs,
(msg-cmd.process.inArgs), pOutArgs);
/* flush cache for all output buffers
*/
for (i
= 0; i outBufs.numBufs; i++)
{
Memory_cacheWbInv(outBufs.bufs[i],
outBufs.bufSizes[i]);
}
So, yes, the Codec Engine framework should be managing
your outBufs' cache for you.
Perhaps you can double-check that your outBufs.numBufs and outBufs.bufSizes[]
is correct? outBufs.bufSizes[] should be the size of the _buffer_
not necessarily the size of the _contents_ of the buffer. And the codec
shouldn't be changing either of these values - they're read-only from the
codec's perspective.
It might be interesting to turn on trace as Scott
describes below - it should show exactly what cache operations are going
on. It'll be dumped into DSP-side memory, and can be 'scooped out' and
displayed by the ARM using either TraceUtils (preferred) or, if your app isn't
using TraceUtils, Engine_fwriteTrace().
Hope that helps.
Chris
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Cache coherency issue?
Andy,
Glad to hear you found the problem!
SPRUE67, section 4.6 describes how to specify the masks. The easiest
way is via the command line, as shown below (cut from SPRUE67).
You can specify TRACEUTIL_DSP0TRACEMASK just as CE_TRACE and
CE_TRACEFILE are in the example.
Regards,
Scott
From: Andy Ngo [mailto:[EMAIL PROTECTED]
Sent: Friday, March 02, 2007 3:25 PM
To: Ring, Chris; Gary, Scott
Cc: davinci-linux-open-source @linux.davincidsp.com
Subject: Re: Cache coherency issue?
Thank you Chris After going through my ARM code
carefully, per your suggestion, I found out I had assigned
outBufs.bufSizes to 0!
I recently did a lot of cleaning up the code and renaming and
replacing constants to make stuff more readable; one of my replacements
had
forced outBufs.bufSizes to 0, duh! That's the reason I was
getting stale data and an explicit call to Memory_cacheWbInv was
required (or
apparently by just including a call to GT_trace). Thank you so
much for yours and Scott's help. Hopefully this was a lesson learned
that I share with others who may be having the same problem.
I have a newbie question about TraceUtil, I'm new to using it so
please forgive me. I have the following in my ARM configuration .cfg
file.
var TraceUtil =
xdc.useModule('ti.sdo.ce.utils.trace.TraceUtil');
TraceUtil.attrs = TraceUtil.DEFAULT_TRACING
This only turns on log warning (GT_6CLASS) and error
(GT_7CLASS) messages. How do I enable other level tracing (GT_CLASS 0
to 5)
on the fly. Scott mentioned about setting
TRACEUTIL_DSP0TRACEMASK=OM=012. Where is that set, the runtime
environment shell or
in some configuration file? Thanks.
Regards,
Andy
- Original Message
From: Ring, Chris [EMAIL PROTECTED]
To: Andy Ngo [EMAIL PROTECTED]; Gary, Scott
[EMAIL PROTECTED]; Adam Dawidziuk [EMAIL PROTECTED]
Cc: davinci-linux-open-source @linux.davincidsp.com
davinci-linux-open-source@linux.davincidsp.com
Sent: Friday, March 2, 2007 9:19:04 AM
Subject: RE: Cache coherency issue?
FWIW, I'm planning on distributing the sources to at least the
skeletons in future version of Codec Engine. You can then see the cache
operations in all their glory.
Not sure which version of CE you have, but here is a snippet of
the SPHENC skeleton (DSP-side). In red, I've highlighted the cacheWbInv
call(s) _right after_ it invokes the codec's process() call. This is
from Codec Engine 1.02:
/* invalidate cache for all input and output buffers
*/
for (i = 0; i inBufs.numBufs; i++) {
Memory_cacheInv(inBufs.bufs[i],
inBufs.bufSizes[i]);
}
for (i = 0; i outBufs.numBufs; i++) {
Memory_cacheInv(outBufs.bufs[i],
outBufs.bufSizes[i]);
}
/* unmarshall outArgs based on the size of inArgs
*/
pOutArgs = (ISPHENC_OutArgs
*)((UInt)((msg-cmd.process.inArgs)) +
msg-cmd.process.inArgs.size);
/* make the process call */
msg-visa.status = SPHENC_process(handle,
inBufs, outBufs,
(msg-cmd.process.inArgs), pOutArgs);
/* flush cache for all output buffers */
for (i = 0; i outBufs.numBufs; i++) {
Memory_cacheWbInv(outBufs.bufs[i],
outBufs.bufSizes[i]);
}
So, yes, the Codec Engine framework should be managing your
outBufs' cache for you.
Perhaps you can double-check that your outBufs.numBufs and
outBufs.bufSizes[] is correct? outBufs.bufSizes[] should be the size of
the _buffer_ not necessarily the size of the _contents_ of the buffer.
And the codec shouldn't be changing either of these values - they're
read-only from the codec's perspective.
It might be interesting to turn on trace as Scott describes
below - it should show exactly what cache operations are going on.
It'll be dumped into DSP-side memory, and can be 'scooped out' and
displayed by the ARM using either TraceUtils (preferred) or, if your app
isn't using TraceUtils, Engine_fwriteTrace().
Hope that helps.
Chris
attachment: Outlook.jpg
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
NAND Bad Blocks
Hello all, Recently we manufactured our own custom boards with NAND chips, and we'r noticing that during ftl_format of the chip, it doesn't skip over bad blocks in NAND - can someone verify is skipping bad blocks is already supported in the montavista kernel for davinci? I've looked at the nand driver, and there seems to be a file called nand_bbt.c, located in drivers/mtd/nand, and it seems to support this assumption; however, in nand_davinci.c, the this-options for the driver is set to 0 (I think you need to set it to NAND_USE_FLASH_BBT to enable the bad block table feature... Have tried using that feature, but it seems to act wonky..if there is a bad block in a partition, it labels the entire partition as being bad We need this feature for booting a filesystem + kernel from nand for a standalone system, and have a bunch of boards with nand problems on board Thank you, Jerry ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Sound volume
Does anyone know why the sound volume of the decode demo in dvevm1.10 is lower than it is in the decode demo in dvevm1.00 ? I have switched back and forth between the two versions of the dvevm to make sure this isn't due to any other factors. Bobby. _ Advertisement: Fresh jobs daily. Stop waiting for the newspaper. Search Now! www.seek.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau_t=757263760_r=Hotmail_EndText_Dec06_m=EXT ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Sound volume
Does anyone know why the sound volume of the decode demo in dvevm1.10 is lower than it is in the decode demo in dvevm1.00 ? I have switched back and forth between the two versions of the dvevm to make sure this isn't due to any other factors. Bobby. _ Advertisement: Fresh jobs daily. Stop waiting for the newspaper. Search Now! www.seek.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau_t=757263760_r=Hotmail_EndText_Dec06_m=EXT ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: reboot fail when using nandflash
Hi Roger, This situation is happened on standard evm and it works fine when using NOR boot. We use the kernel from dvevm 1.10 but elder u-boot. Currently, we manufacture our own board and use STM flash. So we face the same problem as Ivan faced. The flashwriter from TI can not work on our flash. Our hardware engineer is working on this issue now. Steve 2007/3/2, Monk, Roger [EMAIL PROTECTED]: Steve – some more questions to help us track this down :- Is this on standard evm or custom hardware? Which version of Uboot are you using? – Is it the latest from the ti extranet? Which version of linux kernel? – the one that comes with dvevm v1.10? Does reboot work successfully from NOR or is it also failing from NOR? Does reboot work successfully when using the MV filesystem, rather than your ramdisk? ~roger -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Steve Yeh *Sent:* 02 March 2007 10:41 *To:* davinci-linux-open-source@linux.davincidsp.com *Subject:* reboot fail when using nandflash Hi, Does anybody face the following problem? Any comment? Thanks a lot. Steve I storage kernel and ramdisk on nandflash and boot evm form it, but I can't reboot my system by submit shutdown –f –r now or halt -f both and system will show system is reboot now or Booting PSP Boot Loader and then no any response. As I know, Booting PSP Boot Loader was printed by boot loader, but I don't know why it's not go on. Any commands? P.S halt and shutdown were copy form evm hard disk (under /sbin) not soft link to busybox, any I copy all /etc form evm hard disk to my ramdisk. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
