您尚未登录。

#1 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2019-02-19 11:14:01

各位路过的大虾,有人用f1c100s跑成功过emmc的没,看datasheet只能通过sd相关引脚转,我自己焊了个tf接口转的emmc,windows,ubuntu都能正常读写,本以为能够像sd卡那样用起来,结果发现烧录,包括在内核当设备都不可用,用逻辑分析仪跟过,cmd0,cmd8后回复R7时,argument内部的vol电压和echo值全都是0,然后cmd0,cmd1回复R1时的card status的值为0x00ff8000,也不知道这是个什么状态,然后就再没相关反应咯!

#3 全志 SOC » f1c200s有在uboot阶段实现了i2c正常通信的没 » 2018-12-12 18:43:13

asdf
回复: 1

看了下twi0的base地址都配错了,配的是1c2c400;芯片手册是1c27000;

#4 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-12-12 18:39:12

官方sdk的uboot阶段又能i2c通信成功的没,我看twi0 base地址都是错的,有点方

#5 Re: 全志 SOC » f1c100s有人调过内存频率没 » 2018-12-11 16:40:05

正常上讲sysconfig优先级的确是高于dts,但是也不是所有配置都能生效,我记得dram是受其para下其它配置值共同影响的;这里可以确定是480没生效,更改dts有效,读取0x1c20020的值是0x90000c11,参照芯片手册算出来的确是312;我一直纳闷的是,看驱动clk一块设置也没什么别的为何就出现我只要改动dram频率就会出现偶尔起不起来的情况,卡在内核内存频率设置的时候,按道理软件不应该出现这种随机性吧感觉

晕哥 说:

不好意思, 看成 cpu 频率了.

https://blog.csdn.net/jklinux/article/details/82382066

... sys_config.fex就是全志传统的script.fex。 设备树的dtb文件是由dts文件和sys_config.fex文件组合生成. 而且sys_config.fex里的内容的优先级别比dts要高 ...


sysconfig 配 480M, 那应该会覆盖 sys_config.fex 的312M,
现在运行的速度是多少,你是怎么确定的?

asdf 说:

不是cpuy哦,是内存,sysconfig dram配的的确是480,312是设备树***clk.dtsi里面配置的

晕哥 说:

官方的 sys_config.fex 是 312Mhz ?
我怎么记得是 408Mhz

#6 Re: 全志 SOC » f1c100s有人调过内存频率没 » 2018-12-08 17:49:14

不是cpuy哦,是内存,sysconfig dram配的的确是480,312是设备树***clk.dtsi里面配置的

晕哥 说:

官方的 sys_config.fex 是 312Mhz ?
我怎么记得是 408Mhz

#7 Re: 全志 SOC » f1c100s能超频到多少呢? » 2018-12-06 09:41:22

是,挖坑官方sdk的确配的是528
/* register allwinner,sunxi-pll-clock */
        clk_pll_cpu: pll_cpu {
            #clock-cells = <0>;
            compatible = "allwinner,sunxi-pll-clock";
            lock-mode = "none";
            assigned-clock-rates = <528000000>;
            clock-output-names = "pll_cpu";
        };
可能我记混了,刚又从新跑了下,528频率也是匹配性能的,但是主线内核原始版本基本能肯定是超到816的了,整形性能比528高30%多,但是我没去读过寄存器

ippen 说:
asdf 说:

对比过几个sdk,挖坑社区官方sdk在sun3iwip1-clk.dtsi配置的的确是528,我没有改过,然后sysconfig配的408不确定是否生效,但实际性能我对比nano荔枝派基本是一致的,nano都说的是408,没看到何处去设置的只看到有个ccu相关的宏是11;然后我有个较新的官方sdk,配置到816才能持平nano和老官方sdk的性能,我总感觉nano和挖坑官方sdk实际主频应该都是816的,不知大家有何见解

可以肯定不是816,我是用直接读寄存器的方式获取数据,然后根据手册推算出来的,官方的sdk是528,4.19主线内核是408

#8 Re: 全志 SOC » f1c100s能超频到多少呢? » 2018-12-04 15:04:48

对比过几个sdk,挖坑社区官方sdk在sun3iwip1-clk.dtsi配置的的确是528,我没有改过,然后sysconfig配的408不确定是否生效,但实际性能我对比nano荔枝派基本是一致的,nano都说的是408,没看到何处去设置的只看到有个ccu相关的宏是11;然后我有个较新的官方sdk,配置到816才能持平nano和老官方sdk的性能,我总感觉nano和挖坑官方sdk实际主频应该都是816的,不知大家有何见解

#9 Re: 全志 SOC » f1c100s能超频到多少呢? » 2018-11-13 11:23:27

bsp这边有超频成功的没,sysconfig的配置对uboot有效,但kernel最大也就408M,再高直接就起不来了,可有什么方案没

#10 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-11-05 14:13:54

dts只有默认的156M才能启动,sys_config单纯调dram段下的clk也是不行的,可能能调但依全志一般都不会描述的

晕哥 说:
asdf 说:

@晕哥  bsp这边内存频率怎么调啊,只支持默认的156?cpu频率在dts调节生效,从276调到了408

应该是 sys_config.fex 里面调,dts是否能调不确定.

#11 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-11-05 13:39:25

@晕哥  bsp这边内存频率怎么调啊,只支持默认的156?cpu频率在dts调节生效,从276调到了408

#12 Re: 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-30 12:34:51

直接烧感觉不可控,新片子的话勾上格式化应该是没问题的,但我不确定更改类似分区或者多次烧录会不会再出什么意外咯~反正我是遇到了

