PCB fabrication costs for OMAP3530 designs

Leandro_Gentili · December 5, 2008, 5:14pm

Everybody pays the cost for what a subset of people want, even if it
is probably the majority. What are people willing to pay for this
change?

We know that "one size does not fit all", that's why the idea is a new
board (using the beagleboard.org philosophy) for the average embedded
developer, and keep improving the actual board too (like Rev C.) not
to replace it.

Each of the board changes cost us roughly $20,000, plus there
are the per-board cost increases. I believe we need to keep the price
down and continue to drive the volume up.

With the CUS package cost shouldn't be so high.

IMHO, beagleboard.org (and TI) has everything to make history, why?
This is the first time that a hobbist have ALL this at same time:
-Access to the lastest MOBILE Processor technology in low quantities,
is important to remark that the core is ARM that has the BIGGEST
ecosystem tools (if the core were PPC or MIPS is not the same).
-Perfect TIMING for the Open Source maturity (crosscompilers, OE,
Java, Mono, etc).
-Enough MIPS for big things (and fanless!).
-Low Prices!! (Flash and ram memory cost nothing now).
But... the Cons: that is hard to build.... we have to work in this
part....

Microchip became a monster 10 years ago using the same formula, give
cheap access to developers with the PIC family. At that moment,
Motorla was selling tools for the HC08 around $1.2K.

The question is if beagleboard.org is interested or give the room to
other people/company do it.

Gerald_Coley1 · December 5, 2008, 5:30pm

Let’s see what the interest level is. A few weeks back we floated the idea of adding more memory to the board and there was resistance to anything that increased the cost of the board which is what you are proposing here.

Any cost savings from going to the .65mm package will be taken up by the added features. While a 4 layer board is possible for getting all of the signals out in this .65mm package, I have my doubts that it is possible when you consider the routing challenges of the SDRAM signals with just two routing layers. That is a lot of signals to get into the memory packages while maintianing the right impedances and shielding.

When you factor in the fact that we would need to build a large quantity, as we currently do, to help keep the cost down, it would indeed need to compete with the current Beagle to become viable. I agree that a design like this would help those that want to build their own product based on this design, but past that it is unclear to me as to the overall benefit. I am definitely not saying that it should not be done, but I believe we need to set the right expectations.

So how would this effort be funded to get boards built and assembled?

Gerald

John_Beetem · December 5, 2008, 6:51pm

I rather like the mini-AB connector, which keeps BeagleBoard small.
What would be nice is a little 2-pin jumper to ground OTG pin 4 so you
can use a readily-available mini-B cable.

Gerald_Coley1 · December 5, 2008, 7:22pm

Well, actually the rev C will have a shorting pad on it to drop some solder on it and get the pin grounded. We didn’t have room for afull size jumper. With USB host on Rev C, the need to use the OTG port in the host mode should start to lessen.

Gerald

John_USP · December 5, 2008, 7:52pm

Good discussion so far about a next design that would work for most developers.

I think BeagleBoard is brilliant and kudos to the guys that developed it. I just think we need to look at the total cost to use BeagleBoard, and that includes USB hubs, special cables, LCD display, USB keyboard & mouse, etc. You could easily spend $500 before you are done. Then you have to think about an enclosure you can use to demonstrate your final solution.

Here is what I would like to see as a next step:

Battery backed up real-time clock
Battery gauge/monitor/charger for portable applications
LCD/Touchscreen ZIF connector for direct connection to a low cost display like that used on a PSP1000. The 20 Pin connector used on the RevC board is difficult to use and requires some type of adaptor board. Connectors cost money.
10/100/1000 Ethernet, possibly dual Ethernet
I don’t have a need for this, but I think there is a legitimate need to include support for a camera sensor
ETM support
Connectors should only be placed on two sides of the board, not all four sides.

Now the question is, how do we support all of this without adversely affecting the cost of the BeagleBoard? Here are a few ideas:

Make provisions on the PCB for connectors that will enable the above features, but don’t install the connectors. Let users solder the connectors onto the board when they need them. The concern would be that there is no space for the connectors on the board. Actually, there is plenty of space on the other side of the BeagleBoard, so using low profile board-board connectors would solve this problem.
Create a variety of piggy-back boards to support most of the above features. Most of these boards would be fairly simple and should not be expensive to manufacture.

Just some ideas that I hope might help.

Regards,

Leandro_Gentili · December 5, 2008, 8:24pm

Let's see what the interest level is. A few weeks back we floated the idea
of adding more memory to the board and there was resistance to anything that
increased the cost of the board which is what you are proposing here.

Is impossible to make everybody happy. That's why is necessary a
couple of variants. It's like ask which color do you want the
beagleboard?

Any cost savings from going to the .65mm package will be taken up by the
added features. While a 4 layer board is possible for getting all of the
signals out in this .65mm package, I have my doubts that it is possible when
you consider the routing challenges of the SDRAM signals with just two
routing layers. That is a lot of signals to get into the memory packages
while maintianing the right impedances and shielding.

