Re: Root File system creation - Source required

[Philip Balister]

Tobias Knutsson wrote:

Hi,

I'm new to Ti's SoCs so I do not know if there is some way to re-use
that one. Otherwise I would suggest looking at buildroot,
OpenEmbedded, OpenWRT or some other build system that will generate a
root fs for you from a given configuration. The other option is to
build one from scratch (not that hard). In that case you should
probably look at busybox for all basic utilities. For ssh
functionality I would recomend dropbear (which depending on
configuration might require zlib). Then it all depends on how much
functionality you need i guess.


Support for TI SoC's in Openembedded is improving regularly. There are 
quite a few people working with OE and TI parts at the moment. You can 
even build codec engine with OE (although I've only done so for the 
Beagle Board)


Philip




On Mon, May 18, 2009 at 16:16, Venkatachala Upadhya
venkatachala_upad...@mindtree.com wrote:

Hello,

I am using DM6446 on a custom board. For this custom board, root file system 
would lie in SD/MMC card. I would like to create root file system for this. To 
take the advantages of TI distributed file system (as part of the DVEVM board 
plus packages, as it is verified), can I re-use it? If that is possible, how to 
get the sources, so that I can customize?

If this is not possible, can anyone suggest me the good starting point?

Thanks!

With best regards,

Venkatachala Upadhya| Extn: 65395|
--

http://www.mindtree.com/email/disclaimer.html

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source








smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: emdebian and Ubuntu?

[Philip Balister]

Yusuf Caglar AKYUZ wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrea Gasparini wrote:

Ben West spiffera, alle Wednesday 21 January 2009 circa:

However, the decision by Ubuntu maintainers above now means I must set
up parallel Debian system.
Has anyone else encountered this problem with Ubuntu and emdebian?

Uhm. I never tried, but can't you simply install the Debian package?
( I mean, downloaded from _debian_ repository, not ubuntu one )
Usually, with some little hacks, there's no need to have various 
Ubuntu/Debian systems running.
Anyway, I think you'll ear about me , as I'd like to give emdebian a try, 
and kick out MV filesystems.


Bye


Hi,

Recently openembedded folks published an online image builder at [1] for
various targets including davinci-dvevm. In case you're interested in a
new fs image...


If you use this this, please let us I know how it works for you. I can 
make sure any emails on this list get to the right people.


Thanks,

Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: UART1/2 on DM6467

[Philip Balister]

Stijn Devriendt wrote:

Apart from that I've been looking to fetch the git-tree from
source.mvista.com/git
this weekend, but found a dead URI instead.


I noticed this also. I switched the OpenEmbedded davinci recipe to use:

http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary

Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: FYI - TI patch plan

[Philip Balister]

Narnakaje, Snehaprabha wrote:

Hi,

Texas Instruments plans to improve and/or add support for TI's family of 
DaVinci SoCs.  This work is being done by a number of us here and I am 
coordinating the efforts. Beginning this month, TI will contribute patches to 
the DaVinci GIT tree, with the goal to update DM644x and add DM355 and DM6467 
support. Another goal is to get all driver features and bug fixes up-ported 
from earlier TI/MontaVista LSP releases for these devices. We plan to follow 
the approximate roadmap below:

September/October 2008: Patches for DM6467/DM355 baseport, DM9000 Ethernet (DM355), I2C (DM6467/DM355), GPIO (DM6467/DM355), EDMA (DM6467/DM355) and Video Capture (Using OMAP like I2C interface for the TVP decoders, contiguous buffer management) for DM644x. 


Next: Patches for NAND (DM6467, DM355 and DM644x), NOR on DM644x, Audio Driver 
support on DM6467 and DM355, SPI on DM6467 and DM355, Video capture on DM355, 
Support for Micron Sensors in the Video capture for DM644x and DM355, Video 
display framework using Encoder/Display manager and encoder modules for DM644x, 
fbdev display driver updates to use new Video display framework, fbdev display 
support for DM355 and V4L2 display driver for DM355 and DM644x.

Later: Patches for IPIPE on DM355, Previewer/Resizer on DM644x, H3A on DM644x 
and DM355, Video display/capture and VDCE driver support on DM6467, MMC/SD 
driver support on DM355 and USB support on DM6467 and DM355.

We want to benefit from the review and feedback from the DaVinci Linux 
community as we supply these patches, so the timeline for completing this 
process will depend on how extensive the community comments turn out to be.

I will share updates and status of this plan to the list on a monthly basis.


Is the ultimate goal to get these patches into the mainline kernel? That 
 would be really good. The linux-omap guys are making an effort to get 
all the omap patches upstream.


Philip




Thanks and regards
Sneha Narnakaje

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 1/1] Serial: DaVinci: Revert double IIR test