晕哥 说:
asdf 说:

这个问题目前找到一个解决方案,首先下载assert大神改的uboot到dram,然后对nand flash 进行全盘擦除;然后再用最新的全志phonixsuuit,注意要勾上格式化烧录就可以了,不擦只加格式化是不行的,除非新片子,应该是烧录时分区处理的完善性问题了

直接用 phonixsuit 烧录 spi nand 不可以吗?

#13 Re: 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-30 11:44:58

这个问题目前找到一个解决方案,首先下载assert大神改的uboot到dram,然后对nand flash 进行全盘擦除;然后再用最新的全志phonixsuuit,注意要勾上格式化烧录就可以了,不擦只加格式化是不行的,除非新片子,应该是烧录时分区处理的完善性问题了

#14 Re: 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-29 18:33:35

好吧,多谢晕哥!我也搞不懂为啥到我这里又降了十多倍速度了,不知会不会是硬件原因啊?sd启动再烧录这个方法值得一试!

晕哥 说:
晕哥 说:
晕哥 说:

速度慢的问题我去请教原作者 @assert
kernel, dtb 的烧录可以用 u-boot的指令.

@assert 说 sunxi-fel 没有优化,是比较慢,有 4k-6k 左右的速度, 但是你的这么慢,就不知道是什么问题了。
只能自己重写 sunxi-fel 工具了.

出个歪主意, 从 TF 卡启动, 然后利用 linux 4.19 写 spi nand.

#15 Re: 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-29 16:46:54

59% [============================                    ]   0.3 kB/s, ETA 24:00 usb_bulk_send() ERROR -1: Input/Output Error

虽然龟速并且中途还报错了,但是好消息是连上串口上电居然能成功启动到uboot的命令行,也能操作!
那么问题来了:
一个是速度慢的问题,
二个是这种状态下的uboot我要怎么比较简便把dtb,kernel弄进来呢,还是直接用tftp

#16 Re: 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-29 16:03:28

嗯,从启动现象看已经初始化好了dram,正在尝试跳转,现在我在把整个uboot下进去,可是感人的速度
6% [==                                              ]   0.2 kB/s, ETA 80:03
这个可能是硬件影响或者其它原因,一脸懵逼~

晕哥 说:
asdf 说:

这个sunxi-fel工具我烧了个0x6000长度的spl,然后有两个问题,第一烧录速度极慢,0.2k左右;第二烧录到spinand数据排列有问题,我的芯片是GD5F1G的,通过从spinand反读回来跟原spl.bin对比,spinand里面是跳着写入的,前1024一样,1024-2048全为ff,2049开始又跟源文件的1025一样了,现象就是跳1024个字节,但是只有sunxi-fel的bin文件~~

boot0部分只用1024字节,读回的时候按正常方式读取。
1024字节是brom决定的。

#17 Re: 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-29 15:37:18

这个sunxi-fel工具我烧了个0x6000长度的spl,然后有两个问题,第一烧录速度极慢,0.2k左右;第二烧录到spinand数据排列有问题,我的芯片是GD5F1G的,通过从spinand反读回来跟原spl.bin对比,spinand里面是跳着写入的,前1024一样,1024-2048全为ff,2049开始又跟源文件的1025一样了,现象就是跳1024个字节,但是只有sunxi-fel的bin文件~~

#18 Re: 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-29 10:56:08

我刚好有块gd的nand,查看info对得上,话说我能直接用这个烧.img不晕哥,如果不行的话要弄整个系统大概怎么操作的呢~~

晕哥 说:

https://whycan.cn/files/members/3/QQ20181028160937.png

可以用这个 sunxi-fel, 支持 GD5F1G  spinand

#19 Re: 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-28 22:28:46

我还没去看有没代码,反正官方说的支持的

v3s 说:

全志官方提供的 uboot spi nand lib?

#20 Re: 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-28 22:27:16

好的,多谢晕哥,板子不在手头明天我试下

晕哥 说:

这个是主线 u-boot, 支持 spi nand, 出自大神 @assert

就看你能不能用起来

https://whycan.cn/t_1594.html

#21 Re: 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-28 13:22:29

kernel前的部分代码我得去看看有没有,还不确定是不是闭源的,话说你有成功稳定跑起过spi nand么,

cityf 说:

这个 linux 是什么版本? 4.19 已经内置支持了 spi nand了.

#22 Re: 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-28 13:19:44

我这还是3.10的,不过这个出问题的还在uboot阶段,还没到kernel的

cityf 说:

这个 linux 是什么版本? 4.19 已经内置支持了 spi nand了.

#23 全志 SOC » f1c100s官方bsp关于spi nand启动的问题 » 2018-10-28 11:56:08

asdf
回复: 24

我拿到一个f1c100s能用的spi nand的lib库,同样的板子,同样的包之前烧录并且运行好几次都没问题,都成功起到文件系统的,啥没改说烧录不进去就不进去了,我跟踪了部分关键打印,初始化都成功但一到要下载写入就gg了,有大佬能帮忙分析下可能的原因不,硬件电路确认过,奇怪的是前后软硬都没变怎么就不行了,会有可能影响到了哪个关键寄存器值?