Harder with less layers? Sure, the question is possible or not? You
are the boss in this field, I didn't try to route it, but my
speculation is that should be possible (at least 2 memory chips) if
not why TI would do all the noise with the "Via Channel Technology".

When you factor in the fact that we would need to build a large quantity, as
we currently do, to help keep the cost down,
it would indeed need to compete
with the current Beagle to become viable.

The worst picture is if another company sell that new board and you
are not getting the benefit of decrese prices in the component parts
that are common in both designs (like the OMAP35xx, PSU, Memory, etc).
Is the same case in which some people is buying other boards because
the BB has no LCD port.

would help those that want to build their own product based on this design,
but past that it is unclear to me as to the overall benefit. I am definitely
not saying that it should not be done, but I believe we need to set the
right expectations.

So how would this effort be funded to get boards built and assembled?

The excelent momentum that BB has, will not last much, competition/
clones will apear, the only way is keep feeding the innovation and go
1 step further.

Gerald_Coley1 · December 5, 2008, 8:53pm

I agree you cannot make everyone happy. I have done over 20 OMAP EVM designs over the years, so I have a lot of experience in that area.

While not my idea, I was involved with the creation of the via channel array technology. The goal was to get all the signals out on two routing layers, which it has certainly done. I am not saying that it won’t work, but please keep in mind that the layers are not the only factor in cost. If taking it to four layers requires micro vias, then you loose some of the cost benefit of the 4 layers. There has been a plan inside TI to try and do the 4 layer board, but it has not to date been done.

The Rev C Beagle will indeed have an LCD interface. It will require an adapter to make it work with all of the different displays, whether they are 3V, 3.3V, 5V RGB TTL, LVS, or some other interface. It was not pratical to add all of those interfaces. As you have said, you can’t make everyone happy. However, the Rev C will come pretty close. As designed, I can’t think of a LCD panel that it could not be interfaced to. The only added cost would be the simple adapter to allow it to interface to a specific LCD or series of LCD displays.

I have a schematic done for the .65mm design. The decision was to set it aside and get the Rev C out for many reasons, some of which are issues internal to TI involving schedules. The BeagleBoard was designed and released prior to the full parts being release to production. We wanted to get out there as quickly as we could.

Gerald

Gerald_Coley1 · December 5, 2008, 9:02pm

So, here is the key factor in this. What is the price target that BeagleXXX must meet to get the same acceptance in the market as it has to date? What would the total BOM look like, cables, power supplies, etc.? Can we build them in quantities of 1K, 5k, or 10K, and can we sell them all in 6 months?

If we can answer this, there is no issue in filling up the BOM to take advantage of the new found cost budget to add a lot of features and accesories. Nothing that has been mentioned to date is something that we don’t already have on the TI EVM, you know, the $1500 unit, except for a fancy case. Although, there is one like that called the Zoom MDK that sells for around $800 that does have a case.

Gerald

John_USP · December 5, 2008, 10:11pm

Hi Gerald,

I think you lost me here,

Almost everything I proposed should not add any cost to the BeagleBoard. Placing pads on the PCB so that we can solder a connector will not affect the price at all. It just makes more of the OMAP signals available to that we can add daughter boards with the functionality we need/want.

Other items such as bringing out the battery line from the TWL4020, should have been done anyway.

I don’t want to see the price increase. On the contrary, with increasing flexibility, the applications for BeagleBoard should increase, which will increase volume and hopefully help reduce costs.

Regards,

Gerald_Coley1 · December 6, 2008, 1:04am

There has been talk of of Ethernet being added, ETM, and LVDS, moving to the CUS package, increased board dimensions,etc. It light of the entire conversation on this thread, I stand by my comment. If you want to add pads, then no, that won’t add component cost. It depends, as I have said, as to what you add. However, if you knew how tight the REV C card was as a result of adding the LCD connector and moving the USB from Port 1 to Port 2, the need for two more layers is definitely a possibility with even the most simple changes. So adding a few pads may push us to add the layers thereby pegging the cost meter.

Also, please wait for the Rev C to come out. I think you will find that some of your concerns will be addressed.

Gerald

jkridner · December 6, 2008, 5:39am

I welcome the clones and just hope that they help bring better
solutions. I hope and expect the clones to do more business than the
original. It would be good for us to figure out how to be open to
those here on this list.

Still, as there are opportunities to improve without adding cost, I
think we should take them. My feeling is that the Beagle Board should
remain the bare minimum and enable as much of the design as possible
to be "dropped in" to other designs. Beagle's goal should be to make
it affordable for as many people as possible to get a useful OMAP3530
board. It should also be a reference for people to use in their own
designs.

If we were really to make 10,000 or 100,000 at a time, the costs would
really go down quite significantly, so I'm hopeful that that means
people are aware there is plenty of opportunity to turn this into a
viable complete end-consumer product, which is not something we want
to do with Beagle. As it is, 1,000 at a time the quantity we seek for
the current price point, but we do still need to buy some of the
components in higher quantities.

If we did have a really good 0.65mm design that was public, the
quantity required to get to our target price could come down quite a
bit. That would make it where others could use it as a starting point
for making their own custom designs, for perhaps even fewer than 1,000
boards. Some concrete proposals that don't increase the BOM would
really be welcome.

