Nishanth' tech rambles

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

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 ...

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??...

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.. on...

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...

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 I...

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 omap 2420 platforms? GPMC as an example...

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...