NAND_UbootInit
[1.443]NAND_UbootInit start
[1.445]NB1: enter NAND_LogicInit
[1.448]SpiNandHwInit: Start Nand Hardware initializing .....
[1.454]uboot: nand version: 3 6006 20180504 1300
int sunxi_dma_init---
irq enable
[1.473]uboot nand_request_tx_dma: reqest genernal dma for nand success, 0x83eb8b94
[1.480]uboot nand_request_tx_dma: reqest genernal dma for nand success, 0x83eb8bb4
_get_spic_clk_v1: sclk0=0x64
[1.510]not burn nand partition table!
[1.514][ND]not enough block:479,878!!
[1.517][NE]build phy partition 0 error!
[1.521][NE]build all phy partition fail!
[1.729][NE]not find mbr table!!!!
[1.732]NB1: nand_info_init fail
[1.735]NAND_UbootInit end: 0xfffffffb
NAND_UbootExit
[1.740]NB1: NAND_LogicExit
nand release dma:83eb8b94
nand release dma:0
sunxi dma exit
[1.748]erase_flag = 1
[1.750]NB1 : enter phy init
[1.753]SpiNandHwInit: Start Nand Hardware initializing .....
[1.758]uboot: nand version: 3 6006 20180504 1300
int sunxi_dma_init---
irq enable
[1.778]uboot nand_request_tx_dma: reqest genernal dma for nand success, 0x83eb8b94
[1.785]uboot nand_request_tx_dma: reqest genernal dma for nand success, 0x83eb8bb4
_get_spic_clk_v1: sclk0=0x64
[1.815]NB1 : nand phy init ok
[1.818]erase by flag 1
[1.820]has cleared the boot blocks.
[1.917]erase block128
[2.086]erase block256
[2.256]erase block384
[2.425]erase block512
[2.595]erase block640
[2.765]erase block768
[2.934]erase block896
[3.102]NAND_Uboot_Erase
[3.104]NB1 : enter phy Exit
nand release dma:83eb8b94
nand release dma:0
sunxi dma exit
[3.112]successed in erasing flash
NAND_UbootInit
[3.117]NAND_UbootInit start
[3.120]NB1: enter NAND_LogicInit
[3.123]SpiNandHwInit: Start Nand Hardware initializing .....
[3.128]uboot: nand version: 3 6006 20180504 1300
[3.144]request spi gpio  ok!
int sunxi_dma_init---
irq enable
[3.150]uboot nand_request_tx_dma: reqest genernal dma for nand success, 0x83eb8b94
[3.157]request general tx dma channel ok!
[3.161]uboot nand_request_tx_dma: reqest genernal dma for nand success, 0x83eb8bb4
[3.169]request general rx dma channel ok!
[3.172]SPI nand ID: 12c212c2 12c212c2
[3.176][SCAN_DBG] NandTwoPlaneOp: 1, DriverTwoPlaneOPCfg: 1, 0xffcfffff
[3.182]nand : get id number_ctl from script:0x55aaaa55
[3.187]_UpdateExtAccessFreqPara: no para.
[3.191]PHY_Scan_DelayMode: right delay mode 0x0
[3.196]PHY_Scan_DelayMode: right delay mode 0x800
_get_spic_clk_v1: sclk0=0x64
[3.203]PHY_Scan_DelayMode: right delay mode,clk 50 MHz, bit[13]=0,bit[11]=0
[3.209]physic_info_read start!!
[3.212]physic_info_read already!!
[3.215]

[3.216][SCAN_DBG] ==============Nand Architecture Parameter==============
[3.223][SCAN_DBG]    Nand Chip ID:         0xffff12c2 0xffffffff
[3.229][SCAN_DBG]    Nand Chip Count:      0x1
[3.233][SCAN_DBG]    Nand Chip Connect:    0x1
[3.237][SCAN_DBG]    Sector Count Of Page: 0x4
[3.241][SCAN_DBG]    Page Count Of Block:  0x40
[3.246][SCAN_DBG]    Block Count Of Die:   0x400
[3.250][SCAN_DBG]    Plane Count Of Die:   0x1
[3.254][SCAN_DBG]    Die Count Of Chip:    0x1
[3.259][SCAN_DBG]    Bank Count Of Chip:   0x1
[3.263][SCAN_DBG]    Optional Operation:   0x60
[3.267][SCAN_DBG]    Access Frequence:     0x0
[3.271][SCAN_DBG] =======================================================

[3.298]secure storage updata ok!
[3.301]nand secure storage ok: 58,59
[3.304]nand: get CapacityLevel from script, 55aaaa55
[3.309]burn nand partition table! mbr tbl: 0x83eebcc4, part_count:9
[3.315]start block:60
[3.317][ND]factory FirstBuild 66
[3.320]PHY_PageReadSpare bad flag: bank 0x0  block 0x45  page 0x1
[3.326]PHY_PageReadSpare bad flag: bank 0x0  block 0x45  page 0x0
[3.332][PHY_DBG] Find a bad block (NO. 0x45) in the Die 0x0
[3.337]PHY_PageReadSpare bad flag: bank 0x0  block 0x46  page 0x1
[3.343]PHY_PageReadSpare bad flag: bank 0x0  block 0x46  page 0x0
[3.349][PHY_DBG] Find a bad block (NO. 0x46) in the Die 0x0
[3.355]PHY_PageReadSpare bad flag: bank 0x0  block 0x47  page 0x1
[3.361]PHY_PageReadSpare bad flag: bank 0x0  block 0x47  page 0x0

#24 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-24 13:22:33

你们用这种方法烧到卡上能启动不?需要怎样地额外配置才行呢

ippen 说:
晕哥 说:
ippen 说:

我记得好像用phoenixsuit ,如果没有spiflash,会选择mmc卡,不过不知道为啥今天phoenixsuit用不了,一直超时

接上串口,可以看到log的, 通过usb把 u-boot下载到 dram里面跑,然后通过u-boot烧写的。