John_USP · December 6, 2008, 6:22am

Is anyone using the OMAP3530 EVM board. I can get the board to work with the
2.6.22 kernel and u-boot 1.1.4, but now I want to update u-boot to 2008.10
and the 2.6.27 kernel, but I get the following error:

Wrong Image Format for bootm command
ERROR: can't get kernel image!

I updated bootargs and bootcmd similar to what I used to boot BeagleBoard
with the same release of u-boot and kernel, but I get an error when I set
bootcmd:

** Unable to use mmc 0:1 for fatload **
Wrong Image Format for bootm command
ERROR: can't get kernel image!

I built the kernel and u-boot using omap3evm config.

Regards,

jkridner · December 7, 2008, 1:40pm

This would probably be found sooner if it was started on a new
thread...

John_USP · December 8, 2008, 10:47pm

Hi Jason,

When I received the loaner board from TI this was the environment:

OMAP3_EVM # printenv

bootargs=setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/mtdblock4
rw2
bootcmd=onenand read 80200000 280000 400000 ; bootm 80200000

bootdelay=10

baudrate=115200

netmask=255.255.254.0

bootfile="uImage"

stdin=serial

stdout=serial

stderr=serial

Somehow this seemed to work for the cube demo that comes with this board.
This was using 2.6.22 kernel and 1.1.4 u-boot.

I tried to set bootcmd and bootargs to something similar to what I used on
my BeagleBoard, using the following commands:

setenv bootargs console=ttyS0,115200n8 root=/dev/mmcblk0p2 rootdelay=2
rootfstype=ext3 ro video=omapfb:vram:2M,vram:4M8
setenv bootcmd mmcinit; fatload mmc 0:1 0x80200000 uImage; bootm 0x80200000

However, when I try to set the bootcmd, it says:

** Unable to use mmc 0:1 for fatload **
Wrong Image Format for bootm command
ERROR: can't get kernel image!

Regards,

From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Jason Kridner
Sent: Sunday, December 07, 2008 5:41 AM
To: Beagle Board
Subject: [beagleboard] Re: OMAP3530 EVM with 2.6.27 Kernel

This would probably be found sooner if it was started on a new
thread...

> Is anyone using the OMAP3530 EVM board. I can get the board to work with

the

> 2.6.22 kernel and u-boot 1.1.4, but now I want to update u-boot to

2008.10

> and the 2.6.27 kernel, but I get the following error:
>
> Wrong Image Format for bootm command
> ERROR: can't get kernel image!
>
> I updated bootargs and bootcmd similar to what I used to boot

BeagleBoard

> with the same release of u-boot and kernel, but I get an error when I

set

Thanh_Tran · December 9, 2008, 1:43am

I had similar problem. Adding a single quote around the command seemed to fix the problem:

setenv bootcmd ‘mmcinit; fatload mmc 0:1 0x80200000 uImage; bootm 0x80200000’

-Thanh

— On Mon, 12/8/08, John (USP) jsynesio@us-power.com wrote:

> From: John (USP) jsynesio@us-power.com
> Subject: [beagleboard] Re: OMAP3530 EVM with 2.6.27 Kernel
> To: beagleboard@googlegroups.com
> Date: Monday, December 8, 2008, 2:47 PM
>
> > Hi Jason, > > When I received the loaner board from TI this was the environment: > > OMAP3_EVM # printenv > > bootargs=setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/mtdblock4 > rw2 > bootcmd=onenand read 80200000 280000 400000 ; bootm 80200000 > > bootdelay=10 > > baudrate=115200 > > netmask=255.255.254.0 > > bootfile="uImage" > > stdin=serial > > stdout=serial > > stderr=serial > > Somehow this seemed to work for the cube demo that comes with this board. > This was using 2.6.22 kernel and 1.1.4 u-boot. > > I tried to set bootcmd and bootargs to something similar to what I used on > my BeagleBoard, using the following commands: > > setenv bootargs console=ttyS0,115200n8 root=/dev/mmcblk0p2 rootdelay=2 > rootfstype=ext3 ro video=omapfb:vram:2M,vram:4M8 > setenv bootcmd mmcinit; fatload mmc 0:1 0x80200000 uImage; bootm 0x80200000 > > However, when I try to set the bootcmd, it says: > > ** Unable to use mmc 0:1 for fatload ** > Wrong Image Format for bootm command > ERROR: can't get kernel image! > > Regards, > > > -----Original Message----- > > From: beagleboard@googlegroups.com > > [mailto:beagleboard@googlegroups.com] On Behalf Of Jason Kridner > > Sent: Sunday, December 07, 2008 5:41 AM > > To: Beagle Board > > Subject: [beagleboard] Re: OMAP3530 EVM with 2.6.27 Kernel > > > > > > This would probably be found sooner if it was started on a new > > thread... > > > > On Dec 6, 12:22 am, "John $USP$" > <jsyne...@us-power.com> wrote: > > > Is anyone using the OMAP3530 EVM board. I can get the board to work > with > the > > > 2.6.22 kernel and u-boot 1.1.4, but now I want to update u-boot to > 2008.10 > > > and the 2.6.27 kernel, but I get the following error: > > > > > > Wrong Image Format for bootm command > > > ERROR: can't get kernel image! > > > > > > I updated bootargs and bootcmd similar to what I used to boot > BeagleBoard > > > with the same release of u-boot and kernel, but I get an error when I > set > > > bootcmd: > > > > > > ** Unable to use mmc 0:1 for fatload ** > > > Wrong Image Format for bootm command > > > ERROR: can't get kernel image! > > > > > > I built the kernel and u-boot using omap3evm config. > > > > > > > Can you share the exact log of your u-boot session and print out our > > environment variables? > > > > > >