[Philip Balister]

Kevin Hilman wrote:

Mark Lokowich [EMAIL PROTECTED] writes:


Revert double IIR test in 8250 driver



Can you give a more detailed description of what the problem is that
is being fixed?


Without this patch, serial console behavior is strange. You type and 
nothing is echoed and you hit return and things happen. It feels like 
two processes are grabbing input.


I think someone posted a more technical description, but I couldn't find 
it quickly.


Philip



This is in the generic 8250 driver so will affect all platforms.  For
this to be accepted, it should be discussed on linux-serial[1]

Kevin


Acked-by: Jaswinder Singh [EMAIL PROTECTED]
---
--- linux-2.6/drivers/serial/8250.c
+++ linux-2.6-vanilla/drivers/serial/8250.c
@@ -1867,7 +1867,6 @@
}

if (is_real_interrupt(up-port.irq)) {
-   unsigned char iir1;
/*
 * Test for UARTs that do not reassert THRE when the
 * transmitter is idle and the interrupt has already
@@ -1881,7 +1880,7 @@
wait_for_xmitr(up, UART_LSR_THRE);
serial_out_sync(up, UART_IER, UART_IER_THRI);
udelay(1); /* allow THRE to set */
-   iir1 = serial_in(up, UART_IIR);
+   serial_in(up, UART_IIR);
serial_out(up, UART_IER, 0);
serial_out_sync(up, UART_IER, UART_IER_THRI);
udelay(1); /* allow a working UART time to re-assert THRE */
@@ -1894,7 +1893,7 @@
 * If the interrupt is not reasserted, setup a timer to
 * kick the UART on a regular basis.
 */
-   if (!(iir1  UART_IIR_NO_INT)  (iir  UART_IIR_NO_INT)) {
+   if (iir  UART_IIR_NO_INT) {
pr_debug(ttyS%d - using backup timer\n, port-line);
up-timer.function = serial8250_backup_timeout;
up-timer.data = (unsigned long)up;


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



[1] From MAINTAINERS:

8250/16?50 (AND CLONE UARTS) SERIAL DRIVER
L:  [EMAIL PROTECTED]
W:  http://serial.sourceforge.net
S:  Orphan
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: did you try openembedded?

[Philip Balister]

[EMAIL PROTECTED] wrote:
I'd like to try openembedded instead of the old montavista that came 
with my board.


My problem is that I cannot understand how I can integrate cmemk, 
dsplink and all the CE infrastructure with openembedded.


I'd like to hear if somebody has ever done it.


I have started to look at adding a recipe to OE for dsplink. Is the 
source for cmemk part of dsplink, if not, where can I get it?


Philip
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

U-boot, git kernel and file system images for Davinci EVM

[Philip Balister]

I've made a set of files for u-bbot, the kernel (built from git) and a 
root file system for the EVM for the Angstrom distribution (built by 
OpenEmbedded). They have booted on an EVM.


If you use root over NFS you will need to comment out the auto eth0 
line in /etc/network/interfaces.


http://amethyst.openembedded.net/~crofton/davinci-dvevm/

To install new packages you will need to do opkg update and opkg 
install package-name. Look in:


http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv5te/

for some package ideas.

Philip
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

NAND Flash usage

[Philip Balister]

I'm working with a Lyrtech SFF SDR board, I have Linux running on the 
board using root over NFS. I boot the kernel from NAND flash. I have 
created three partitions in the flash, but when I flash_eraseall I wipe 
the kernel out of NAND. After I flash_eraseall I can mount a jgffs2 
filesystem and create a filesystem as shown in:


http://linux.omap.com/pipermail/davinci-linux-open-source/2008-January/004858.html

Does anyone have any ideas? I've modified the evm board files to suit 
this board.


Philip


Here is the partition table in the board file:

struct mtd_partition davinci_evm_nandflash_partition[] = {
{
.name   = Bootloader,
.offset = 0,
.size   = 5 * SZ_128K,
.mask_flags = MTD_WRITEABLE,
},

{
.name   = Kernel,
.offset = MTDPART_OFS_APPEND,
.size   = SZ_2M,
.mask_flags = MTD_WRITEABLE,
},
{
.name   = File System,
.offset = MTDPART_OFS_APPEND,
.size   = MTDPART_SIZ_FULL,
.mask_flags = 0,
}
};


Here is cat /proc/mtd:

[EMAIL PROTECTED]:~# cat /proc/mtd
dev:size   erasesize  name
mtd0: 000a 0002 Bootloader
mtd1: 0020 0002 Kernel
mtd2: 07d6 0002 File System
[EMAIL PROTECTED]:~#

I set the mtd debug level higher, here are seemingly related messages:

DaVinci NAND Controller rev. 2.1
Warning: NAND config: Set A1CR reg to 0x0432018c, was 0x0432229c, should 
be done by bootloader.
NAND device: Manufacturer ID: 0x20, Chip ID: 0xf1 (ST Micro NAND 128MiB 
3,3V 8-bit)

Bad block scan: 0 out of 1024 blocks are bad.
Creating 3 MTD partitions on NAND 128MiB 3,3V 8-bit:
0x-0x000a : Bootloader
mtd: Giving out device 0 to Bootloader
0x000a-0x002a : Kernel
mtd: Giving out device 1 to Kernel
0x002a-0x0800 : File System
mtd: Giving out device 2 to File System
mice: PS/2 mouse device common for all mice


[EMAIL PROTECTED]:~# flash_eraseall -j /dev/mtd2
MTD_open
MTD_ioctl
MTD_ioctl
MTD_ioctl
MTD_ioctl
Erasing 128 Kibyte @ 0 --  0 % MTD_ioctl
complete.MTD_ioctl
MTD_ioctl
ErasiMTD_ioctlritten at 0.
ng 128 Kibyte @ MTD_ioctl
2 --  0 % coMTD_ioctl
mplete. Cleanmarker written at 2MTD_ioctl
Erasing 12MTD_ioctl
8 Kibyte @ 4MTD_ioctl
 --  0 % complete. Cleanmarker wMTD_ioctl
ritten at 4.MTD_ioctl
Erasing 128 KibMTD_ioctl
yte @ 6 --  0 % complete. ClMTD_ioctl
eanmarker writteMTD_ioctl
ErasMTD_ioctl
ing 128 Kibyte @ 8 --  0 % cMTD_ioctl
omplete. CleanmaMTD_ioctl
rker written at MTD_ioctl
Erasing 128 Kibyte @ a000MTD_ioctl
0 --  0 % compleMTD_ioctl
te. Cleanmarker MTD_ioctl
Erasing 128 KiMTD_ioctl
byte @ c -- MTD_ioctl
 0 % complete. CMTD_ioctl
EraMTD_ioctlritten at c.
sing 128 Kibyte MTD_ioctl
@ e --  0 % MTD_ioctl
complete. Cleanmarker written atMTD_ioctl
Erasing MTD_ioctl
128 Kibyte @ 100MTD_ioctl
000 --  0 % complete. CleanmarkeMTD_ioctl
r written at 100MTD_ioctl
Erasing 128MTD_ioctl
 Kibyte @ 12 --  0 % completMTD_ioctl
e. Cleanmarker wMTD_ioctl
ritten at 12MTD_ioctl
Erasing 128 Kibyte @ 14 --MTD_ioctl
  0 % complete. MTD_ioctl
Cleanmarker writMTD_ioctl
Erasing 128 KibytMTD_ioctl
e @ 16 --  1MTD_ioctl
 % complete. CleMTD_ioctl
ErasMTD_ioctlten at 16.
ing 128 Kibyte @MTD_ioctl
 18 --  1 % MTD_ioctl
complete. Cleanmarker written atMTD_ioctl
ErasingMTD_ioctl
 128 Kibyte @ 1aMTD_ioctl
 --  1 % complete. CleanmarkMTD_ioctl
er written at 1aMTD_ioctl
Erasing 12MTD_ioctl
8 Kibyte @ 1c --  1 % compleMTD_ioctl
te. Cleanmarker MTD_ioctl
written at 1c000MTD_ioctl
Erasing 128 Kibyte @ 1e -MTD_ioctl
-  1 % complete.MTD_ioctl
 Cleanmarker wriMTD_ioctl
Erasing 128 KibyMTD_ioctl
te @ 20 --  MTD_ioctl
1 % complete. ClMTD_ioctl
EraMTD_ioctlitten at 20.
sing 128 Kibyte MTD_ioctl
@ 22 --  1 %MTD_ioctl
 complete. Cleanmarker written aMTD_ioctl
ErasinMTD_ioctl
g 128 Kibyte @ 2MTD_ioctl
4 --  1 % complete. CleanmarMTD_ioctl
ker written at 2MTD_ioctl
Erasing 1MTD_ioctl
28 Kibyte @ 26 --  1 % complMTD_ioctl
ete. CleanmarkerMTD_ioctl
 written at 2600MTD_ioctl
Erasing 128 Kibyte @ 28 MTD_ioctl
--  1 % completeMTD_ioctl
. Cleanmarker wrMTD_ioctl
Erasing 128 KibMTD_ioctl
yte @ 2a -- MTD_ioctl
 2 % complete. CMTD_ioctl
ErMTD_ioctlwritten at 2a.
asing 128 KibyteMTD_ioctl
 @ 2c --  2 MTD_ioctl
% complete. Cleanmarker written MTD_ioctl
ErasiMTD_ioctl
ng 128 Kibyte @ MTD_ioctl
2e --  2 % complete. CleanmaMTD_ioctl
rker written at MTD_ioctl
Erasing MTD_ioctl
128 Kibyte @ 30 --  2 % compMTD_ioctl
lete. CleanmarkeMTD_ioctl
r written at 300MTD_ioctl
Erasing 128 Kibyte @ 32MTD_ioctl
 --  2 % completMTD_ioctl
e. Cleanmarker wMTD_ioctl
Erasing 128 KiMTD_ioctl
byte @ 34 --MTD_ioctl
  2 % complete. MTD_ioctl
Cleanmarker writMTD_ioctl
MTD_ioctl
MTD_ioctl
MTD_ioctl
MTD_ioctl

[Fwd: NAND Flash usage]

[Philip Balister]

One clarification:

When I create a jffs2 filesystem on /dev/mtd2 using the process 
described in:


http://linux.omap.com/pipermail/davinci-linux-open-source/2008-January/004858.html

The kernel in /dev/mtd1 is no longer bootable. U-boot does not recognize 
the kernel as valid anymore.


Philip


 Original Message 
Subject: NAND Flash usage
Date: Mon, 21 Apr 2008 14:32:44 -0400
From: Philip Balister [EMAIL PROTECTED]
To: davinci-linux-open-source@linux.davincidsp.com 
davinci-linux-open-source@linux.davincidsp.com


I'm working with a Lyrtech SFF SDR board, I have Linux running on the
board using root over NFS. I boot the kernel from NAND flash. I have
created three partitions in the flash, but when I flash_eraseall I wipe
the kernel out of NAND. After I flash_eraseall I can mount a jgffs2
filesystem and create a filesystem as shown in:

http://linux.omap.com/pipermail/davinci-linux-open-source/2008-January/004858.html

Does anyone have any ideas? I've modified the evm board files to suit
this board.

Philip


Here is the partition table in the board file:

struct mtd_partition davinci_evm_nandflash_partition[] = {
 {
 .name   = Bootloader,
 .offset = 0,
 .size   = 5 * SZ_128K,
 .mask_flags = MTD_WRITEABLE,
 },

 {
 .name   = Kernel,
 .offset = MTDPART_OFS_APPEND,
 .size   = SZ_2M,
 .mask_flags = MTD_WRITEABLE,
 },
 {
 .name   = File System,
 .offset = MTDPART_OFS_APPEND,
 .size   = MTDPART_SIZ_FULL,
 .mask_flags = 0,
 }
};


Here is cat /proc/mtd:

[EMAIL PROTECTED]:~# cat /proc/mtd
dev:size   erasesize  name
mtd0: 000a 0002 Bootloader
mtd1: 0020 0002 Kernel
mtd2: 07d6 0002 File System
[EMAIL PROTECTED]:~#

I set the mtd debug level higher, here are seemingly related messages:

DaVinci NAND Controller rev. 2.1
Warning: NAND config: Set A1CR reg to 0x0432018c, was 0x0432229c, should
be done by bootloader.
NAND device: Manufacturer ID: 0x20, Chip ID: 0xf1 (ST Micro NAND 128MiB
3,3V 8-bit)
Bad block scan: 0 out of 1024 blocks are bad.
Creating 3 MTD partitions on NAND 128MiB 3,3V 8-bit:
0x-0x000a : Bootloader
mtd: Giving out device 0 to Bootloader
0x000a-0x002a : Kernel
mtd: Giving out device 1 to Kernel
0x002a-0x0800 : File System
mtd: Giving out device 2 to File System
mice: PS/2 mouse device common for all mice


[EMAIL PROTECTED]:~# flash_eraseall -j /dev/mtd2
MTD_open
MTD_ioctl
MTD_ioctl
MTD_ioctl
MTD_ioctl
Erasing 128 Kibyte @ 0 --  0 % MTD_ioctl
complete.MTD_ioctl
MTD_ioctl
ErasiMTD_ioctlritten at 0.
ng 128 Kibyte @ MTD_ioctl
2 --  0 % coMTD_ioctl
mplete. Cleanmarker written at 2MTD_ioctl
Erasing 12MTD_ioctl
8 Kibyte @ 4MTD_ioctl
  --  0 % complete. Cleanmarker wMTD_ioctl
ritten at 4.MTD_ioctl
Erasing 128 KibMTD_ioctl
yte @ 6 --  0 % complete. ClMTD_ioctl
eanmarker writteMTD_ioctl
ErasMTD_ioctl
ing 128 Kibyte @ 8 --  0 % cMTD_ioctl
omplete. CleanmaMTD_ioctl
rker written at MTD_ioctl
Erasing 128 Kibyte @ a000MTD_ioctl
0 --  0 % compleMTD_ioctl
te. Cleanmarker MTD_ioctl
Erasing 128 KiMTD_ioctl
byte @ c -- MTD_ioctl
  0 % complete. CMTD_ioctl
EraMTD_ioctlritten at c.
sing 128 Kibyte MTD_ioctl
@ e --  0 % MTD_ioctl
complete. Cleanmarker written atMTD_ioctl
Erasing MTD_ioctl
128 Kibyte @ 100MTD_ioctl
000 --  0 % complete. CleanmarkeMTD_ioctl
r written at 100MTD_ioctl
Erasing 128MTD_ioctl
  Kibyte @ 12 --  0 % completMTD_ioctl
e. Cleanmarker wMTD_ioctl
ritten at 12MTD_ioctl
Erasing 128 Kibyte @ 14 --MTD_ioctl
   0 % complete. MTD_ioctl
Cleanmarker writMTD_ioctl
Erasing 128 KibytMTD_ioctl
e @ 16 --  1MTD_ioctl
  % complete. CleMTD_ioctl
ErasMTD_ioctlten at 16.
ing 128 Kibyte @MTD_ioctl
  18 --  1 % MTD_ioctl
complete. Cleanmarker written atMTD_ioctl
ErasingMTD_ioctl
  128 Kibyte @ 1aMTD_ioctl
 --  1 % complete. CleanmarkMTD_ioctl
er written at 1aMTD_ioctl
Erasing 12MTD_ioctl
8 Kibyte @ 1c --  1 % compleMTD_ioctl
te. Cleanmarker MTD_ioctl
written at 1c000MTD_ioctl
Erasing 128 Kibyte @ 1e -MTD_ioctl
-  1 % complete.MTD_ioctl
  Cleanmarker wriMTD_ioctl
Erasing 128 KibyMTD_ioctl
te @ 20 --  MTD_ioctl
1 % complete. ClMTD_ioctl
EraMTD_ioctlitten at 20.
sing 128 Kibyte MTD_ioctl
@ 22 --  1 %MTD_ioctl
  complete. Cleanmarker written aMTD_ioctl
ErasinMTD_ioctl
g 128 Kibyte @ 2MTD_ioctl
4 --  1 % complete. CleanmarMTD_ioctl
ker written at 2MTD_ioctl
Erasing 1MTD_ioctl
28 Kibyte @ 26 --  1 % complMTD_ioctl
ete. CleanmarkerMTD_ioctl
  written at 2600MTD_ioctl
Erasing 128 Kibyte @ 28 MTD_ioctl
--  1 % completeMTD_ioctl
. Cleanmarker wrMTD_ioctl
Erasing 128 KibMTD_ioctl
yte @ 2a -- MTD_ioctl
  2 % complete. CMTD_ioctl
ErMTD_ioctlwritten

Git intro

[Philip Balister]

I have done some work for the Lyrtech Small Factor SDR board that I 
would like to submit to this list. Does anyone have a good git intro to 
take me through the process? I have it in a git repo in a branch I made 
several months ago from the linux-davinci repo.


So I need to update to match the current repo and work out what the 
patch is.


Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Buildroot on 6446EVM

[Philip Balister]

I've used OpenEmbedded to build images for the EVM before. I built glibc 
images, but it should be possible to create uclibc images also. 
Unfortunately, I do not have an EVM to test against so I do not keep a 
set of current images available for download.


Philip

Brian Niebuhr wrote:
Has anyone got buildroot to work on the 6446EVM?  


I am currently running the 2.6.23-davinci1 git kernel with a
Montavista-generated cramfs root filesystem and that is working fine.
However, adding just a couple of packages to create a minimal filesystem
makes the filesystem huge.  So I wanted to try buildroot to generate a
uClibc-based toolchain and filesystem.  I was able to get buildroot to
create a cramfs root filesystem and I used it to replace my Montavista
filesystem. However when the kernel gets to the point where it should
run init, it just apparently hangs (no output whatsoever).  I've tried
various init= kernel parameters, including just init=/bin/sh, and I
always get the same results.  It's as if busybox can't start running.

I assume that I just messed something up in the buildroot configuration,
but I'm not sure what.  If anyone has this working, could I get a copy
of your buildroot .config and/or any tips on how to make it work?

Thanks!

Brian


_
Brian Niebuhr
Senior Design Engineer
E.F. Johnson

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

NAND support in git kernel

[Philip Balister]

I've been beating my head against a wall trying to figure out how to 
support NAND flash with the git kernel. My current thought is that I 
need to take the NAND driver from the MV kernel and get it working with 
git. Is this the correct approach? Or is there a better approach?


Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Creating a new board from the existing evm board

[Philip Balister]

I am also working with the current git kernel. I have seen references to 
a davinci specific file in drivers/mtd/nand in the list archives, but 
this file does not exist in current git.


Philip

Philip Balister wrote:
I am working with the Lyrtech small form factor SDR board. Thanks to 
Sergey's u-boot work, I have this board booting Linux and mounting a 
filesystem via NFS.


The board if fairly close to the EVM, but has NAND flash only.

I believe I need to do the following to add support for this board:

1) Change the machine number to something else.

2) Copy board-evm.c to board-sff.c.

3) Add config option to the Kconfig file for the new board.

