45 nm goes into production

http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=154&articleId=9044179&intsrc=hm_topic

Fat or Thin App processor?

Here is what a friend of mine Jayan John has to say (reposted with permission) on a discussion on various processor variants today in Cellphone business.

The relevant debate may not be “standalone baseband processors” vs”SOC", but whether or not SOC is the best option...

Why? Quote: “Convergence in the industry of computing capabilities and communication protocols has resulted in the development of devices with enhanced functionalities and capabilities. Providing a range of functions at a low cost while maintaining the reliability and compatibility of existing systems and devices is a major challenge today. As devices become more complex with numerous features, it is of prime importance to find out ways to extract more power from the batteries". With this in mind, choosing the right level of integration is a difficult decision.
To make this interesting… Read Texas Instruments vs Philips back in 2005 (http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=159901628). In this interesting debate facts appear to tip the scales in favor of SIP…

Comparison of SiP and SoC:

1. Flexibility: One of the key advantages of an SiP when compared to an SoC, is the high degree of flexibility that it provides for a design house. The ability of an SiP to combine from multiple semiconductor technologies and reuse intellectual property (IP) from multiple sources.

2. Development Time: Short development time/ time to market is achieved more quickly in SiP than SoC.

3. Development Cost: An SoC can typically take $4-5 million to develop, with advanced SoC designs costing $30 million. Such high costs are justifiable only if volumes are high and if the life cycle of the product is long.

4. Device Cost: When compared to an SiP, an SoC typically has a considerably lower device cost.

5. Functionality: The demand for increased functionality in portable devices such as cell phones, PDAs, and so on has driven the electronics industry to develop package solutions that can meet such requirements. Cell phone original equipment manufacturers (OEMs) could not keep pace with exponential demand for their products, and decided to integrate multiple active and passive components into an SiP, rather than investing in additional manufacturing lines.

6. Technical complexity: Integration of an IC function in a SoC requires multiple layers and results in an increased die size. Mixed signal processing complexity in SoC is also a concern.

Conclusion:

SoC is a viable option when the product life cycle is long and there is time and money. When there is enough volume for the product, sometimes, an SoC approach can be much less expensive than an SiP approach, but it depends on whether one is able to recover the nonrecurring engineering (NRE) costs and afford the time, as changes in the market for new products and features happen so quickly.

SiP, on the other hand, is best suited for products where time to market, flexibility, functionality, and cost are extremely important. The ability to combine multiple semiconductor technologies and use IP from different companies is viewed as one of the primary advantages of using SiP. Currently, applications such as cell phones, PDAs, and wireless products are driving the growth of the technology

Sources:

http://electronicdesign.com/Articles/Index.cfm?AD=1&ArticleID=10507

http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=159901628

http://www.frost.com/prod/servlet/market-insight-top.pag?docid=94297860

http://www.research.philips.com/password/archive/23/downloads/pw23_sip_18.pdf

http://ieeexplore.ieee.org/iel5/10489/33245/01568781.pdf

broadcom seems to have some coverage..

Here are some interesting news articles in recent days:
Appilcation processors are dead? http://www.linuxdevices.com/news/NS9250186181.html -> that'd be painful... ;)

Broadcom:
http://www.news.com/8301-10784_3-9797486-7.html?part=rss&subj=news&tag=2547-1_3-0-5 Cnet has some details though not radical
http://www.linuxdevices.com/news/NS8838596703.html - that is some indepth info..
Should the world tremble?

Colored printk: http://kerneltrap.org/Linux/Colored_printk_Output i like jazzy stuff.. mebbe i will steal this for uboot v2??...

uboot 2 for omap in development..