|

John_USP · December 9, 2008, 1:52am

Hi Thanh,

Thank you so much. I just discovered the a few minutes ago. Now I’m copying my debian filesystem to my SDCard and will see if I can get this to finally work.

Regards,

John_USP · December 10, 2008, 7:57pm

I’m still having some difficulty getting 2.6.27 running on the OMAP35xx EVM board.

I start with a cloned SD Card of the TI Cube demo, which is based on u-boot 1.1.4 and Linux Kernel 2.6.22. The cloned SD Card boots up and works fine. I overwrite u-boot.bin with u-boot.bin version 2008.10-00953-dirty and I replace uImage with uImage version 2.6.27-omap1. It doesn’t matter whether I leave the file system on the second partition as is or replace it with a Debian file system that works fine on my BeagleBoard, it fails right after the rootdelay when it tries to mount the MMC. For some reason it does not find the second partition.

This is my u-boot environment:

bootdelay=10

baudrate=115200

bootfile=“uImage”

bootcmd=mmcinit; fatload mmc 0:1 0x80300000 uImage; bootm 0x80300000

bootargs=console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootdelay=4 rootfstype=ext3 video=omapfb:vram:2M,vram:4M,mode:640x480@60,vxres=640,vyres=480

gatewayip=10.100.116.1

ethaddr=08:00:28:01:1C:18

gateway=10.100.116.1

ipaddr=10.100.116.105

netmask=255.255.255.0

serverip=10.100.116.24

stdin=serial

stdout=serial

stderr=serial

Environment size: 442/131068 bytes

And here is the console output:

OMAP3_EVM # boot

reading uImage

1850632 bytes read

Booting kernel from Legacy Image at 80300000 …

Image Name: Linux-2.6.27-omap1

Image Type: ARM Linux Kernel Image (uncompressed)

Data Size: 1850568 Bytes = 1.8 MB

Load Address: 80008000

Entry Point: 80008000

Verifying Checksum … OK

Loading Kernel Image … OK

OK

Starting kernel …

Uncompressing Linux… done, booting t.

<5>Linux version 2.6.27-omap1 (jsynesio@DellXPSGen2) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-41) ) #1 Wed Dec 3 22:17:58 PST 2008

CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f

Machine: OMAP3 EVM

Memory policy: ECC disabled, Data cache writeback

<7>On node 0 totalpages: 32768

<7>free_area_init_node: node 0, pgdat c039b4b4, node_mem_map c03b5000

<7> DMA zone: 32512 pages, LIFO batch:7

<6>OMAP3430 ES2.0

<6>SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000

CPU0: L1 I VIPT cache. Caches unified at level 2, coherent at level 3

CPU0: Level 1 cache is separate instruction and data

CPU0: I cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,

supports RA

CPU0: D cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,

supports RA WB WT

CPU0: Level 2 cache is unified

CPU0: unified cache: 262144 bytes, associativity 8, 64 byte lines, 512 sets,

supports WA RA WB WT

Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512

<5>Kernel command line: console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootdelay=4 rootfstype=ext3 video=omapfb:vram:2M,vram:4M,mode:640x480@60,vxres=640,0

<6>Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz

<6>GPMC revision 5.0

<6>IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts

<6>Total of 96 interrupts on 1 active controller

<6>OMAP34xx GPIO hardware version 2.5

PID hash table entries: 512 (order: 9, 2048 bytes)

<6>OMAP clockevent source: GPTIMER1 at 32768 Hz

Console: colour dummy device 80x30

<6>Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

<6>Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)

<6>Memory: 128MB = 128MB total

<5>Memory: 126008KB available (3360K code, 246K data, 148K init)

<6>Calibrating delay loop… 499.92 BogoMIPS (lpj=1949696)

Mount-cache hash table entries: 512

<6>CPU: Testing write buffer coherency: ok

<6>net_namespace: 288 bytes

<6>NET: Registered protocol family 16

<6>OMAP DMA hardware revision 4.0

<3>USB: No board-specific platform config found

<6>i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz

<6>twl4030: PIH (irq 7) chaining IRQs 368…375

<6>twl4030: power (irq 373) chaining IRQs 376…383

<6>twl4030: gpio (irq 368) chaining IRQs 384…401

<6>i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz

<6>i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz

<6>twl4030_usb twl4030_usb: Initialized TWL4030 USB module

