iMX51 Project 暫停......

因為 AM335x 的 cost 比這個有競爭力 , 加上 AM335x 的 suspend 問題有眉目了 ,
所以這個備胎案就宣告暫停了 ~~~

SGTL50000 CODEC With OSS driver bug.

我們的系統 ,都使用 ASLA 聲音系統 , 只有 Flash 使用 OSS .

結果 , aplay , fsplay 都可以正確播放聲音 , 只有 Falsh 會有問題 .
聲音 ,影像都卡卡的 .

一開始懷疑 LCD 的 format 格式不對 (之前是 888 , 現在是 565 ) 的問題 ,
找了半天發現 , 只要關閉聲音輸出 , 影像就會很流暢 . 所以又開始懷疑 CPU 不夠力.

經過測試 , 一邊播放 MP3 音樂 , 同時播放 沒有聲音的 flash , 兩者也能很流暢的播放.
想一想也對 , 之前 ARM 9 都可以很順暢 , 沒道理 Cortex-A8 會卡卡的 , 應該OSS Driver 有問題.

我將 DirectFB FusionSound 掛載 OSS 的 driver . 發現 fsplay 就會卡卡的 ,並且聲音輸出怪怪的. 確定OSS Driver 有問題.
我將 fusionsound OSS 的 so 檔移除 , 讓 fsplay 去使用alsa , 就會很正常.

/lib/directfb-1.3-0/snddrivers/libfusionsound_alsa.so libfusionsound_oss.bad libfusionsound_wave.so

經過觀察 ARM 9 和 iMX51 的 asound hw_params 發現 ASLA 的 buffer_size 太小 (如下),
動手修改 /linux/sounc/soc/imx/imx-pcm.c 後舊可加大 buffer_size , 並且 要關閉CONFIG_SND_MXC_SOC_IRAM . 不過還是沒有用 .

//=> /linux/sounc/soc/imx/imx-pcm.c 修改內容.

static const struct snd_pcm_hardware imx_pcm_hardware = {
.info = (SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_MMAP_VALID |
SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME),
.formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE,
#ifdef CONFIG_SND_MXC_SOC_IRAM
.buffer_bytes_max = SND_RAM_SIZE,
.period_bytes_max = SND_RAM_SIZE / 4,
#else
.buffer_bytes_max = 128 * 1024,
.period_bytes_max = 64 * 1024,
#endif
.period_bytes_min = 2 * SZ_1K,
.periods_min = 2,
.periods_max = 255,
.fifo_size = 0,
};


//=> 修改之前的 hw_params
cat /proc/asound/card0/pcm0p/sub0/hw_params

access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 22050 (22050/1)
period_size: 2048
buffer_size: 4096
OSS format: S16_LE
OSS channels: 2
OSS rate: 22050
OSS period bytes: 1024
OSS periods: 2
OSS period frames: 2048

//=> 修改之後的 hw_params
cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 22050 (22050/1)
period_size: 2048
buffer_size: 32768
OSS format: S16_LE
OSS channels: 2
OSS rate: 22050
OSS period bytes: 8192
OSS periods: 16
OSS period frames: 2048

尋找了兩天 , 發現 ASLA 只會設定一次 hw_params , OSS 卻會設定很多次 hw_params ,
並且在 /linux/sounc/soc/imx/imx-3stack-sgtl5000.c 的 imx_3stack_audio_hw_params() 中有一個旗標 , 讓hw_params只能設定一次 , 哇咧....難怪 OSS Driver 都怪怪的.
Mark 掉 下列兩行 , Flash player 可以正確 working 了..... !

static int imx_3stack_audio_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
unsigned int channels = params_channels(params);
u32 dai_format;

/* only need to do this once as capture and playback are sync */
// if (priv->hw)
// return 0;
priv->hw = 1;