4) Update the Makefile for the new board.

5) Figure out how to add NAND flash partition info into board-evm.c.

Does this sound reasonable? I'm not sure how to add the NAND flash 
partition info to the board-sff.c file. Any suggestions for examples to 
look at?


Thanks,

Philip




___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: DVFlasher/TI UBL replacement, how to go on?

[Philip Balister]

I took a quick look at the three options and also conclude the best 
starting point is Sergey's tool. It is already in C and the code is GPL, 
so it should make the best starting point for future work.


Philip

Dirk Behme wrote:


Now, we have three different candiates for DVFlasher/TI UBL replacement:

1.  rboot  load.c based

http://linux.omap.com/pipermail/davinci-linux-open-source/2007-August/003916.html 



2. BOOTME  BOOTMMS  mmsuartloader  mmsnandloader

http://linux.omap.com/pipermail/davinci-linux-open-source/2007-August/003925.html 



3. Sergeys tool

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/31457

See [1] as well.

I think we should agree on one to go on with, maybe merging features 
from the other. Target should be to have one open source DVFlasher/TI 
UBL replacement. I haven't looked yet into (2) and (3), but I think (1) 
is only really basic, so better candidates to go on with are (2) or (3). 
I personally like a C/assembly based solution more than one with C# ;)


I asked Kevin regarding a git repository for this. It should be possible 
to host it on [2] if we like.