<5>SCSI subsystem initialized

<6>usbcore: registered new interface driver usbfs

<6>usbcore: registered new interface driver hub

<6>usbcore: registered new device driver usb

<6>musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0

<7>musb_hdrc: ConfigData=0x55 (UTMI-16, dyn FIFOs, bulk split (X), HB-ISO Rx (X))

<7>musb_hdrc: MHDRC RTL version 1.400

<7>musb_hdrc: setup fifo_mode 4

<7>musb_hdrc: 29/31 max ep, 15424/16384 memory

<7>musb_hdrc: hw_ep 0shared, max 64

<7>musb_hdrc: hw_ep 1tx, max 512

<7>musb_hdrc: hw_ep 1rx, max 512

<7>musb_hdrc: hw_ep 2tx, max 512

<7>musb_hdrc: hw_ep 2rx, max 512

<7>musb_hdrc: hw_ep 3tx, max 512

<7>musb_hdrc: hw_ep 3rx, max 512

<7>musb_hdrc: hw_ep 4tx, max 512

<7>musb_hdrc: hw_ep 4rx, max 512

<7>musb_hdrc: hw_ep 5tx, max 512

<7>musb_hdrc: hw_ep 5rx, max 512

<7>musb_hdrc: hw_ep 6tx, max 512

<7>musb_hdrc: hw_ep 6rx, max 512

<7>musb_hdrc: hw_ep 7tx, max 512

<7>musb_hdrc: hw_ep 7rx, max 512

<7>musb_hdrc: hw_ep 8tx, max 512

<7>musb_hdrc: hw_ep 8rx, max 512

<7>musb_hdrc: hw_ep 9tx, max 512

<7>musb_hdrc: hw_ep 9rx, max 512

<7>musb_hdrc: hw_ep 10tx, max 512

<7>musb_hdrc: hw_ep 10rx, max 512

<7>musb_hdrc: hw_ep 11tx, max 512

<7>musb_hdrc: hw_ep 11rx, max 512

<7>musb_hdrc: hw_ep 12tx, max 512

<7>musb_hdrc: hw_ep 12rx, max 512

<7>musb_hdrc: hw_ep 13tx, max 512

<7>musb_hdrc: hw_ep 13rx, max 512

<7>musb_hdrc: hw_ep 14shared, max 1024

<7>musb_hdrc: hw_ep 15shared, max 1024

<6>musb_hdrc: USB OTG mode controller at d80ab000 using DMA, IRQ 92

<6>NET: Registered protocol family 2

<7>Switched to high resolution mode on CPU 0

<6>IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

<6>TCP established hash table entries: 4096 (order: 3, 32768 bytes)

<6>TCP bind hash table entries: 4096 (order: 2, 16384 bytes)

<6>TCP: Hash tables configured (established 4096 bind 4096)

<6>TCP reno registered

<6>NET: Registered protocol family 1

<4>NetWinder Floating Point Emulator V0.97 (double precision)

<5>VFS: Disk quotas dquot_6.5.1

Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)

<6>msgmni has been set to 246

<6>io scheduler noop registered

<6>io scheduler anticipatory registered (default)

<6>io scheduler deadline registered

<6>io scheduler cfq registered

<6>omapfb: configured for panel omap3evm

<4>coherent allocation too big (requested 0x200000 mask 0xffffffff)

<3>omapfb omapfb: unable to allocate FB DMA memory

<3>omapfb omapfb: controller initialization failed (-12)

<6>Serial: 8250/16550 driver4 ports, IRQ sharing enabled

<6>serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654

<6>console [ttyS0] enabled

Linux version 2.6.27-omap1 (jsynesio@DellXPSGen2) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-41) ) #1 Wed Dec 3 22:17:58 PST 2008

CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f

Machine: OMAP3 EVM

Memory policy: ECC disabled, Data cache writeback

OMAP3430 ES2.0

SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000

CPU0: L1 I VIPT cache. Caches unified at level 2, coherent at level 3

CPU0: Level 1 cache is separate instruction and data

CPU0: I cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,

supports RA

CPU0: D cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,

supports RA WB WT

CPU0: Level 2 cache is unified

CPU0: unified cache: 262144 bytes, associativity 8, 64 byte lines, 512 sets,

supports WA RA WB WT

Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512

Kernel command line: console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootdelay=4 rootfstype=ext3 video=omapfb:vram:2M,vram:4M,mode:640x480@60,vxres=640,vyr0

Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz

GPMC revision 5.0

IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts

Total of 96 interrupts on 1 active controller

OMAP34xx GPIO hardware version 2.5

PID hash table entries: 512 (order: 9, 2048 bytes)

OMAP clockevent source: GPTIMER1 at 32768 Hz

Console: colour dummy device 80x30

Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)

Memory: 128MB = 128MB total

Memory: 126008KB available (3360K code, 246K data, 148K init)

Calibrating delay loop… 499.92 BogoMIPS (lpj=1949696)

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

net_namespace: 288 bytes

NET: Registered protocol family 16

OMAP DMA hardware revision 4.0