#if defined(CONFIG_MXC_ASRC) || defined(CONFIG_MXC_ASRC_MODULE)
if ((asrc_ssi_data.output_sample_rate != 0)

呼....困惑我 3 天的東西終於可解決了 , 下一步 .... Video player 支援 565 LCD format .....

modprobe g_file_gstorage fail "unknown relocation: 3" problem

今天本來想說 mass storage driver 比較簡單,想說來驗證ㄧ下,
結果竟出現 "unknown relocation: 3." error , 找了半天,發現 ./arch/arm/kernel/module.c
中沒有辦法處理 R_ARM_REL32 type , 花了一天, 最後還是
問一下 "谷歌" "kernel module.c not handling R_ARM_REL32" ,結果 就有解決方式。

原來
gcc-4.4 defaults to generating .eh_frame sections, but we aren't interested in those currently.
請參考
http://forums.arm.com/index.php?/topic/8122-kernel-modulec-not-handling-r-arm-rel32/

eMMC booting bug

這幾天發現一個詭異的 bug , 用 SDHC Card 開機 , CODEC 可以正常 probe .
如果用 eMMC開機 , 卻會導致 CODEC Probe Fail .
怎樣都覺得詭異 ,同一個 u -boot , kernel 卻只是不同 device booting 卻有這樣的差異 .
經過比對整個 booting message , 發現主要是 PMIC 的電壓設定不正確 ,才會導致 CODEC
電壓對 , Driver Probe fail .

在詳細尋找 , 發現是 u-boot 引起 , 所以...花時時間仔細尋找 , 才發現下面這個 bug .
在spi_setup_slave() function 中 , 有使用 malloc 的方式配置 imx_spi_slave 的變數 ,
但是要注意 , 內容並非 全部都是 "ZERO" , 所以需要補上 memset(......... )
詭異的 bug 就可以解決了 .

imx_spi_slave = (struct imx_spi_dev_t *)malloc(sizeof(struct imx_spi_dev_t));
if (!imx_spi_slave)
return NULL;
memeset(imx_spi_slave,0x0,sizeof(struct imx_spi_dev_t));

imx_spi_slave->slave.bus = bus;
imx_spi_slave->slave.cs = cs;

我沒有在 詳細追朔為何 SDHC 可以成功 , eMMC 卻會導致malloc 的內容以 garbage .
不過 malloc 後 , 如果要確認內容是 "ZERO" 本來就需要 memset 來初始化.
先這樣了 , 可見 iMX51的 BSP 還是不怎樣嚴謹 !! 一堆小 bug.

fatload bug of U-boot Command

最近發現我的 Demo Board 非常不穩定 , Kernel 增加一行 printk 就會導致 U-boot load kernel當掉 !!　這樣沒有辦法 debug kernel , 所以花時間尋找一下 bug !!
　
最後發現只要 kernel 不是 512 的倍數就會導致u-boot 在 fatload 時候卡住 ,如果是 512倍數就沒有問題 , 真是奇怪的問題 , 不過猜想應該是 eMMC reading Function 有問題 , 因為 512 剛好是 sector 的大小 .

找最後 , 發現 get_cluster() 中會呼叫 disk_read() , 並且傳所需要的 block size 數量給 disk_read() , size/FS_BLOCK_SIZE , 如果 size 小於 FS_BLOCK_SIZE 就會傳 "0" 給 disk_read() , 是這邊導致整個 u-boot 當掉 , 所以 , 多加一行 判別 , 如果是 "0" 就傳 "1 " ,這樣就解決了 !!
這樣會有一個小問題 , 就是會多讀取幾個 byte 到 DRAM 中 . 不過在我們的應用上沒有大問題 , 主要是 loading kernel 罷了 , 多出來的也不會有問題.

目前先這樣解決 !!

Prepare BSP Source code ......

我們所使用的GUI 介面是 GTK + DirectFB , 所以 ... 我只需要 kernel , u-boot 等...和GUI 介面無關的 BSP Code 即可 !!
到 FreeScale 下載 L2.6.35_10.11.01_ER_source_bundle.tar.gz !!
解開後.... 哇....超多東西 , 印象中 FreeScale 有一套 開發環境 , 需要 install ..... !!
果然.... 好大一包 BSP ..... !!
經過尋找後 , 先取出 u-boot .....
L2.6.35_10.11.01_ER_source/pkgs/u-boot-2009.08.tar.bz2
L2.6.35_10.11.01_ER_source/pkgs/u-boot-v2009.08-imx_10.11.01.tar.bz2
其中 u-boot-2009.08.tar.bz2 和官方網頁上的相同 , 另外一個是 FreeScale 的patch file .

相同的 , 取出 kernel .......
L2.6.35_10.11.01_ER_source/pkgs/linux-2.6.35.3.tar.bz2
L2.6.35_10.11.01_ER_source/pkgs/linux-2.6.35.3-imx_10.11.01.bz2
一樣一個是標準 source code , 另外一個是 patch file .

這個 Target 最後不會使用 NAND , 會使用 eMMC , 所以需要一個 utility (elftosd)
L2.6.35_10.11.01_ER_source/pkgs/elftosb-10.11.01.tar.gz

kernel , u-boot 在 make 過程都順利沒有問題 , 不過 elftosd 卻會 make error .
我的 Host 是 Fedora 16 , 出問題點是找不到 libm.so file ....
花了一些時間後 對 makefile.rules 進行下列 patch 即可了 .
sed -i 's/-lstdc++/-lstdc++\ -lm/g' $(VERSION)/makefile.rules

目前準備到這裡 ....接著要等 DEMO Board 來測試一下 u-boot , kernel 是否可以 working .....

Start iMX51 Proting ....

結束了 Am335x 的 CPU 後 , 更換為 iMX51 這系列的 CPU ....
接著 , 進行 iMX51 Porting .... !!
不知道 BSP 完整度如何 ?? 不過這個 CPU 已經量產有一段時間了 , 應該沒有啥大問題 !!
如果有 , FAE 應該也早就知道了 .... 期望...這個 Project 可以順利一點 ~~~ !!