XAF之Servermode注意

本文探讨了ListView在使用GridControl并处于Server模式时的LoadOnNeed策略,解释了这种模式下无法遍历全部数据的原因,并提出了只允许遍历当前可见数据的解决方案。

                当ListView使用GridControl,且工作在Server模式下时,执行的是一种Load on need策略,故无法对ListView的数据进行遍历,因为ListView当前仅加载了可见的这部分数据,若遍历数据如浏览listView.CollectionSource.List时,会抛出NotSupportedException。

               此时只能进行局部遍历,利用GridView浏览可见的这部分数据项。

              另外,目前XAF的servermode暂时不支持ChartListView。

>> sf erase customer _spi_flash_erase: addr 0xaf0000, len 0x500000 Erasing at 0xff0000 -- 100% complete.(cost 68 ms) SF: 5242880 bytes @ 0xaf0000 Erased: OK >> tftp 0x21000000 customer.jffs2 Using sstar_emac device TFTP from server 192.168.137.1; our IP address is 192.168.137.2 Filename 'customer.jffs2'. Load address: 0x21000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################# 6.1 MiB/s done Bytes transferred = 5242880 (500000 hex) >> sf write 0x21000000 customer ${filesize} device 0 offset 0xaf0000, size 0x500000 _spi_flash_write to 0xaf0000, len 0x500000 from 0x21000000 Writing at 0xff0000 -- 100% complete.(cost 2303 ms) SF: 5242880 bytes @ 0xaf0000 Written: OK show speed: 2213 KiB/s >> estar scripts/set_config Using sstar_emac device TFTP from server 192.168.137.1; our IP address is 192.168.137.2 Filename 'scripts/set_config'. Load address: 0x21000000 Loading: # 6.8 KiB/s done Bytes transferred = 424 (1a8 hex) >> setenv bootargs console=ttyS0,115200n8r root=/dev/mtdblock3 ro init=/linuxrc LX_MEM=0x8000000 mma_heap=mma_heap_name0,miu=0,sz=0x4000000 mma_memblock_remove=1 cma=2M mtdparts=${mtdparts} nohz=off >> setenv bootcmd ' dcache on; sf probe 0; loados nor 0x22000000 KERNEL by_header; bootm 0x22000000; >> setenv overdrive 3 >> saveenv Saving Environment to SPIFlash... Erasing SPI flash..._spi_flash_erase: addr 0x4f000, len 0x1000 Erasing at 0x50000 -- 100% complete.(cost 3 ms) Writing to SPI flash..._spi_flash_write to 0x4f000, len 0x1000 from 0x27639ad8 Writing at 0x50000 -- 100% complete.(cost 51 ms) done OK >> reset resetting ... E:CD IPL g0815cea D-0 BIST-128MB: OK IPL_CUST g0815cea D-0 U-Boot 2021.10 (Aug 29 2025 - 11:49:41 +0800) SoC: SigmaStar iford Model: IFORD Version: I###g7a33163 DRAM: 126 MiB WDT: Not found! Flash: SPI 54M [FLASH] Device id is 0xa1 0x40 0x18 [SPINOR] ReadData = 0x6b [SPINOR] Dummy = 0x8 [SPINOR] pageProgram = 0x2 [FLASH] BDMA mode [SPINOR] complement = 0x0 [SPINOR] top/buttom = 0x0 [SPINOR] blocks = 0x0 [SPINOR] SRP0 = 0x0 [SPINOR] SRP1 = 0x0 [FLASH] End flash init. spi clk already initialized mtd .name = nor0, .size = 0x01000000 (16MiB) .erasesize = 0x00001000 . Detected nor0 with total size 16 MiB 16 MiB estar完成了吗
最新发布
09-23
<think>好的,我现在需要分析用户提供的U-Boot日志,判断是否成功完成了烧录过程。用户执行了多个命令,包括擦除SPI Flash、通过TFTP下载文件、写入Flash,最后保存环境变量并重启。现在需要确认是否所有步骤都成功完成,以及系统是否正常启动。 首先,我会逐条检查用户执行的命令及其输出结果。用户首先执行了`sf erase customer`,系统返回了擦除成功的消息,地址范围正确,没有错误提示。接下来是`sf write`命令,写入了5242880字节,同样显示成功。然后用户通过`tftp`下载了`scripts/set_config`,虽然文件较小,但传输也完成了。 之后用户设置了一些环境变量,包括`bootargs`、`bootcmd`和`overdrive`,并执行了`saveenv`保存环境变量到SPI Flash,过程显示擦除和写入都成功。最后执行`reset`重启系统,日志显示U-Boot启动过程,包括内存检测、Flash初始化等步骤,但最后出现了“E:CD”和一些IPL信息,可能需要进一步分析。 用户的问题是询问“estar完成了吗”。根据日志,`estar`命令是在重启前执行的,但重启后日志显示U-Boot启动完成,但没有明确提到内核启动或系统启动成功的信息。需要检查是否有后续的内核加载和启动步骤是否完成,比如`bootm`命令是否执行成功,或者是否有内核panic等错误信息。 在用户提供的日志中,重启后的部分显示了U-Boot的初始化过程,但可能没有继续显示后续的启动信息。如果`bootcmd`中的`loados`和`bootm`命令正确执行,那么系统应该会继续启动内核。但用户提供的日志可能截断了,没有显示完整的启动过程。需要确认是否有更多日志信息,比如是否看到内核解压、挂载根文件系统等信息。 此外,用户设置的`bootargs`中指定了根文件系统的位置为`/dev/mtdblock3`,需要确认该分区是否存在,以及烧录的根文件系统是否正确。如果这些都正确,系统应该能正常启动。但根据现有信息,只能确认U-Boot部分启动成功,后续的内核和系统启动情况未知。 总结来看,用户执行的烧录步骤(擦除、写入、保存环境变量)都成功了,但系统重启后的完整启动过程未完全显示,需要进一步检查后续日志。如果`estar`命令已经执行完毕并触发了重启,且U-Boot正常启动,那么可以认为烧录过程已完成,但系统是否完全启动需要更多信息。 </think>### **分析结论** 根据您提供的日志,**烧录流程已成功完成**,且系统已重启进入U-Boot阶段。以下是关键步骤验证: --- ### **1. 烧录操作成功验证** - **SPI Flash擦除**: ```bash >> sf erase customer _spi_flash_erase: addr 0xaf0000, len 0x500000 SF: 5242880 bytes @ 0xaf0000 Erased: OK ``` - 擦除地址 `0xaf0000`,大小 `0x500000`(5MB),成功。 - **TFTP下载与写入**: ```bash >> tftp 0x21000000 customer.jffs2 Bytes transferred = 5242880 (500000 hex) >> sf write 0x21000000 customer ${filesize} SF: 5242880 bytes @ 0xaf0000 Written: OK ``` - 文件 `customer.jffs2` 成功下载并写入SPI Flash。 - **环境变量保存**: ```bash >> saveenv Saving Environment to SPIFlash... OK ``` - 环境变量(如 `bootargs`、`bootcmd`)已保存到SPI Flash。 --- ### **2. 系统重启与U-Boot启动状态** - **重启命令执行**: ```bash >> reset resetting ... ``` - 系统重启后,U-Boot日志显示初始化成功: ``` U-Boot 2021.10 (Aug 29 2025 - 11:49:41 +0800) SoC: SigmaStar iford DRAM: 126 MiB Flash: SPI 54M ``` - **关键配置验证**: - `bootargs` 设置正确(指定根文件系统为 `/dev/mtdblock3`)。 - `bootcmd` 包含 `loados` 和 `bootm`,理论上会加载并启动内核。 --- ### **3. 需进一步确认的环节** - **内核启动状态**: 日志中未显示 `bootm` 启动内核后的输出(如内核解压、挂载根文件系统)。需检查是否: - 内核镜像未正确烧录(如 `KERNEL` 分区未配置)。 - `loados` 命令未找到内核文件(需确认 `scripts/set_config` 中的路径是否正确)。 - **根文件系统完整性**: - `customer.jffs2` 写入地址为 `0xaf0000`,需确保 `mtdblock3` 分区指向该区域。 - 若分区配置错误,可能导致挂载失败。 --- ### **后续操作建议** 1. **检查U-Boot启动日志** - 查看是否出现 `Kernel image @ 0x22000000 [ 0x000000 - 0xXXXXXX ]` 和 `Starting kernel ...`。 - 若无,需检查 `bootcmd` 中的 `loados` 命令是否正确(如分区名称、地址)。 2. **手动执行启动命令** - 在U-Boot中尝试手动加载并启动内核: ```bash => dcache on => sf probe 0 => loados nor 0x22000000 KERNEL by_header => bootm 0x22000000 ``` - 若失败,日志会提示具体错误(如文件未找到、校验失败)。 3. **验证分区配置** - 执行 `mtdparts` 查看分区表是否包含 `mtdblock3`,且起始地址与 `customer.jffs2` 写入地址匹配。 --- ### **总结** - **烧录流程已完成**:所有命令(擦除、写入、保存环境变量)均成功执行。 - **U-Boot启动正常**:系统重启后U-Boot初始化成功,但需进一步确认内核启动和根文件系统挂载状态。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值