USB: No board-specific platform config found

i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz

twl4030: PIH (irq 7) chaining IRQs 368…375

twl4030: power (irq 373) chaining IRQs 376…383

twl4030: gpio (irq 368) chaining IRQs 384…401

i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz

i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz

twl4030_usb twl4030_usb: Initialized TWL4030 USB module

SCSI subsystem initialized

usbcore: registered new interface driver usbfs

usbcore: registered new interface driver hub

usbcore: registered new device driver usb

musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0

musb_hdrc: USB OTG mode controller at d80ab000 using DMA, IRQ 92

NET: Registered protocol family 2

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 4096 (order: 3, 32768 bytes)

TCP bind hash table entries: 4096 (order: 2, 16384 bytes)

TCP: Hash tables configured (established 4096 bind 4096)

TCP reno registered

NET: Registered protocol family 1

NetWinder Floating Point Emulator V0.97 (double precision)

VFS: Disk quotas dquot_6.5.1

Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)

msgmni has been set to 246

io scheduler noop registered

io scheduler anticipatory registered (default)

io scheduler deadline registered

io scheduler cfq registered

omapfb: configured for panel omap3evm

coherent allocation too big (requested 0x200000 mask 0xffffffff)

omapfb omapfb: unable to allocate FB DMA memory

omapfb omapfb: controller initialization failed (-12)

Serial: 8250/16550 driver4 ports, IRQ sharing enabled

serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654

console [ttyS0] enabled

<6>serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654

serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654

<6>serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654

serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654

<6>brd: module loaded

brd: module loaded

<6>loop: module loaded

loop: module loaded

eth0: LAN9115 (rev 2) at 0x2c000000 IRQ 336eth0: LAN9115 (rev 2) at 0x2c000000 IRQ 336

eth0: Invalid ethernet MAC address. Please set using ifconfig

<7>eth0: LAN911x Internal PHY

<6>i2c /dev entries driver

i2c /dev entries driver

<4>Driver ‘sd’ needs updating - please use bus_type methods

Driver ‘sd’ needs updating - please use bus_type methods

<6>OneNAND driver initializing

OneNAND driver initializing

<6>omap2-onenand omap2-onenand: initializing on CS0, phys base 0x20000000, virtual base c8880000

omap2-onenand omap2-onenand: initializing on CS0, phys base 0x20000000, virtual base c8880000

<7>OneNAND Manufacturer: Samsung (0xec)

<6>Muxed OneNAND 128MB 1.8V 16-bit (0x30)

Muxed OneNAND 128MB 1.8V 16-bit (0x30)

<6>OneNAND version = 0x0221

OneNAND version = 0x0221

<7>Chip support all block unlock

<6>Scanning device for bad blocks

Scanning device for bad blocks

<6>onenand_bbt_wait: ecc error = 0x2222, controller error 0x2400

onenand_bbt_wait: ecc error = 0x2222, controller error 0x2400

<4>Bad eraseblock 752 at 0x05e00000

Bad eraseblock 752 at 0x05e00000

<5>Creating 5 MTD partitions on “omap2-onenand”:

Creating 5 MTD partitions on “omap2-onenand”:

<5>0x00000000-0x00080000 : “xloader”

0x00000000-0x00080000 : “xloader”

<5>0x00080000-0x00260000 : “uboot”

0x00080000-0x00260000 : “uboot”

<5>0x00260000-0x00280000 : “params”

0x00260000-0x00280000 : “params”

<5>0x00280000-0x00780000 : “linux”

0x00280000-0x00780000 : “linux”

<5>0x00780000-0x08000000 : “jffs2”

0x00780000-0x08000000 : “jffs2”

<5>usbmon: debugfs is not available

usbmon: debugfs is not available

<6>Initializing USB Mass Storage driver…

Initializing USB Mass Storage driver…

<6>usbcore: registered new interface driver usb-storage

usbcore: registered new interface driver usb-storage

<6>USB Mass Storage support registered.

USB Mass Storage support registered.

<6>usbcore: registered new interface driver usbtest

usbcore: registered new interface driver usbtest

<6>input: omap_twl4030keypad as /class/input/input0

input: omap_twl4030keypad as /class/input/input0

<6>ads7846 spi1.0: touchscreen, irq 335

ads7846 spi1.0: touchscreen, irq 335

<6>input: ADS784x Touchscreen as /class/input/input1

input: ADS784x Touchscreen as /class/input/input1

<6>OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec

OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec

<6>usbcore: registered new interface driver usbhid

usbcore: registered new interface driver usbhid

<6>usbhid: v2.6:USB HID core driver

usbhid: v2.6:USB HID core driver

<6>TCP cubic registered

TCP cubic registered

<6>NET: Registered protocol family 17

NET: Registered protocol family 17

<6>NET: Registered protocol family 15

NET: Registered protocol family 15

<6>RPC: Registered udp transport module.

RPC: Registered udp transport module.

<6>RPC: Registered tcp transport module.

RPC: Registered tcp transport module.

<3>Power Management for TI OMAP3.

Power Management for TI OMAP3.