家里的电脑上的phoenixsuit可以烧,可以明确的是,如果没有spiflash,会烧到sd卡上

#25 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-22 10:58:42

我也是再看,刚刚对比了打包时候地终端打印信息,文件系统操作看来跟这个没关系,在do_finish的那个函数,并且我看在配置dragonboard 平台时他直接只链接了roofs.ext4,说不定是可以打进去的,我没试的还

basicdev 说:
asdf 说:

实际操作函数如下

function do_pack_linux()
{
    printf "packing for linux\n"

    ln -s ${LICHEE_OUT}/vmlinux.tar.bz2 vmlinux.fex
    ln -s ${LICHEE_OUT}/boot.img        boot.fex
    ln -s ${LICHEE_OUT}/rootfs.ext4     rootfs.fex

    # Those files is ready for SPINor.
    ln -s ${LICHEE_OUT}/uImage          kernel.fex
    ln -s ${LICHEE_OUT}/rootfs.squashfs rootfs_squashfs.fex

    if [ "x${PACK_SIG}" = "xsecure" ] ; then
        do_signature
    else
        echo "normal"
    fi 
}

这个是pack 命令后面跟的参数不同吧?

#26 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-22 10:34:02

实际操作函数如下

function do_pack_linux()
{
    printf "packing for linux\n"

    ln -s ${LICHEE_OUT}/vmlinux.tar.bz2 vmlinux.fex
    ln -s ${LICHEE_OUT}/boot.img        boot.fex
    ln -s ${LICHEE_OUT}/rootfs.ext4     rootfs.fex

    # Those files is ready for SPINor.
    ln -s ${LICHEE_OUT}/uImage          kernel.fex
    ln -s ${LICHEE_OUT}/rootfs.squashfs rootfs_squashfs.fex

    if [ "x${PACK_SIG}" = "xsecure" ] ; then
        do_signature
    else
        echo "normal"
    fi 
}

#27 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-22 10:27:25

pack会刷新 c600/tools/pack/out 下的一堆文件,其中文件系统相关的这两个链接:

rootfs.fex -> /home/xxx/c600/out/sunivw1p1/linux/common/rootfs.ext4
rootfs_squashfs.fex -> /home/xxx/c600/out/sunivw1p1/linux/common/rootfs.squashfs

我尝试替换过rootfs.squashfs,登录之后验证是可行地,但替换rootfs.ext4则不生效,在tools/pack/下的pack脚本没有直接看到相关地文件操作,只有上面这两句链接,但是我猜想全志应该是把这套实现好了地,有可能在他哪个闭源地工具里面,有兴趣地朋友一起来研究研究

#28 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-22 10:05:52

刚周末浪回来,不知各位sd验证得如何咯,你们有没有尝试在烧录img之后不再额外dd文件系统地方法,就是pack的时候直接把自己做的ext4文件系统打进img烧录包的,这样会方便很多,这个估计得琢磨下bsp的那一套逻辑

#29 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-10-19 14:59:10

现象基本一致,回头详细看看

lilo 说:

https://blog.csdn.net/chenyu105/article/details/9749549
本文记录一次内核模块内存越界,导致故障的排查分析过程,和各位共享交流。

#30 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-10-19 14:18:40

路过的有使用过显示的没有,我运行qt程序的时候会出现类似Bad page state的问题,我的显示屏是800x480的,总感觉可能还是哪里没有配置正确,随机矩形可以正确绘制的

[  104.541476] BUG: Bad page state in process syslogd  pfn:81c26
[  104.547844] page:c05184c0 count:0 mapcount:0 mapping:  (null) index:0x2
[  104.555200] page flags: 0x200(arch_1)
[  104.559261] Modules linked in:
[  104.562698] CPU: 0 PID: 53 Comm: syslogd Tainted: G    B        3.10.65 #20
[  104.570431] Backtrace:
[  104.573186] [<c00134a0>] (dump_backtrace+0x0/0x110) from [<c0013640>] (show_stack+0x18/0x1c)
[  104.582570]  r6:c05704f0 r5:c04cf224 r4:c05184c0 r3:00400000
[  104.588887] [<c0013628>] (show_stack+0x0/0x1c) from [<c033f7f8>] (dump_stack+0x20/0x28)
[  104.597812] [<c033f7d8>] (dump_stack+0x0/0x28) from [<c00672b8>] (bad_page+0xdc/0x10c)
[  104.606644] [<c00671dc>] (bad_page+0x0/0x10c) from [<c006829c>] (get_page_from_freelist+0x378/0x4b0)
[  104.616784]  r5:c04c47a8 r4:00000000
[  104.620820] [<c0067f24>] (get_page_from_freelist+0x0/0x4b0) from [<c00684c8>] (__alloc_pages_nodemask+0xf4/0x614)
[  104.632238] [<c00683d4>] (__alloc_pages_nodemask+0x0/0x614) from [<c0072fc4>] (shmem_getpage_gfp+0x2a8/0x5f0)
[  104.643268] [<c0072d1c>] (shmem_getpage_gfp+0x0/0x5f0) from [<c00733b0>] (shmem_write_begin+0x40/0x48)
[  104.653643] [<c0073370>] (shmem_write_begin+0x0/0x48) from [<c0061914>] (generic_file_buffered_write+0xe0/0x23c)
[  104.664993] [<c0061834>] (generic_file_buffered_write+0x0/0x23c) from [<c006330c>] (__generic_file_aio_write+0x31c/0x35c)
[  104.677192] [<c0062ff0>] (__generic_file_aio_write+0x0/0x35c) from [<c00633ac>] (generic_file_aio_write+0x60/0xc0)
[  104.688709] [<c006334c>] (generic_file_aio_write+0x0/0xc0) from [<c0091084>] (do_sync_write+0x7c/0xa0)
[  104.699075] [<c0091008>] (do_sync_write+0x0/0xa0) from [<c0091978>] (vfs_write+0xe0/0x18c)
[  104.708257]  r7:c3a77f78 r6:01020478 r5:0000008b r4:c3aa7140
[  104.714608] [<c0091898>] (vfs_write+0x0/0x18c) from [<c0091d58>] (SyS_write+0x48/0x70)
[  104.723440] [<c0091d10>] (SyS_write+0x0/0x70) from [<c000f8a0>] (ret_fast_syscall+0x0/0x2c)
[  104.732729] BUG: Bad page state in process syslogd  pfn:81c27
[  104.739098] page:c05184e0 count:0 mapcount:0 mapping:  (null) index:0x2
[  104.746453] page flags: 0x200(arch_1)
[  104.750547] Modules linked in:
[  104.753963] CPU: 0 PID: 53 Comm: syslogd Tainted: G    B        3.10.65 #20
[  104.761701] Backtrace:
[  104.764461] [<c00134a0>] (dump_backtrace+0x0/0x110) from [<c0013640>] (show_stack+0x18/0x1c)