So, I am on a slow roll on uboot2 changes for OMAP.. uboot 2 is lot less mature as it can be seen digging into the code, but it is most promising. The main reason I want to jump on uboot2 is that omap support is very nascent here, and lots can be done..
Some areas of concern:
* i2c seems pretty unclear
* I like the dev concept, but should modules of OMAP be also dev based? I dont think so.. generic modules - yes..i2c etc..
* on dev -> it looks very immature considering that include/driver.h has:
45 struct driver_d {

55 ssize_t (*erase) (struct device_d*, size_t count, unsigned long offset);
56 int (*protect)(struct device_d*, size_t count, unsigned long offset, int prot);

59 void (*info) (struct device_d *);

Errrr... erase,protect,info ?? that is flash type device struct rt? it does not fit into a generic driver structure..
* I dont like the fact that there is still a config.h (include/configs/xyz.h SYMLINKed to include/config.h) which makes NO sense to me.. one of the ideas of menuconfig was to kick this crap out rt?? in OMAP I am thinking of maintaining this as a empty file.. but for some reason stuck with this:
CONFIG_BOOT_PARAMS CONFIG_ARCH_NUMBER CFG_MALLOC_LEN CONFIG_STACKSIZE

On my progress so far:
Since I have to sync house chores with uboot ... Not much to add except: the following is my current git-status (yeah yeah.. i need to checkin..)..
# On branch master
# Changed but not updated:
# (use "git add ..." to update what will be committed)
#
# modified: arch/arm/Kconfig
# modified: arch/arm/Makefile
# modified: arch/arm/cpu/Makefile
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# arch/arm/configs/omap2430_sdp2430_defconfig
# arch/arm/cpu/Kconfig
# arch/arm/cpu/start.S
# arch/arm/mach-omap/
# board/omap/
# include/asm-arm/arch-omap/
# include/configs/omap.h

I am going in for the following trees:
board/omap/ -> each board file comes here. Kconfig here define the board characteristics
arch/arm/mach-omap/ -> silicon stuff
-- common -> equal to plat-omap on kernel
-- omap1 -> equal to mach-omap1 on kernel
`-- omap2 -> equal to mach-omap2 on kernel
include/asm-arm/arch-omap/ (silicon includes)
-- omap1
`-- omap2
I dont want to throw out an half baked patch out, I kind of have the pinmux framework in place for omap2. i checked 1710,1610 trms, FUNC_MUX concept is a nightmare :(... maybe look at it 2morrow..

uboot follies!

Ok today I had a look of Makefile.. Denx supports a unified make file unlike the strategy in kernel. There are some interesting snippets of code in the same. In short, we could have something for configs as follows:

__ _config
Where,
SiliconName = omap2420, omap3430,et.al.
boardName = sdp,osk,apollon etc
Special = Boot Mode -> e.g. nand/onenand or defined boot mode for that platform.

Now, should i have es versions??? 3430 es1 and es2 are different enough to have two code definitions?

One thing I don’t agree to : u-boot.arm/doc/README.ARM-SoC
cpu/$(CPU)/$(SOC)/
does not facilitate re-use -> coz I might want to reuse across arm versions.. and this does not let me do it..

I am getting diverted again -> this time it is U-boot v2!!!!
cg-clone http://www.denx.de/git/u-boot-v2.git/ u-boot.v2
let me see what sacha has got...

Day 1: getting a feel and a few thoughts

Where are the files?
u-boot.arm is what i am basing myself on.
Directory: u-boot.arm/lib_arm/
Description:
ARM specific library function implementation
Files:
armlinux.c _ashrdi3.S cache.c _divsi3.S _modsi3.S _umodsi3.S
_ashldi3.S board.c div0.c Makefile _udivsi3.S
Contains:
some important (if I may use such a word - all look important):
bootm implementation,
banner display
cache functions
start_armboot

Directory:/u-boot.arm/cpu/arm1136
Description:
ARM1136 CPU specific logic. This is kind of common for most part. I can see that ARM integrator and 2420 are the two folks using this so far at least..

Files:
config.mk cpu.c interrupts.c Makefile start.S

Contains:
start.s is the basic starting point of the boot process..
__start is where the code starts the boot..
So... after almost an year and a half of CCS assembly, I need to brush up the GNU ARM Assembly.. i got it somewhere.. hmm..
Ref:
GNU ARM Assembly Quick Reference Guide: http://www.microcross.com/GNU-ARM-Assy-Quick-Ref.pdf
An Introduction to the GNU ARM Assembler - A Summary of the GNU Assembler Manual: http://www.microcross.com/assembler-intro.pdf
GNU inline assembler cookbook: http://www.ethernut.de/en/documents/arm-inline-asm.html

AND ofcourse:
ARM Architecture manual: http://www.arm.com/documentation/books/1183.html
(some 50 bucks or so... )
U can also see ARM V7 info here: http://www.arm.com/products/CPUs/ARM_Cortex-M3_v7.html

Note: I am just putting links here from google.. so lets see where it gets me.

(idea) on reset:
we do an ivt relocation to trampoline vector of rom code.. Hmm.. that should move out of there...
if i move it to cpu_init_crit....and keep _start to r0... will that work? mainly do arm integrator folks care?

I like Kyumin Park's patch on reusing the same uboot as xloader with lots of options stripped out.. so the boot code should be capable of that too..

(idea) arm1136_cache_flush
all flush and cache routines should go out to mmu.s

(idea) .reset_cpu is SOC based.. does not belong here..

(idea): asm/arch/omap2420.h
hmm...i'd like it as:
asm/arch/cpu.h
depends on asm/arch/soc.h
That brings about a larger question:
how should the code be organised.. I think the following is logical:
ARM --> SOC1
\-> SOC2 --> board1
\-> board2
reuse capability:
accross boards (e.g. fpga logic)
across soc (e.g. b/w 3430 and 2430 if i want to reuse gpmc)

now, that raises a question as to how each of the following should be organized:
a) board directory
b) cpu/arm1136
c) include/asm/arch

(idea): should int handling be isolated L220 specific? does not make sense to me... but.. on a larger context??

ok.. it is dinner time and bit of tv mebbe now..

OMAP Uboot port work started

I am starting off with a fresh OMAP port of uboot. Nothing is proper unless i answer some of my questions..

Why Do this?
* The main reason of doing this is coz I am sick and tired of crappy code and repatch folks have been doing.. and am hoping that I can do a clean reuse for OMAP platform
* U-boot is largely ignored for maybe the lack of fame and fortune stuff, but I kinda like it at the moment, coz it reminds me the first line of code i wrote for 2430 port.. it was in uboot.. on virtual platform. kind of presilicon. pressures were high, could never do a clean job then.. here is a chance to get things right..
* I am kind of tired doing my "project" work
* My wife is getting busy for her exams and other than an hour's walk, I wont get troubled much for a week at least (I hope ;) ).

What is my plan?
I am hoping to integrate a lot of modules and avoid repetitions where possible.. e.g.:
why have multiple board file for each of omap2420 platforms?
GPMC as an example remains common thru out, why not isolate it out...
FPGA is another example..
maybe I'd move with kernel like plat-omap, mach-omap1,mach-omap2 etc.. I don't know yet.. i will discuss my ideas with the list..
I will post every activity, thoughts i have on this blog, label such blogs with uboot, so it is a nice thing to check out *if* you are interested in this activity.. also u can let me know if you would like to contribute and any ideas, wish list etc is most welcome.


PS: Google's spell check sucks :( no add to dic option.

sine theta in kernel?

cordic algo seems pretty powerful: http://www.ddj.com/embedded/196700769
C Code for the same: http://my.execpc.com/~geezer/embed/cordic.c
Now to see if VFP and Neon support can handle float ops.. never tried it so far... Hmm...