<6>SmartReflex driver initialized

SmartReflex driver initialized

<6>Disabling unused clock “sr2_fck”

Disabling unused clock “sr2_fck”

<6>Disabling unused clock “sr1_fck”

Disabling unused clock “sr1_fck”

<6>Disabling unused clock “mcbsp_fck”

Disabling unused clock “mcbsp_fck”

<6>Disabling unused clock “mcbsp_fck”

Disabling unused clock “mcbsp_fck”

<6>Disabling unused clock “mcbsp_fck”

Disabling unused clock “mcbsp_fck”

<6>Disabling unused clock “mcbsp_ick”

Disabling unused clock “mcbsp_ick”

<6>Disabling unused clock “mcbsp_ick”

Disabling unused clock “mcbsp_ick”

<6>Disabling unused clock “mcbsp_ick”

Disabling unused clock “mcbsp_ick”

<6>Disabling unused clock “gpt2_ick”

Disabling unused clock “gpt2_ick”

<6>Disabling unused clock “gpt3_ick”

Disabling unused clock “gpt3_ick”

<6>Disabling unused clock “gpt4_ick”

Disabling unused clock “gpt4_ick”

<6>Disabling unused clock “gpt5_ick”

Disabling unused clock “gpt5_ick”

<6>Disabling unused clock “gpt6_ick”

Disabling unused clock “gpt6_ick”

<6>Disabling unused clock “gpt7_ick”

Disabling unused clock “gpt7_ick”

<6>Disabling unused clock “gpt8_ick”

Disabling unused clock “gpt8_ick”

<6>Disabling unused clock “gpt9_ick”

Disabling unused clock “gpt9_ick”

<6>Disabling unused clock “wdt3_ick”

Disabling unused clock “wdt3_ick”

<6>Disabling unused clock “wdt3_fck”

Disabling unused clock “wdt3_fck”

<6>Disabling unused clock “gpio2_dbck”

Disabling unused clock “gpio2_dbck”

<6>Disabling unused clock “gpio3_dbck”

Disabling unused clock “gpio3_dbck”

<6>Disabling unused clock “gpio4_dbck”

Disabling unused clock “gpio4_dbck”

<6>Disabling unused clock “gpio5_dbck”

Disabling unused clock “gpio5_dbck”

<6>Disabling unused clock “gpt9_fck”

Disabling unused clock “gpt9_fck”

<6>Disabling unused clock “gpt8_fck”

Disabling unused clock “gpt8_fck”

<6>Disabling unused clock “gpt7_fck”

Disabling unused clock “gpt7_fck”

<6>Disabling unused clock “gpt6_fck”

Disabling unused clock “gpt6_fck”

<6>Disabling unused clock “gpt5_fck”

Disabling unused clock “gpt5_fck”

<6>Disabling unused clock “gpt4_fck”

Disabling unused clock “gpt4_fck”

<6>Disabling unused clock “gpt3_fck”

Disabling unused clock “gpt3_fck”

<6>Disabling unused clock “gpt2_fck”

Disabling unused clock “gpt2_fck”

<6>Disabling unused clock “gpt12_ick”

Disabling unused clock “gpt12_ick”

<6>Disabling unused clock “wdt1_ick”

Disabling unused clock “wdt1_ick”

<6>Disabling unused clock “wdt2_ick”

Disabling unused clock “wdt2_ick”

<6>Disabling unused clock “wdt2_fck”

Disabling unused clock “wdt2_fck”

<6>Disabling unused clock “gpio1_dbck”

Disabling unused clock “gpio1_dbck”

<6>Disabling unused clock “cam_ick”

Disabling unused clock “cam_ick”

<6>Disabling unused clock “cam_mclk”

Disabling unused clock “cam_mclk”

<6>Disabling unused clock “des1_ick”

Disabling unused clock “des1_ick”

<6>Disabling unused clock “sha11_ick”

Disabling unused clock “sha11_ick”

<6>Disabling unused clock “rng_ick”

Disabling unused clock “rng_ick”

<6>Disabling unused clock “aes1_ick”

Disabling unused clock “aes1_ick”

<6>Disabling unused clock “ssi_ick”

Disabling unused clock “ssi_ick”

<6>Disabling unused clock “mailboxes_ick”

Disabling unused clock “mailboxes_ick”

<6>Disabling unused clock “mcbsp_ick”

Disabling unused clock “mcbsp_ick”

<6>Disabling unused clock “mcbsp_ick”

Disabling unused clock “mcbsp_ick”

<6>Disabling unused clock “gpt10_ick”

Disabling unused clock “gpt10_ick”

<6>Disabling unused clock “gpt11_ick”

Disabling unused clock “gpt11_ick”

<6>Disabling unused clock “hdq_ick”

Disabling unused clock “hdq_ick”

<6>Disabling unused clock “mspro_ick”

Disabling unused clock “mspro_ick”

<6>Disabling unused clock “mmchs_ick”

Disabling unused clock “mmchs_ick”

<6>Disabling unused clock “mmchs_ick”

Disabling unused clock “mmchs_ick”