#31 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-19 10:13:59

应该是的吧,全志那一套pack 机制多繁杂的,反正我看nor和常规linux mmc分区都有使用到的,nor的roofs是在里面的,mmc的应该是没有但框架建好了的

晕哥 说:

PhoenixCard_V310_20130618 这个我有,原理是藏了多个 rootfs 到 img 文件吗?

#32 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-19 09:17:37

PhoenixCard_V310_20130618   这个软件你们没用过?专门烧sd的,不是用phoenixsuit哦

#33 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-19 09:15:34

对的,spi 和sd都是可以烧录的,我是分别各用的一个烧录软件,都是全志官方的,ext4文件系统是缺失的,要自己dd

basicdev 说:
ippen 说:
晕哥 说:

接上串口,可以看到log的, 通过usb把 u-boot下载到 dram里面跑,然后通过u-boot烧写的。

家里的电脑上的phoenixsuit可以烧,可以明确的是,如果没有spiflash,会烧到sd卡上

那打包的img文件里面有至少两个根文件系统 squadfs和ext4?
发现是哪种介质就用哪个文件系统?

#34 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-18 18:13:40

文件系统只读的解决办法找到,首先要在内核配置block layer那儿打开2TB+那个选项,然后再进入shell后最开始还是只读的,需要从新挂载下就可以了,mount -o remount,rw /dev/root /  但是我fstab明明指定的rw为何不生效呢

#35 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-18 18:02:41

这个是windows的工具,直接用读卡器就可以了,选卡启动,先恢复再烧录即可

晕哥 说:
asdf 说:

对,要用全志的phoenixcard工具烧录的,

晕哥 说:

上面这个是烧到 TF 卡的 固件?

请教如何配置,才会烧到TF卡,默认是烧到 spi flash 吧?

#36 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-18 17:42:51

对,要用全志的phoenixcard工具烧录的,

晕哥 说:
asdf 说:

注意我把内核debug串口调到PE0,PE1的

上面这个是烧到 TF 卡的 固件?

#37 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-18 17:36:50

注意我把内核debug串口调到PE0,PE1的

#38 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-18 17:33:02

已发!
mount查看/是ro状态
# mount
rootfs on / type rootfs (rw)
/dev/root on / type ext4 (ro,relatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=28548k,nr_inodes=7137,mode=755)
proc on /proc type proc (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=666)
tmpfs on /dev/shm type tmpfs (rw,relatime,mode=777)
tmpfs on /tmp type tmpfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
sysfs on /sys type sysfs (rw,relatime)

晕哥 说:
asdf 说:

玩不转,文件上传不了,邮箱只能发字,:(

发我邮箱吧,我传上来.  516333132@qq.com

#39 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-18 17:29:37

已发!

ippen 说:
asdf 说:

@ippen,传了几次不成功,我发你邮箱吧

邮箱: 85572144@qq.com ,谢谢

#40 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-18 17:07:52

玩不转,文件上传不了,邮箱只能发字,:(

#41 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-18 16:54:23

@ippen,传了几次不成功,我发你邮箱吧

#42 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-18 16:53:02

制作的sd卡img不带rootfs要自己再dd,目前还有个问题,挂载的文件系统是readonly的,按照提示打开内核LBDAF配置无效,我在env加rw又会识别不了文件系统,路过大神支个招

#43 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-18 15:24:33

这问题昨天已经结了,记录下给路过的朋友填下坑,问题其实也就出在文件系统的正确性和存在性上,第一之前我配的ramfs并没有对,导致内核崩溃,之后直接取消了反而发现能挂了只是像7楼上的没找到文件系统,只认到了分区;基于这个问题跑去折腾全志的pack一通,基本确定就是pack出来的.img里面其实根本就没有对应的rootfs,所以在制作sd启动卡的时候自然对应位置就没有了,所以会找不到,中途冒了一些分区的离奇问题,最后通过做sd卡启动包后再自己制作个ext4的文件系统直接dd进sd卡的对应分区,成功挂载

#44 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-16 15:22:02

@晕哥 我的spi和sd在两个板子上焊坏了没办法,不过我把initramfs配置取消后反而离成功更近了感觉
[    1.345576] sunxi-mmc 1c0f000.sdmmc: sdc set ios: clk 50000000Hz bm PP pm ON vdd 16 width 4 timing SD-HS(SDR25) dt B
[    1.357506] mmc0: new high speed SDHC card at address 0001
[    1.364701] mmcblk0: mmc0:0001 SD8GB 7.27 GiB
[    1.372059]  mmcblk0: p1 p2 p3 < p5 p6 p7 >
[    1.815649] BSP_disp_layer_set_para: fb_format=0x0, yuv_ch=0
[    1.864539] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    1.875270] List of all partitions:
[    1.879260] b300         7632384 mmcblk0  driver: mmcblk
[    1.885349]   b301         6955519 mmcblk0p1 00000000-01
[    1.891315]   b302           32768 mmcblk0p2 00000000-02
[    1.897356]   b303               1 mmcblk0p3
[    1.902234]   b305           16384 mmcblk0p5 00000000-05
[    1.908233]   b306           65536 mmcblk0p6 00000000-06
[    1.914223]   b307          524288 mmcblk0p7 00000000-07
[    1.920149] No filesystem could mount root, tried:  ext4
[    1.926151] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,7)
[    1.935543] Rebooting in 5 seconds..


