OMAPL138/AM1808支持NAND及其ECC出现的问题回复
2013-03-20 21:07
274 查看
最近为改板的AM1808移植了u-boot,kernel,使用am1808开发低成本m2m设备,支持3G,Wifi, zigbee,gps,rtc,SD/microSD,目的第一个版本已发布。
NAND的ECC校验较上以版本有所改善,并使用ubifs作为新的文件系统,支持sd卡更新系统。
下面是一些整理的资料,有些来自TI,有些来自论坛
OMAP-L138 NAND_ECC_HW and U-Boot
I'm a little bit confused about how OMAP-L138hardware supports 4-bit ECC for NAND devices. NAND device in question is:
SAMSUNG K9F2G08UXA
- Page Program : (2K + 64)Byte
- Block Erase : (128K + 4K)Byte
By default, DaVinci-PSP-SDK-03.20.00.06 is configured in terms of NAND ECC as follows:
U-Boot:
#undef CONFIG_SYS_NAND_HW_ECC
#define CONFIG_SYS_NAND_4BIT_HW_ECC
#define CONFIG_SYS_NAND_USE_FLASH_BBT
#define CFG_DAVINCI_STD_NAND_LAYOUT
Linux:
static struct davinci_nand_pdata da850_evm_nandflash_data = {
.parts = da850_evm_nandflash_partition,
.nr_parts = ARRAY_SIZE(da850_evm_nandflash_partition),
.ecc_mode = NAND_ECC_HW,
.ecc_bits = 4,
.options = NAND_USE_FLASH_BBT,
};
However, it turns out that these definitions are not compatible with each other. When I flash a JFFS2 root filesystem on the NAND device, mounting it fails. Changing the above options to:
U-Boot:
#define CONFIG_SYS_NAND_HW_ECC
#define CONFIG_SYS_NAND_USE_FLASH_BBT
#define CFG_DAVINCI_STD_NAND_LAYOUT
Linux:
static struct davinci_nand_pdata da850_evm_nandflash_data = {
.parts = da850_evm_nandflash_partition,
.nr_parts = ARRAY_SIZE(da850_evm_nandflash_partition),
.ecc_mode = NAND_ECC_HW,
.ecc_bits = 1,
.options = NAND_USE_FLASH_BBT,
};
Allows my system to boot. Unfortunately, there is one problem with this. My device needs to be able to program the boot area (UBL etc.) directly from Linux. OMAP-L138hardware boot supports only 4-bit ECC. Thus, my workaround is useless
as programming the bootsector with 1-bit ECC won't work. My conclusions are:
- U-Boot porgrams the NAND Flash with 4bit ECC correctly (I'm able to flash the bootsector from U-Boot with no problems)
- Linux configuration/implementation for 4-bit ECC is broken
How canI solve my issue? Linux and U-Boot codes are based on DaVinci-PSP-SDK-03.20.00.06 software. Were there any patches in the more recent versions?
Trying to use UBI with OMAPL138
This question is not answered
Posted by Marc-Andre Hebert
on Apr 21, 2010 6:24 PM
Prodigy160points
Hello,
I am trying to use UBI on top the NAND on the OMAPL138. But I am having problems. I am currently using TFTP and NFS to boot from the network. I enabled UBI and UBIFS in the kernel and cross compiled the ubi user tools. I then try to follow the steps from the ubifs FAQ.
Here are the mtd devices created by default on the EV
mtd0: 0x000000000000-0x000000020000 : "u-boot env"
mtd1: 0x000000020000-0x000000040000 : "UBL"
mtd2: 0x000000040000-0x0000000c0000 : "u-boot"
mtd3: 0x000000200000-0x000000600000 : "kernel"
mtd4: 0x000000600000-0x000020000000 : "filesystem"
Here are the 2 issues I observed.
1) There are errors when attaching the UBI device the second time (doing attach on a freshly erased/formatted mtd returns no error)
ubiattach /dev/ubi_ctrl -m 4
Then I get a series of error messages:
UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 0:0, read 64 bytes
[...]
UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 2:512, read 512 bytes
UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 21:512, read 512 bytes
UBI: run torture test for PEB 21
UBI: PEB 21 passed torture test, do not mark it a bad
And these last 4 lines keep getting repeated.
2) Doing a ubiformat seems to screp the bad block table used by u-boot
Ex: root# ubiformat /dev/mtd4
Then at the following boot:
NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit)
Bad block table not found for chip 0
Bad block table not found for chip 0
Bad block table written to 0x1ffe0000, version 0x01
Bad block table written to 0x1ffc0000, version 0x01
From what I've gathered the BBT in u-boot uses the last 4 blocks.
At first I was only trying with mtd4 so I figured reducing it's size by 4 blocks and defining a mtd5 for the BTT would work but it didn't.
I then tried formatting the mtd3 and obtained the same results.
I don't see why this is affecting the BBT table.
Any help would be appreciated
Marc
u-bootOMAP L138 NANDOMAP L138MTDNANDLinux Drivers
Report Abuse
Reply
All Replies
Posted by Marc-Andre Hebert
onApr 21, 2010 7:09 PM
Prodigy160points
I actually found a partial answer for my problem number 1. I needed to specify "--vid-hdr-offset 2048" when attaching the mtd device because sub pages do not seem to be supported.
I still have the issue with the BBT being rewritten each time.
Thanks
Marc
Report Abuse
Reply
Posted by Marc-Andre Hebert
onApr 22, 2010 7:40 PM
Prodigy160points
The BBT being rewritten was corrected by updating the u-boot to the latest version from the git tree (http://arago-project.org/git/people/?p=sekhar/u-boot-omapl1.git).
Report Abuse
Reply
Posted by Sudhakar Rajashekhara
onApr 26, 2010 12:36 PM
Expert5070points
Marc,
I did not observe problem No. 1 reported by you if I run ubiattach/ubidetach multiple times (without any arguments) after running ubiformat on the partition.
Regards,
Sudhakar
Does this help with your question? If not, please send back more information. If it answers your question, please click the Verify Answer button below.
Report Abuse
Reply
Posted by Clifton Barnes
onAug 31, 2010 7:56 PM
Prodigy90points
I'm using DaVinci-PSP-SDK-03.20.00.11 for U-Boot and Linux kernel on the TI OMAPL-138. I am having the exact same problem as No. 1 from Marc-Andre Hebert. I can do "ubiformat /dev/mtd2 -f rfs" to format the NAND partition and flash my UBI root filesystem. I can then
"ubiattach /dev/ubi_ctrl -m2" and everything works fine with no errors. However, if I then run "ubidetach /dev/ubi_ctrl -m2" and then run "ubiattach /dev/ubi_ctrl -m2" again, it is not successful. I get the following:
# ubiattach /dev/ubi_ctrl -m2
UBI: attaching mtd2 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 237:0, read 64 bytes
Backtrace:
[<c002d5b8>] (dump_backtrace+0x0/0x110) from [<c02e4748>] (dump_stack+0x18/0x1c)
r6:c3a31000 r5:ffffffb6 r4:00000040 r3:00000000
[<c02e4730>] (dump_stack+0x0/0x1c) from [<c01e5604>] (ubi_io_read+0x1a8/0x244)
[<c01e545c>] (ubi_io_read+0x0/0x244) from [<c01e5bfc>] (ubi_io_read_ec_hdr+0x74/0x34c)
[<c01e5b88>] (ubi_io_read_ec_hdr+0x0/0x34c) from [<c01e9360>] (ubi_scan+0x134/0x7d0)
[<c01e922c>] (ubi_scan+0x0/0x7d0) from [<c01dfe50>] (ubi_attach_mtd_dev+0x604/0xcc4)
[<c01df84c>] (ubi_attach_mtd_dev+0x0/0xcc4) from [<c01e07b8>] (ctrl_cdev_ioctl+0xec/0x1a8)
[<c01e06cc>] (ctrl_cdev_ioctl+0x0/0x1a8) from [<c00ae508>] (vfs_ioctl+0x34/0xb4)
r6:40186f40 r5:bec0ec48 r4:c3906400
[<c00ae4d4>] (vfs_ioctl+0x0/0xb4) from [<c00aebd4>] (do_vfs_ioctl+0x554/0x5ac)
r6:c3415ad8 r5:c3906400 r4:bec0ec48 r3:00002000
[<c00ae680>] (do_vfs_ioctl+0x0/0x5ac) from [<c00aec6c>] (sys_ioctl+0x40/0x64)
[<c00aec2c>] (sys_ioctl+0x0/0x64) from [<c0029f60>] (ret_fast_syscall+0x0/0x28)
r7:00000036 r6:00000003 r5:ffffffff r4:bec0ec48
<repeated many times>
How were you able to solve error No. 1 from the first post?
Thanks,
Clif
Report Abuse
Reply
Posted by Marc-Andre Hebert
onAug 31, 2010 8:01 PM
Prodigy160points
Like I said in an earlier post, you need to specify the --vid-hdr-offset 2048 when attaching.
Report Abuse
Reply
Posted by Clifton Barnes
onAug 31, 2010 8:12 PM
Prodigy90points
If I specify that option I get the following:
# ubiattach --vid-hdr-offset 2048 /dev/ubi_ctrl -m2
UBI: attaching mtd2 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI error: validate_ec_hdr: bad VID header offset 512, expected 2048
UBI error: validate_ec_hdr: bad EC header
Backtrace:
[<c002d5b8>] (dump_backtrace+0x0/0x110) from [<c02e4748>] (dump_stack+0x18/0x1c)
r6:c3a14800 r5:00000000 r4:c3a5e400 r3:00000040
[<c02e4730>] (dump_stack+0x0/0x1c) from [<c01e5e64>] (ubi_io_read_ec_hdr+0x2dc/0x34c)
[<c01e5b88>] (ubi_io_read_ec_hdr+0x0/0x34c) from [<c01e9360>] (ubi_scan+0x134/0x7d0)
[<c01e922c>] (ubi_scan+0x0/0x7d0) from [<c01dfe50>] (ubi_attach_mtd_dev+0x604/0xcc4)
[<c01df84c>] (ubi_attach_mtd_dev+0x0/0xcc4) from [<c01e07b8>] (ctrl_cdev_ioctl+0xec/0x1a8)
[<c01e06cc>] (ctrl_cdev_ioctl+0x0/0x1a8) from [<c00ae508>] (vfs_ioctl+0x34/0xb4)
r6:40186f40 r5:bef9ac28 r4:c396fc00
[<c00ae4d4>] (vfs_ioctl+0x0/0xb4) from [<c00aebd4>] (do_vfs_ioctl+0x554/0x5ac)
r6:c3415ad8 r5:c396fc00 r4:bef9ac28 r3:00002000
[<c00ae680>] (do_vfs_ioctl+0x0/0x5ac) from [<c00aec6c>] (sys_ioctl+0x40/0x64)
[<c00aec2c>] (sys_ioctl+0x0/0x64) from [<c0029f60>] (ret_fast_syscall+0x0/0x28)
r7:00000036 r6:00000003 r5:ffffffff r4:bef9ac28
UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0
UBI error: ubi_attach_mtd_dev: failed to attach by scanning, error -22
ubiattach: error!: cannot attach mtd2
error 22 (Invalid argument)
I should have specified that I had tried your suggestion before. So, I didn't know if there was something else that was found to fix this problem.
NAND的ECC校验较上以版本有所改善,并使用ubifs作为新的文件系统,支持sd卡更新系统。
下面是一些整理的资料,有些来自TI,有些来自论坛
OMAP-L138 NAND_ECC_HW and U-Boot
I'm a little bit confused about how OMAP-L138hardware supports 4-bit ECC for NAND devices. NAND device in question is:
SAMSUNG K9F2G08UXA
- Page Program : (2K + 64)Byte
- Block Erase : (128K + 4K)Byte
By default, DaVinci-PSP-SDK-03.20.00.06 is configured in terms of NAND ECC as follows:
U-Boot:
#undef CONFIG_SYS_NAND_HW_ECC
#define CONFIG_SYS_NAND_4BIT_HW_ECC
#define CONFIG_SYS_NAND_USE_FLASH_BBT
#define CFG_DAVINCI_STD_NAND_LAYOUT
Linux:
static struct davinci_nand_pdata da850_evm_nandflash_data = {
.parts = da850_evm_nandflash_partition,
.nr_parts = ARRAY_SIZE(da850_evm_nandflash_partition),
.ecc_mode = NAND_ECC_HW,
.ecc_bits = 4,
.options = NAND_USE_FLASH_BBT,
};
However, it turns out that these definitions are not compatible with each other. When I flash a JFFS2 root filesystem on the NAND device, mounting it fails. Changing the above options to:
U-Boot:
#define CONFIG_SYS_NAND_HW_ECC
#define CONFIG_SYS_NAND_USE_FLASH_BBT
#define CFG_DAVINCI_STD_NAND_LAYOUT
Linux:
static struct davinci_nand_pdata da850_evm_nandflash_data = {
.parts = da850_evm_nandflash_partition,
.nr_parts = ARRAY_SIZE(da850_evm_nandflash_partition),
.ecc_mode = NAND_ECC_HW,
.ecc_bits = 1,
.options = NAND_USE_FLASH_BBT,
};
Allows my system to boot. Unfortunately, there is one problem with this. My device needs to be able to program the boot area (UBL etc.) directly from Linux. OMAP-L138hardware boot supports only 4-bit ECC. Thus, my workaround is useless
as programming the bootsector with 1-bit ECC won't work. My conclusions are:
- U-Boot porgrams the NAND Flash with 4bit ECC correctly (I'm able to flash the bootsector from U-Boot with no problems)
- Linux configuration/implementation for 4-bit ECC is broken
How canI solve my issue? Linux and U-Boot codes are based on DaVinci-PSP-SDK-03.20.00.06 software. Were there any patches in the more recent versions?
Trying to use UBI with OMAPL138
This question is not answered
Posted by Marc-Andre Hebert
on Apr 21, 2010 6:24 PM
Prodigy160points
Hello,
I am trying to use UBI on top the NAND on the OMAPL138. But I am having problems. I am currently using TFTP and NFS to boot from the network. I enabled UBI and UBIFS in the kernel and cross compiled the ubi user tools. I then try to follow the steps from the ubifs FAQ.
Here are the mtd devices created by default on the EV
mtd0: 0x000000000000-0x000000020000 : "u-boot env"
mtd1: 0x000000020000-0x000000040000 : "UBL"
mtd2: 0x000000040000-0x0000000c0000 : "u-boot"
mtd3: 0x000000200000-0x000000600000 : "kernel"
mtd4: 0x000000600000-0x000020000000 : "filesystem"
Here are the 2 issues I observed.
1) There are errors when attaching the UBI device the second time (doing attach on a freshly erased/formatted mtd returns no error)
ubiattach /dev/ubi_ctrl -m 4
Then I get a series of error messages:
UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 0:0, read 64 bytes
[...]
UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 2:512, read 512 bytes
UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 21:512, read 512 bytes
UBI: run torture test for PEB 21
UBI: PEB 21 passed torture test, do not mark it a bad
And these last 4 lines keep getting repeated.
2) Doing a ubiformat seems to screp the bad block table used by u-boot
Ex: root# ubiformat /dev/mtd4
Then at the following boot:
NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit)
Bad block table not found for chip 0
Bad block table not found for chip 0
Bad block table written to 0x1ffe0000, version 0x01
Bad block table written to 0x1ffc0000, version 0x01
From what I've gathered the BBT in u-boot uses the last 4 blocks.
At first I was only trying with mtd4 so I figured reducing it's size by 4 blocks and defining a mtd5 for the BTT would work but it didn't.
I then tried formatting the mtd3 and obtained the same results.
I don't see why this is affecting the BBT table.
Any help would be appreciated
Marc
u-bootOMAP L138 NANDOMAP L138MTDNANDLinux Drivers
Report Abuse
Reply
All Replies
Posted by Marc-Andre Hebert
onApr 21, 2010 7:09 PM
Prodigy160points
I actually found a partial answer for my problem number 1. I needed to specify "--vid-hdr-offset 2048" when attaching the mtd device because sub pages do not seem to be supported.
I still have the issue with the BBT being rewritten each time.
Thanks
Marc
Report Abuse
Reply
Posted by Marc-Andre Hebert
onApr 22, 2010 7:40 PM
Prodigy160points
The BBT being rewritten was corrected by updating the u-boot to the latest version from the git tree (http://arago-project.org/git/people/?p=sekhar/u-boot-omapl1.git).
Report Abuse
Reply
Posted by Sudhakar Rajashekhara
onApr 26, 2010 12:36 PM
Expert5070points
Marc,
I did not observe problem No. 1 reported by you if I run ubiattach/ubidetach multiple times (without any arguments) after running ubiformat on the partition.
Regards,
Sudhakar
Does this help with your question? If not, please send back more information. If it answers your question, please click the Verify Answer button below.
Report Abuse
Reply
Posted by Clifton Barnes
onAug 31, 2010 7:56 PM
Prodigy90points
I'm using DaVinci-PSP-SDK-03.20.00.11 for U-Boot and Linux kernel on the TI OMAPL-138. I am having the exact same problem as No. 1 from Marc-Andre Hebert. I can do "ubiformat /dev/mtd2 -f rfs" to format the NAND partition and flash my UBI root filesystem. I can then
"ubiattach /dev/ubi_ctrl -m2" and everything works fine with no errors. However, if I then run "ubidetach /dev/ubi_ctrl -m2" and then run "ubiattach /dev/ubi_ctrl -m2" again, it is not successful. I get the following:
# ubiattach /dev/ubi_ctrl -m2
UBI: attaching mtd2 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 237:0, read 64 bytes
Backtrace:
[<c002d5b8>] (dump_backtrace+0x0/0x110) from [<c02e4748>] (dump_stack+0x18/0x1c)
r6:c3a31000 r5:ffffffb6 r4:00000040 r3:00000000
[<c02e4730>] (dump_stack+0x0/0x1c) from [<c01e5604>] (ubi_io_read+0x1a8/0x244)
[<c01e545c>] (ubi_io_read+0x0/0x244) from [<c01e5bfc>] (ubi_io_read_ec_hdr+0x74/0x34c)
[<c01e5b88>] (ubi_io_read_ec_hdr+0x0/0x34c) from [<c01e9360>] (ubi_scan+0x134/0x7d0)
[<c01e922c>] (ubi_scan+0x0/0x7d0) from [<c01dfe50>] (ubi_attach_mtd_dev+0x604/0xcc4)
[<c01df84c>] (ubi_attach_mtd_dev+0x0/0xcc4) from [<c01e07b8>] (ctrl_cdev_ioctl+0xec/0x1a8)
[<c01e06cc>] (ctrl_cdev_ioctl+0x0/0x1a8) from [<c00ae508>] (vfs_ioctl+0x34/0xb4)
r6:40186f40 r5:bec0ec48 r4:c3906400
[<c00ae4d4>] (vfs_ioctl+0x0/0xb4) from [<c00aebd4>] (do_vfs_ioctl+0x554/0x5ac)
r6:c3415ad8 r5:c3906400 r4:bec0ec48 r3:00002000
[<c00ae680>] (do_vfs_ioctl+0x0/0x5ac) from [<c00aec6c>] (sys_ioctl+0x40/0x64)
[<c00aec2c>] (sys_ioctl+0x0/0x64) from [<c0029f60>] (ret_fast_syscall+0x0/0x28)
r7:00000036 r6:00000003 r5:ffffffff r4:bec0ec48
<repeated many times>
How were you able to solve error No. 1 from the first post?
Thanks,
Clif
Report Abuse
Reply
Posted by Marc-Andre Hebert
onAug 31, 2010 8:01 PM
Prodigy160points
Like I said in an earlier post, you need to specify the --vid-hdr-offset 2048 when attaching.
Report Abuse
Reply
Posted by Clifton Barnes
onAug 31, 2010 8:12 PM
Prodigy90points
If I specify that option I get the following:
# ubiattach --vid-hdr-offset 2048 /dev/ubi_ctrl -m2
UBI: attaching mtd2 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI error: validate_ec_hdr: bad VID header offset 512, expected 2048
UBI error: validate_ec_hdr: bad EC header
Backtrace:
[<c002d5b8>] (dump_backtrace+0x0/0x110) from [<c02e4748>] (dump_stack+0x18/0x1c)
r6:c3a14800 r5:00000000 r4:c3a5e400 r3:00000040
[<c02e4730>] (dump_stack+0x0/0x1c) from [<c01e5e64>] (ubi_io_read_ec_hdr+0x2dc/0x34c)
[<c01e5b88>] (ubi_io_read_ec_hdr+0x0/0x34c) from [<c01e9360>] (ubi_scan+0x134/0x7d0)
[<c01e922c>] (ubi_scan+0x0/0x7d0) from [<c01dfe50>] (ubi_attach_mtd_dev+0x604/0xcc4)
[<c01df84c>] (ubi_attach_mtd_dev+0x0/0xcc4) from [<c01e07b8>] (ctrl_cdev_ioctl+0xec/0x1a8)
[<c01e06cc>] (ctrl_cdev_ioctl+0x0/0x1a8) from [<c00ae508>] (vfs_ioctl+0x34/0xb4)
r6:40186f40 r5:bef9ac28 r4:c396fc00
[<c00ae4d4>] (vfs_ioctl+0x0/0xb4) from [<c00aebd4>] (do_vfs_ioctl+0x554/0x5ac)
r6:c3415ad8 r5:c396fc00 r4:bef9ac28 r3:00002000
[<c00ae680>] (do_vfs_ioctl+0x0/0x5ac) from [<c00aec6c>] (sys_ioctl+0x40/0x64)
[<c00aec2c>] (sys_ioctl+0x0/0x64) from [<c0029f60>] (ret_fast_syscall+0x0/0x28)
r7:00000036 r6:00000003 r5:ffffffff r4:bef9ac28
UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0
UBI error: ubi_attach_mtd_dev: failed to attach by scanning, error -22
ubiattach: error!: cannot attach mtd2
error 22 (Invalid argument)
I should have specified that I had tried your suggestion before. So, I didn't know if there was something else that was found to fix this problem.
相关文章推荐
- WIN7上安装sql2000出现的此系统不支持的问题解决方法
- 韦东山教程ARM的时钟设置出现的问题及其解决方法
- 有感:应聘Java笔试时可能出现问题及其答案[转贴]
- 关于Vue项目路由栏去除“#”的处理方法及其刷新页面时出现404问题
- jekyll博客搭建及其可能出现的问题(1)
- myeclise maven导入现成的web项目时出现的问题 增加web支持
- [转] 应聘Java笔试时可能出现问题及其答案(第八部分)
- 解决虚拟机安装64位系统“此主机支持 Intel VT-x,但 Intel VT-x 处于禁用状态”的问题(一般出现在win7 旗舰版)
- elasticsearch-2.1.0集群搭建 及其出现的一些问题
- 关于mini2440烧写supervivi出现no nand device found问题的解决办法
- 应聘Java笔试时可能出现问题及其答案
- 应聘Java笔试时可能出现问题及其答案 (七)
- jspsmart 支持jdk1.4 解决utf-8编码时出现乱码的问题 附源码和jar包
- 安卓学习笔记---使用AndroidStudio出现的问题错误(错误: -source 1.6 中不支持 diamond 运算符 (请使用 -source 7 或更高版本以启用 diamond 运算)
- 应聘Java笔试时可能出现问题及其答案
- 有感:应聘Java笔试时可能出现问题及其答案
- iOS-app 支持arm64位出现的一些小问题
- IE6下position:fixed不支持问题及其解决方式
- 应聘Java笔试时可能出现问题及其答案
- discuz 海量信息公司的保10洁 2.1.0使用了短php标签在不支持&lt;?的配置上出现奇怪问题