<6>Disabling unused clock “des2_ick”

Disabling unused clock “des2_ick”

<6>Disabling unused clock “sha12_ick”

Disabling unused clock “sha12_ick”

<6>Disabling unused clock “aes2_ick”

Disabling unused clock “aes2_ick”

<6>Disabling unused clock “icr_ick”

Disabling unused clock “icr_ick”

<6>Disabling unused clock “pka_ick”

Disabling unused clock “pka_ick”

<6>Disabling unused clock “ssi_ssr_fck”

Disabling unused clock “ssi_ssr_fck”

<6>Disabling unused clock “hdq_fck”

Disabling unused clock “hdq_fck”

<6>Disabling unused clock “mcbsp_fck”

Disabling unused clock “mcbsp_fck”

<6>Disabling unused clock “mcbsp_fck”

Disabling unused clock “mcbsp_fck”

<6>Disabling unused clock “mmchs_fck”

Disabling unused clock “mmchs_fck”

<6>Disabling unused clock “mspro_fck”

Disabling unused clock “mspro_fck”

<6>Disabling unused clock “mmchs_fck”

Disabling unused clock “mmchs_fck”

<6>Disabling unused clock “gpt11_fck”

Disabling unused clock “gpt11_fck”

<6>Disabling unused clock “gpt10_fck”

Disabling unused clock “gpt10_fck”

<6>Disabling unused clock “iva2_ck”

Disabling unused clock “iva2_ck”

<6>Disabling unused clock “dpll5_ck”

Disabling unused clock “dpll5_ck”

<6>Disabling unused clock “dpll4_m6x2_ck”

Disabling unused clock “dpll4_m6x2_ck”

<6>Disabling unused clock “dpll4_m5x2_ck”

Disabling unused clock “dpll4_m5x2_ck”

<6>Disabling unused clock “dpll3_m3x2_ck”

Disabling unused clock “dpll3_m3x2_ck”

<6>Disabling unused clock “sys_clkout1”

Disabling unused clock “sys_clkout1”

<6>VFP support v0.3: VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1

implementor 41 architecture 3 part 30 variant c rev 1

<6>Waiting 4sec before mounting root device…

Waiting 4sec before mounting root device…

<3>Root-NFS: No NFS server available, giving up.

Root-NFS: No NFS server available, giving up.

<3>VFS: Unable to mount root fs via NFS, trying floppy.

VFS: Unable to mount root fs via NFS, trying floppy.

VFS: Cannot open root device “mmcblk0p2” or unknown-block(2,0)

Please append a correct “root=” boot option; here are the available partitions:

1f00 512 mtdblock01f00 512 mtdblock0 (driver?)

(driver?)

1f01 1920 mtdblock11f01 1920 mtdblock1 (driver?)

(driver?)

1f02 128 mtdblock21f02 128 mtdblock2 (driver?)

(driver?)

1f03 5120 mtdblock31f03 5120 mtdblock3 (driver?)

(driver?)

1f04 123392 mtdblock41f04 123392 mtdblock4 (driver?)

(driver?)

<0>Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

Regards,

RobertCNelson · December 10, 2008, 8:50pm

Hi John,

I don't have an evm board at my desk to actually test this, but does
this uImage, bootcmd, bootarg [1] make a difference?

For comparison his .config is located here:
http://people.ubuntu.com/~ogra/arm/OMAP35x_EVM/kernel/

1. http://people.ubuntu.com/~ogra/arm/OMAP35x_EVM/

John_USP · December 10, 2008, 10:17pm

Hi Robert,

Again, you are the greatest. I'm not sure why, but using this uImage, the
EVM board boots up, but when I use the uImage I built from the GIT
repository and using the evm config, it won't load the file system. I'm
going to rebuild uImage using the kernel config available on this site.

Thank you again.

Regards,

From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Robert Nelson
Sent: Wednesday, December 10, 2008 12:50 PM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Re: OMAP3530 EVM with 2.6.27 Kernel

> I'm still having some difficulty getting 2.6.27 running on the OMAP35xx

EVM

> board.
>
> I start with a cloned SD Card of the TI Cube demo, which is based on

u-boot

> 1.1.4 and Linux Kernel 2.6.22. The cloned SD Card boots up and works

fine. I

> overwrite u-boot.bin with u-boot.bin version 2008.10-00953-dirty and I
> replace uImage with uImage version 2.6.27-omap1. It doesn't matter

whether I

> leave the file system on the second partition as is or replace it with a
> Debian file system that works fine on my BeagleBoard, it fails right

after

> the rootdelay when it tries to mount the MMC. For some reason it does

not

kapare · December 11, 2008, 9:38pm

Hi

I try to run the kernel image of Robert and it work!

I run the demo that come with the OMAP35xx EVM in /usr/tests/demo

two problems:
1- pictures are display with wrong colors, in red and black.
2- keyboard event are not working (strange since I see /dev/input/
eventx).

Is someone able to confirm that uImage have been done with:
http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=log
Cross compiler from codesourcery 2007q3

If so is there a patch to fix the screen colors & keyboard ?

Regards

kap