我看bsp这边虽然可以通过那个out下的target来替换文件系统,但最后都通过工具做成了.fex在downloaod到板子,这里的文件系统格式什么的是不是不匹配呢

#45 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-16 14:02:12

  │ │                                [-] Initial RAM filesystem and RAM disk (initramfs/initrd) support                                   │ │  
  │ │                              (/home/mengh/work-sdk/allwinner/c600/linux-3.10/rootfs_32bit.cpio.gz) Initramfs source file(s)       │ │  
  │ │                              (0)     User ID to map to 0 (user root)                                                              │ │  
  │ │                              (0)     Group ID to map to 0 (group root)                                                            │ │  
  │ │                              [-]   Support initial ramdisks compressed using gzip                                                 │ │  
  │ │                              [ ]   Support initial ramdisks compressed using bzip2                                                │ │  
  │ │                              [ ]   Support initial ramdisks compressed using LZMA                                                 │ │  
  │ │                              [ ]   Support initial ramdisks compressed using XZ                                                   │ │  
  │ │                              [ ]   Support initial ramdisks compressed using LZO                                                  │ │  
  │ │                                    Built-in initramfs compression mode (Gzip)  --->                                               │ │  
  │ │                              [-] Optimize for size                                       

我像这样配置的,啥反应都没了~~

之前用的naka的配置:bootargs=earlyprintk console=tty0 console=ttyS0,115200 panic=5 rootwait rootfstype=ext4 root=/dev/mmcblk0p2 rw rootflags=noload init=/linuxrc
这个在spi上是可以直接跑到shell的,一样的文件系统

晕哥 说:

把根文件系统放 spi flash上, 或者用 initramfs, 启动后看能否能挂载 TF 卡的根文件系统:

mount /dev/mmcXXX /mnt/YYY

参考: http://ilinuxkernel.com/?p=2061

#46 Re: 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-16 11:28:10

[    2.081852] mmc0: host does not support reading read-only switch. assuming write-enable.这个我在内核配置始终没找到相关能配读写的地方,把ext系列文件系统支持添上也没用

#47 全志 SOC » nano关于bsp这边sd卡启动的问题 » 2018-10-16 11:23:32

asdf
回复: 40