Opinions?

Best regards

Dirk

[1] http://wiki.davincidsp.com/index.php?title=RBL_UBL_and_host_program

[2] http://source.mvista.com/git/
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: git tree updated to 2.6.23-rc2 [resend]

[Philip Balister]

u-boot is in the u-boot git repository.

http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary

There are not any tarball releases containing the davinci code yet.

Philip

Steve Spano wrote:

Where can this latest be downloaded to get the latest UBOOT and Kernels?

Thanks 


Steve Spano
FLE

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Dirk Behme
Sent: Friday, August 17, 2007 10:19 AM
To: Kevin Hilman
Cc: davinci-linux-open-source
Subject: Re: git tree updated to 2.6.23-rc2 [resend]

Kevin Hilman wrote:

The DaVinci git tree[1] has now been updated to 2.6.23-rc2, and tagged
as v2.6.23-rc2-davinci1.


Many thanks for this!

Now we have a recent kernel and recent UBoot containing DaVinci main 
tree! :)


Best regards

Dirk
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: HR timers

[Philip Balister]

Dirk Behme wrote:

So, that code
has diverged from the DaVinci git in lots of ways to be cleanly
re-organized, reformatted etc. for mainline acceptance.  The result, the
merge will take some time.


What's about this merge plan:

1) Take a local branch of recent DaVinci git
2) Take a local branch of recent Tonys OMAP git. Should contain mainline 
DaVinci stuff (?)