看过本站nakanoyip关于使用bsp的dtb和zimage替换荔枝派主线sd卡启动成功,由于信息不全仍旧没能走通;
然后我直接采用了全志官方的一套配置了sd驱动,制作出.img包用PhoenixCard软件制作卡启动包发现能够成功跑到kernel的末尾段,对比应该就在挂载文件系统前后崩掉,已经成功识别sd卡,路过大神可有方案
部分打印如下
[    1.763009] sunxi-mmc 1c0f000.sdmmc: SD/MMC/SDIO Host Controller Driver(v0.30 2015-10-10 10:03) C9
[    1.776484] sunxi-mmc 1c0f000.sdmmc: Can't get vmmc regulator string
[    1.783543] sunxi-mmc 1c0f000.sdmmc: Can't get vqmmc regulator string
[    1.790772] sunxi-mmc 1c0f000.sdmmc: Can't get vdmmc regulator string
[    1.797971] sunxi-mmc 1c0f000.sdmmc: Failed getting OCR mask: 0
[    1.805228] sunxi-mmc 1c0f000.sdmmc: *******************set host ocr**************************
[    1.815323] sunxi-mmc 1c0f000.sdmmc: sdc set ios: clk 0Hz bm PP pm UP vdd 21 width 1 timing LEGACB
[    1.844334] sunxi-mmc 1c0f000.sdmmc: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing B
[    1.874419] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[    1.880606] hub 1-0:1.0: hub_suspend
[    1.884888] sunxi-mmc 1c0f000.sdmmc: base:0xf1c0f000 irq:106
[    1.891200] sunxi-mmc 1c0f000.sdmmc: smc 0 p0 err, cmd 52, RTO !!
[    1.898138] usb usb1: bus auto-suspend, wakeup 1
[    1.903299] sunxi-mmc 1c0f000.sdmmc: smc 0 p0 err, cmd 52, RTO !!
[    1.910197] sunxi-mmc 1c0f000.sdmmc: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing B
[    1.922668] usbcore: registered new interface driver usbhid
[    1.928944] usbhid: USB HID core driver
[    1.936110] sunxi-mmc 1c0f000.sdmmc: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing B
[    1.948146] TCP: cubic registered
[    1.951830] Initializing XFRM netlink socket
[    1.956706] NET: Registered protocol family 17
[    1.961941] VFP support v0.3: not present
[    1.968901] sunxi-mmc 1c0f000.sdmmc: smc 0 p0 err, cmd 5, RTO !!
[    1.976227] [LCD]
[    1.978337] sunxi-mmc 1c0f000.sdmmc: smc 0 p0 err, cmd 5, RTO !!
[    1.985305] lcd_module_init
[    1.989586] sunxi-mmc 1c0f000.sdmmc: smc 0 p0 err, cmd 5, RTO !!
[    2.008727] sunxi-mmc 1c0f000.sdmmc: smc 0 p0 err, cmd 5, RTO !!
[    2.018623] sunxi-mmc 1c0f000.sdmmc: sdc set ios: clk 400000Hz bm PP pm ON vdd 16 width 1 timing B
[    2.033918] sunxi-mmc 1c0f000.sdmmc: sdc set ios: clk 400000Hz bm PP pm ON vdd 16 width 1 timing B
[    2.048174] sunxi-mmc 1c0f000.sdmmc: sdc set ios: clk 400000Hz bm PP pm ON vdd 16 width 1 timing B
[    2.081852] mmc0: host does not support reading read-only switch. assuming write-enable.
[    2.092831] sunxi-mmc 1c0f000.sdmmc: sdc set ios: clk 400000Hz bm PP pm ON vdd 16 width 1 timing B
[    2.104495] sunxi-mmc 1c0f000.sdmmc: sdc set ios: clk 50000000Hz bm PP pm ON vdd 16 width 1 timinB
[    2.116441] sunxi-mmc 1c0f000.sdmmc: sdc set ios: clk 50000000Hz bm PP pm ON vdd 16 width 4 timinB
[    2.128258] mmc0: new high speed SDHC card at address 0001
[    2.135393] mmcblk0: mmc0:0001 SD8GB 7.27 GiB
[    2.142617]  mmcblk0: p1 p2 p3 < p5 p6 p7 >
[    2.586863] BSP_disp_layer_set_para: fb_format=0x0, yuv_ch=0
[    2.635653] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    2.643067] async_waiting @ 1
[    2.646498] async_continuing @ 1 after 2 usec
[    2.651832] Freeing unused kernel memory: 124K (c04a3000 - c04c2000)
[    2.689194] Unable to handle kernel paging request at virtual address 001f001b
[    2.697336] pgd = c1494000
[    2.700340] [001f001b] *pgd=81484831, *pte=00000000, *ppte=00000000
[    2.707374] Internal error: Oops: 1 [#1] ARM
[    2.712096] Modules linked in:
[    2.715495] CPU: 0 PID: 38 Comm: mount Not tainted 3.10.65 #28
[    2.721957] task: c16b22a0 ti: c1486000 task.ti: c1486000
[    2.727959] PC is at __d_lookup_rcu+0x58/0x11c
[    2.732897] LR is at lookup_fast+0x44/0x26c
[    2.737536] pc : [<c00a45a0>]    lr : [<c009ad88>]    psr: 20000013
[    2.737536] sp : c1487da0  ip : c1487de8  fp : c1487de4
[    2.750242] r10: c1487dec  r9 : 00000003  r8 : 002968b1
[    2.756025] r7 : c1487eb8  r6 : c1401088  r5 : 001f001f  r4 : 001f0017
[    2.763248] r3 : 001f001f  r2 : 001f001f  r1 : 00000014  r0 : c1401088
[    2.770475] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[    2.778371] Control: 0005317f  Table: 81494000  DAC: 00000015
[    2.784728]
[    2.784728] PC: 0xc00a4520:
[    2.789451] 4520  e1a01000 e50b0020 e1a00005 ebffd556 e24b1014 e5210010 e1a00004 ebffffda
[    2.798547] 4540  e24bd014 e89da830 e1a0c00d e92ddff0 e24cb004 e24dd01c e50b3038 e5913008
[    2.807642] 4560  e1c180d0 e1a07001 e59f10ec e1a0a002 e50b3030 e08822a0 e59f30e0 e0020291
[    2.816738] 4580  e5931004 e5933000 e2611020 e1a02132 e1a06000 e7935102 e50b9034 ea000027
[    2.825829] 45a0  e5943004 e5942010 e1520006 1a000022 e594200c e3520000 0a00001f e3c33001
[    2.834922] 45c0  e58a3000 e5962000 e3120002 0a00000c e5942018 e1520008 1a000017 e1a00006
[    2.844013] 45e0  e51b1038 e1a02004 e58d7000 ebfff982 e3500000 0a000015 e3500001 1affffe7
[    2.853101] 4600  ea00000d e1c421d8 e1530009 01520008 1a000009 e5941020 e51b2030 e51b3034
[    2.862199]
[    2.862199] LR: 0xc009ad08:
[    2.866920] ad08  e24bd018 e89da870 e1a0c00d e92dd830 e24cb004 e1a04000 e1a05001 e5900004
[    2.876006] ad28  eb0023e3 e5940000 e5953000 e1500003 089da830 eb003cdf e89da830 e1a0c00d
[    2.885100] ad48  e92ddff0 e24cb004 e24dd00c e5903024 e1a05001 e3130040 e1a04000 e1a07002
[    2.894186] ad68  e590a000 e5906004 e2801008 0a000051 e1a00006 e24b2030 e5943020 eb0025ef
[    2.903276] ad88  e2508000 0a000041 e5983028 e5873000 e51b3030 e5982004 e1520003 1a000075
[    2.912368] ada8  e5962004 e5943028 e1520003 1a000071 e51b3030 e5843028 e5983000 e3130004
[    2.921456] adc8  03a06001 0a000009 e5983058 e5941024 e5933000 e12fff33 e2506000 ca000003
[    2.930549] ade8  e376000a 13a09000 03a09001 ea00002b e585a000 e5858004 e5950004 e5903000
[    2.939638]
[    2.939638] SP: 0xc1487d20:
[    2.944360] 7d20  000200da c05614f0 c1487d9c c1487d38 c1487d5c c00a45a0 20000013 ffffffff
[    2.953449] 7d40  c1487d8c 002968b1 c1487de4 c1487d58 c000f538 c000a1a0 c1401088 00000014
[    2.962540] 7d60  001f001f 001f001f 001f0017 001f001f c1401088 c1487eb8 002968b1 00000003
[    2.971628] 7d80  c1487dec c1487de4 c1487de8 c1487da0 c009ad88 c00a45a0 20000013 ffffffff
[    2.980717] 7da0  c1487dbc c1487db0 c009b210 c1400128 00000003 c181b011 c009b270 c1487eb0
[    2.989807] 7dc0  c1487e30 c1401088 c1487e38 c16ddca0 00000000 c18200b0 c1487e1c c1487de8
[    2.998899] 7de0  c009ad88 c00a4558 c009bb80 c003f974 c148c264 c1487eb0 00000041 c181b010
[    3.007987] 7e00  00000051 c16ddca0 00000000 00000000 c1487e5c c1487e20 c009be90 c009ad54

#48 Re: 全志 SOC » @assert 大神移植全志官方f1c100s linux bsp 到licheepi nano » 2018-10-12 16:44:20

naka兄,你这中间改了哪里了呢,我也遇到同样的问题了~

nakanoyip 说:

暈哥, 現在可以開到 Kernel 了, 但另一個問題是 TF Card 不能讀到,  所以 mount 不到 root
我在 SPI boot 或者 TF Boot, uboot 裡都可以用 mmc 0:1 去讀到 zImage 和 dtb 上 ram , 也可以 boot 到 kernel

用 SPI boot 進去 spi 的 root 後, 查到 /dev 有
mtd0, mtd1, mtd2, mtd3
mtd0ro, mtd1ro, mtd2ro, mtd3ro
mtdblock0, mtdblock1, mtdblock2, mtdblock3
但全都 mount 不起,  應該是 Kernel 的問題 , 知道那裡可以修改嗎 ?

#49 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-10-10 16:57:08

uart0可以用了,sys_config里面全志这边貌似有点坑,像我上面那么改他不认,我尝试把port1设置成PE1,PE0两个引脚,然后debug port还是选1,再把port0设置成PA3,PA2,不过我把port0关了,成功在内核阶段使用;有个地方,inittab从ttyS1改成ttyS0我的rootfs只读不生效,我觉得如果这里能改的话应该直接就可以了,话说为啥我挂载的rootfs是readonly啊,不能操作文件

#51 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-10-10 15:29:28

就sys_config的uart_para段把debug port设置成0;再把对应的管脚改成PE1,PE0

晕哥 说:
asdf 说:

话说默认debug串口为uart1,改成uart0后直接烧录都不成功,可有什么好的方案呢,有人实现uart0 debug了么

你是如何改的呢?应该不存在烧录不成功的问题.

#52 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-10-10 15:12:25

话说默认debug串口为uart1,改成uart0后直接烧录都不成功,可有什么好的方案呢,有人实现uart0 debug了么

#53 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-10-10 11:23:23

软切的话在/sys/devices/soc.0/usbc0.2/otg_role 这个文件,只需要echo usb_host 或者usb_devices就可以了,数字0,1,2应该也可以的

晕哥 说:
asdf 说:

otg软切目前倒是可用的,话说原理图上没有看到id脚呢

晕哥 说:

恭喜恭喜!
然后组织给你摊派一个重要的任务,
把OTG切换的功能调通.

^_^

请教如何操作?

#54 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-10-09 18:20:01

otg软切目前倒是可用的,话说原理图上没有看到id脚呢

晕哥 说:

恭喜恭喜!
然后组织给你摊派一个重要的任务,
把OTG切换的功能调通.

^_^

#55 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-10-09 16:51:11

终于把显示demo随机矩形跑起来了,特别感谢晕哥提供的.config,sys_config也可参照晕哥的,虽然晕哥强调那几个我都配了但可能还是其它一些未知的配置影响了;然后也给后面调试的朋友再指出两个可能遇到的坑,1.显示的PD7管脚跟daudio模块的管脚有冲突,可以在sunivw1p1.dtsi相关位置屏蔽;2.如果自己设计走线注意lcd_power管脚的正确性和开关逻辑!   目前usb主从显示都通了,接下来再把触摸,串口调通~

#57 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-10-08 18:13:42

我替换了sys_config也没出fb0,配置了一通多了个disp设备,晕哥有时间可否分享下你的.config,不行我再清理干净从新走一遍看看~

#58 Re: 全志 SOC » 【2】step by step 编译全志 f1c100s 官方linux bsp (重建文件系统已经搞定,详见5楼) » 2018-10-08 15:41:22

我按照流程最后运行fb-test-rect的时候才发现没有fb0设备,去内核打开了fb相关配置还是出不来,sys_config文件也打开了lcd0的

页脚

工信部备案:粤ICP备20025096号 Powered by FluxBB

感谢为中文互联网持续输出优质内容的各位老铁们。 QQ: 516333132, 微信(wechat): whycan_cn (哇酷网/挖坑网/填坑网) service@whycan.cn