3) (Manually) merge (2) on top to (1)
3a) With merge conflicts in DaVinci only files, take the files from 
Tony/mainline. Discard version in DaVinci git.
3b) With merge conflicts in non-DaVinci files, resolve them manually as 
appropriate

4) Resolve compile and runtime errors introduced by (3)
5) Create a patch of the changes between (1) and (after 4) and send to 
list for review


Has anyone thought about what it would take to move the davinci specific 
bits into the OMAP tree?


Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[Fwd: [U-Boot-Users] Starting a patch for TI Davinci support]

[Philip Balister]

I posted this on the u-boot list, and then I realized this list is also 
a good place to collect comments.


Philip

 Original Message 
Subject: [U-Boot-Users] Starting a patch for TI Davinci support
Date: Thu, 21 Jun 2007 10:23:25 -0400
From: Philip Balister [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

I am trying to get a patch together to add support for the TI Davinci
processor into u-boot. I have started with one of the patches floating
around the internet and am in the process of modifying to support the
Lyrtech SFF SDR board. Currently, this patch will boot on the board and
use the network and do some ram tests. I haven't worked through NAND
support yet.

The patch is against git. I am very interested in structural comments,
like the best way to support similar, but different boards.

I would be glad to collect additional patches and see if we can't get
support for davinci boards into u-boot.

The current patch is here:

http://www.balister.org/~balister/u-boot-sffsdr.patch

Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [Fwd: [U-Boot-Users] Starting a patch for TI Davinci support]

[Philip Balister]

Ivan Tonchev wrote:

The patch is against git. I am very interested in structural comments,
like the best way to support similar, but different boards.

My patch is against u-boot 1.2. I'm also interested to have DaVinci 
support integrated in the u-boot mainline. Have you already spoken with 
TI people about this?


I've seen TI guys post to the list, but haven't spoke directly to them.


I would be glad to collect additional patches and see if we can't get
support for davinci boards into u-boot.

I can't release everything to the public as I use TI-proprietary code. 
Probably if TI people give their blessing to the mainline idea...


I'm going to be on vacation until July 4. I'm going to take a break from 
this until I get back. I've got a project that badly needs Linux running 
on the Lyrtech board last month, so I will be pretty desperate when I 
get back.


I'm trying to avoid adding yet another set of patches for u-boot and 
davinci to the mix by collecting what I find in one place.


Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Still testing

[Philip Balister]

Ping
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

DDR controller timing

[Philip Balister]

When I set up the controller (in DVFlasher) with these numbers, attempts 
to flash lead to flash/RAM verification failures. I really think I am 
doing the math OK, but I could be missing something (like an off by two)


I think I set the SYSCLOCK to 324 MHz, which should clock the DDR 
interface at 162 Mhz and calculated the timing accordingly.


The numbers here work mostly, unless you memory test large sections of 
RAM with u-boot: 
http://trac.geekisp.com/opensdr/browser/HW_tools/sff_sdr/serial_loader/trunk/DVFlasher/ubl/src/dm644x.c#L29


Updating to these numbers leads to the problem described above.

// For Micron MT47H32M16BN-3 @ 324 MHz
const Uint8 DDR_NM = 0;
const Uint8 DDR_CL = 3;
const Uint8 DDR_IBANK = 2;
const Uint8 DDR_PAGESIZE = 2;
const Uint8 DDR_T_RFC = 17;
const Uint8 DDR_T_RP = 2;
const Uint8 DDR_T_RCD = 2;
const Uint8 DDR_T_WR = 2;
const Uint8 DDR_T_RAS = 6;
const Uint8 DDR_T_RC = 8;
const Uint8 DDR_T_RRD = 1;
const Uint8 DDR_T_WTR = 1;
const Uint8 DDR_T_XSNR = 18;
const Uint8 DDR_T_XSRD = 199;
const Uint8 DDR_T_RTP = 1;
const Uint8 DDR_T_CKE = 2;
const Uint16 DDR_RR = 1263;
const Uint8 DDR_Board_Delay = 3;
const Uint8 DDR_READ_Latency = 5;

const Uint32 PLL2_Mult = 24;
const Uint32 PLL2_Div1 = 12;
const Uint32 PLL2_Div2 = 1;

// Set CPU clocks
const Uint32 PLL1_Mult = 22;  // DSP=594 MHz ARM=297 MHz

Can anyone see what I am doing wrong?

Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

DDR controller setup

[Philip Balister]

I'm trying this again as I had a report the first try was garbled.

When I set up the controller (in DVFlasher) with these numbers, attempts 
to flash lead to flash/RAM verification failures. I really think I am 
doing the math OK, but I could be missing something (like an off by two)


I think I set the SYSCLOCK to 324 MHz, which should clock the DDR 
interface at 162 Mhz and calculated the timing accordingly.


The numbers here work mostly, unless you memory test large sections of 
RAM with u-boot: 
http://trac.geekisp.com/opensdr/browser/HW_tools/sff_sdr/serial_loader/trunk/DVFlasher/ubl/src/dm644x.c#L29


Updating to these numbers leads to the problem described above.

// For Micron MT47H32M16BN-3 @ 324 MHz
const Uint8 DDR_NM = 0;
const Uint8 DDR_CL = 3;
const Uint8 DDR_IBANK = 2;
const Uint8 DDR_PAGESIZE = 2;
const Uint8 DDR_T_RFC = 17;
const Uint8 DDR_T_RP = 2;
const Uint8 DDR_T_RCD = 2;
const Uint8 DDR_T_WR = 2;
const Uint8 DDR_T_RAS = 6;
const Uint8 DDR_T_RC = 8;
const Uint8 DDR_T_RRD = 1;
const Uint8 DDR_T_WTR = 1;
const Uint8 DDR_T_XSNR = 18;
const Uint8 DDR_T_XSRD = 199;
const Uint8 DDR_T_RTP = 1;
const Uint8 DDR_T_CKE = 2;
const Uint16 DDR_RR = 1263;
const Uint8 DDR_Board_Delay = 3;
const Uint8 DDR_READ_Latency = 5;

const Uint32 PLL2_Mult = 24;
const Uint32 PLL2_Div1 = 12;
const Uint32 PLL2_Div2 = 1;

// Set CPU clocks
const Uint32 PLL1_Mult = 22;  // DSP=594 MHz ARM=297 MHz

Can anyone see what I am doing wrong?

Philip


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Bringing u-boot up on a new board

[Philip Balister]

I have a SFF SDR Board from Lyrtech. I have loaded some code over serial 
and tested the DDR RAM successfully. I'd like to start working on 
getting u-boot running on the board.


Where is the best place to get u-boot for davinci from (for starting a 
new board)?


Thanks,

Philip
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: DV Flasher

[Philip Balister]

Ivan Tonchev wrote:

1. Try running this in text console (CTRL + ALT + F1), not in xterm. For
some unknown to me reason, xterm doesn't like mono console output.


Removing the .Clear command solved this problem also.


2. Download latest DVFlasher code from my.ti.com (latest downloadable
version is 1.12)


The only zip file I can find is the one from the pdf. How do I find the 
later version?



4. Are you trying to flash something on an EVM or you're testing with a
custom board? In case of the latter, read this thread:
http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg02411.html


I've been following this thread. I'm waiting on some information about 
the parts used for memory. The board is the Lyrtech small form factor 
SDR board. http://tinyurl.com/2mkg9n


Currently, I am going to try getting the uartapp from spraai0 going 
first, then moving into using the flash.


Thanks!

Philip



smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: DV Flasher

[Philip Balister]

Andrew Armstrong wrote:

Philip,

If you read the readme file included with DV flasher it describes using 
mono under a linux machine to enable you to execute it.


Moving past my skipping the readme and reading the source 

OK, I have built the DVFlasher and am attempting to run it using mono.

Executing:

mono DVFlasher_1_10.exe

causes the xterm to blink and the prompt to return with no visible 
messages remaining. I think it is trying to display a message, but the 
screen is erased before I can see the message.


Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

DV Flasher

[Philip Balister]

Does anyone know if there is a Linux DV Flasher program? I'm reading 
SPRAAI0 and 4 at the moment and it would be handy avoid needing a 
windows machine.


Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Lyrtech DV board

[Philip Balister]

I have access to this board:

http://www.lyrtech.com/DSP-development/dsp_fpga/sffsdrevaluationmodule.php

Unfortunately, Lyrtech only provides Integrity on the ARM. I would like 
to get Linux running on this board. I am guessing, I need to start by 
getting u-boot running. It looks like the board only has NAND flash.


Does anyone have any suggestions how to get started and/or words of 
encouragement?


Thanks,

Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Small footprint filesystem

[Philip Balister]

Take a look at OpenEmbedded. (http://www.openembedded.org) I use it to 
make custom images for the OSK board. If I can get a Davinci board and 
some time, I plan on adding support for Davinci based systems.


Philip

Andy Ngo wrote:

Hi,

The DVEVM board comes with a HUGE filesystem on the 2.5” hard drive.  On boot 
up, the Linux kernel mounts the partition
(/dev/hda1) to be used as the root filesystem.  The filesystem is 1.9GB!  This 
is good for development purposes but when we have
our custom board, we will only have a small flash memory to store the 
filesystem.  Do anyone have instructions on how to create
small footprint filesystem (16Mb)?  I was planning to do a top-down approach 
of eliminating all the files/directories
(/opt/mv_pro_4.0/montavista/pro/devkit/arm/v5t_le/target) I don’t need until I 
get it to a manageable filesystem but I’m not sure
what are needed and what aren’t. Has anyone done this and have a recommendation?

 Also, the current “top” (procps) utility on the board is version 3.2.5; it doesn’t support displaying individual threads of a process; 
it only shows info about a process as a whole but not the thread.  Version 3.2.6 has that capability; does anyone know how we

can get that version?

Thank!

Regards,
Andy




___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Best way to get data from a fpga?

[Philip Balister]

How about McBSP ports? (I'm not sure if this is realistic, but I am also 
interested in the answer)


Philip

Carlos Ojea wrote:

It is based on your data rate, maybe SPI is a good choice?

Maybe, I don't know if it will be enough bandwith. In case we need a
higher data rate, what would be your suggestion?

Many Thanks,
Carlos
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source