| Message ID | 1442480614-32345-1-git-send-email-b18965@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Sep 17, 2015 at 05:03:34PM +0800, Alison Wang wrote: > Add Freescale LS1021A initial defconfig file. > The LS1021A SoC is a dual-core Cortex-A7 based processor. > > LS1021A has some special configurations against imx_v6_v7_defconfig and > multi_v7_defconfig, such as CONFIG_ARM_LPAE, CONFIG_ARM_PSCI... > LPAE needs to be supported to access memory beyond the 4GB limit for > LS1021A. PSCI needs to be supported for LS1021A too. But CONFIG_ARM_LPAE > and CONFIG_ARM_PSCI are disabled in imx_v6_v7_defconfig and > multi_v7_defconfig, so a separate LS1021A defconfig is needed. Sounds like a need for multi_v7_lpae_defconfig rather than creating a new load of platform specific defconfigs.
> On Thu, Sep 17, 2015 at 05:03:34PM +0800, Alison Wang wrote: > > Add Freescale LS1021A initial defconfig file. > > The LS1021A SoC is a dual-core Cortex-A7 based processor. > > > > LS1021A has some special configurations against imx_v6_v7_defconfig > > and multi_v7_defconfig, such as CONFIG_ARM_LPAE, CONFIG_ARM_PSCI... > > LPAE needs to be supported to access memory beyond the 4GB limit for > > LS1021A. PSCI needs to be supported for LS1021A too. But > > CONFIG_ARM_LPAE and CONFIG_ARM_PSCI are disabled in > > imx_v6_v7_defconfig and multi_v7_defconfig, so a separate LS1021A > defconfig is needed. > > Sounds like a need for multi_v7_lpae_defconfig rather than creating a > new load of platform specific defconfigs. > [Alison Wang] Thanks for your reply. I agreed with you about creating a new multi_v7_lpae_defconfig. In multi_v7_lpae_defconfig, I need to add the following CONFIG_XX to support LS1021A based on multi_v7_defconfig. CONFIG_ARM_LPAE=y CONFIG_VMSPLIT_2G=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=256000 CONFIG_GIANFAR=y CONFIG_REALTEK_PHY=y CONFIG_I2C_IMX=y CONFIG_SPI_FSL_DSPI=y CONFIG_IMX2_WDT=y CONFIG_REGULATOR_DEBUG=y CONFIG_REGULATOR_VIRTUAL_CONSUMER=y CONFIG_SOUND=y CONFIG_SND=y CONFIG_SND_SOC=y CONFIG_SND_SOC_FSL_SAI=y CONFIG_SND_SOC_SGTL5000=y CONFIG_SND_SIMPLE_CARD=y CONFIG_FSL_EDMA=y CONFIG_CLK_QORIQ=y What's your suggestion? If it's ok, I will send a patch about multi_v7_lpae_defconfig. Best Regards, Alison Wang
On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang <alison.wang@freescale.com> wrote: > [Alison Wang] Thanks for your reply. I agreed with you about creating > a new multi_v7_lpae_defconfig. In multi_v7_lpae_defconfig, I need to add > the following CONFIG_XX to support LS1021A based on multi_v7_defconfig. > > CONFIG_ARM_LPAE=y > CONFIG_VMSPLIT_2G=y Is CONFIG_VMSPLIT_2G=y really needed?
> On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang <alison.wang@freescale.com> > wrote: > > > [Alison Wang] Thanks for your reply. I agreed with you about creating > > a new multi_v7_lpae_defconfig. In multi_v7_lpae_defconfig, I need to > > add the following CONFIG_XX to support LS1021A based on > multi_v7_defconfig. > > > > CONFIG_ARM_LPAE=y > > CONFIG_VMSPLIT_2G=y > > Is CONFIG_VMSPLIT_2G=y really needed? [Alison Wang] I tried to remove CONFIG_VMSPLIT_2G and used the default CONFIG_VMSPLIT_3G, but kernel could not boot up. It hangs at " Starting kernel ... ". Any suggestion? Thanks. Best Regards, Alison Wang
On Thursday 24 September 2015 07:27:10 Huan Wang wrote: > > On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang <alison.wang@freescale.com> > > wrote: > > > > > [Alison Wang] Thanks for your reply. I agreed with you about creating > > > a new multi_v7_lpae_defconfig. In multi_v7_lpae_defconfig, I need to > > > add the following CONFIG_XX to support LS1021A based on > > multi_v7_defconfig. > > > > > > CONFIG_ARM_LPAE=y > > > CONFIG_VMSPLIT_2G=y > > > > Is CONFIG_VMSPLIT_2G=y really needed? > [Alison Wang] I tried to remove CONFIG_VMSPLIT_2G and used the default CONFIG_VMSPLIT_3G, > but kernel could not boot up. It hangs at " Starting kernel ... ". > > Any suggestion? Thanks. Try enabling DEBUG_LL for your platform to get some debug output, if you still don't get any helpful messages, try also inserting printascii(__func__); statements in the early boot process to see how far you get before the hang. Arnd
> On Thursday 24 September 2015 07:27:10 Huan Wang wrote: > > > On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang > > > <alison.wang@freescale.com> > > > wrote: > > > > > > > [Alison Wang] Thanks for your reply. I agreed with you about > > > > creating a new multi_v7_lpae_defconfig. In > > > > multi_v7_lpae_defconfig, I need to add the following CONFIG_XX to > > > > support LS1021A based on > > > multi_v7_defconfig. > > > > > > > > CONFIG_ARM_LPAE=y > > > > CONFIG_VMSPLIT_2G=y > > > > > > Is CONFIG_VMSPLIT_2G=y really needed? > > [Alison Wang] I tried to remove CONFIG_VMSPLIT_2G and used the default > > CONFIG_VMSPLIT_3G, but kernel could not boot up. It hangs at " Starting > kernel ... ". > > > > Any suggestion? Thanks. > > Try enabling DEBUG_LL for your platform to get some debug output, if you > still don't get any helpful messages, try also inserting > > printascii(__func__); > > statements in the early boot process to see how far you get before the hang. > [Alison Wang] I can get to __turn_mmu_on or later, but I could not get the print message "Booting Linux on physical CPU 0xf00" in smp_setup_processor_id(). I guess something wrong with the initial page tables in __create_page_tables, as for CONFIG_VMSPLIT_3G, only PAGE_OFFSET is changed from 0x80000000 to 0xC0000000. BTW, on our platform, TEXT_OFFSET is 0x00008000, PHYS_OFFSET is 0x80000000. Any suggestion? Thanks. Best Regards, Alison Wang
On Wednesday 14 October 2015 10:18:47 Huan Wang wrote: > > On Thursday 24 September 2015 07:27:10 Huan Wang wrote: > > > > On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang > > > > <alison.wang@freescale.com> > > > > wrote: > > > > > > > > > [Alison Wang] Thanks for your reply. I agreed with you about > > > > > creating a new multi_v7_lpae_defconfig. In > > > > > multi_v7_lpae_defconfig, I need to add the following CONFIG_XX to > > > > > support LS1021A based on > > > > multi_v7_defconfig. > > > > > > > > > > CONFIG_ARM_LPAE=y > > > > > CONFIG_VMSPLIT_2G=y > > > > > > > > Is CONFIG_VMSPLIT_2G=y really needed? > > > [Alison Wang] I tried to remove CONFIG_VMSPLIT_2G and used the default > > > CONFIG_VMSPLIT_3G, but kernel could not boot up. It hangs at " Starting > > kernel ... ". > > > > > > Any suggestion? Thanks. > > > > Try enabling DEBUG_LL for your platform to get some debug output, if you > > still don't get any helpful messages, try also inserting > > > > printascii(__func__); > > > > statements in the early boot process to see how far you get before the hang. > > > [Alison Wang] I can get to __turn_mmu_on or later, but I could not get the print > message "Booting Linux on physical CPU 0xf00" in smp_setup_processor_id(). > > I guess something wrong with the initial page tables in __create_page_tables, > as for CONFIG_VMSPLIT_3G, only PAGE_OFFSET is changed from 0x80000000 to 0xC0000000. > BTW, on our platform, TEXT_OFFSET is 0x00008000, PHYS_OFFSET is 0x80000000. > > Any suggestion? Thanks. My first guess is that there is something wrong with your debug_ll implementation, as that would explain why you can't get anything to the console after turning on page tables. It looks like ls1021a uses lpuart, but I can't even see an implementation for that in arch/arm/include/debug/. What code do you use for printing? Arnd
> On Wednesday 14 October 2015 10:18:47 Huan Wang wrote: > > > On Thursday 24 September 2015 07:27:10 Huan Wang wrote: > > > > > On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang > > > > > <alison.wang@freescale.com> > > > > > wrote: > > > > > > > > > > > [Alison Wang] Thanks for your reply. I agreed with you about > > > > > > creating a new multi_v7_lpae_defconfig. In > > > > > > multi_v7_lpae_defconfig, I need to add the following CONFIG_XX > > > > > > to support LS1021A based on > > > > > multi_v7_defconfig. > > > > > > > > > > > > CONFIG_ARM_LPAE=y > > > > > > CONFIG_VMSPLIT_2G=y > > > > > > > > > > Is CONFIG_VMSPLIT_2G=y really needed? > > > > [Alison Wang] I tried to remove CONFIG_VMSPLIT_2G and used the > > > > default CONFIG_VMSPLIT_3G, but kernel could not boot up. It hangs > > > > at " Starting > > > kernel ... ". > > > > > > > > Any suggestion? Thanks. > > > > > > Try enabling DEBUG_LL for your platform to get some debug output, if > > > you still don't get any helpful messages, try also inserting > > > > > > printascii(__func__); > > > > > > statements in the early boot process to see how far you get before the > hang. > > > > > [Alison Wang] I can get to __turn_mmu_on or later, but I could not get > > the print message "Booting Linux on physical CPU 0xf00" in > smp_setup_processor_id(). > > > > I guess something wrong with the initial page tables in > > __create_page_tables, as for CONFIG_VMSPLIT_3G, only PAGE_OFFSET is > changed from 0x80000000 to 0xC0000000. > > BTW, on our platform, TEXT_OFFSET is 0x00008000, PHYS_OFFSET is > 0x80000000. > > > > Any suggestion? Thanks. > > My first guess is that there is something wrong with your debug_ll > implementation, as that would explain why you can't get anything to the > console after turning on page tables. > > It looks like ls1021a uses lpuart, but I can't even see an implementation > for that in arch/arm/include/debug/. What code do you use for printing? > [Alison Wang] ls1021a uses duart as the default serial port, not lpuart. So 8250/16550 serial driver is used. Let me explain my debug process in detail. When CONFIG_VMSPLIT_2G is used, I could boot up the whole kernel and get the print message " Booting Linux on physical CPU 0xf00" after "Starting kernel" as below. Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0xf00 ..... But when CONFIG_VMSPLIT_3G is used, I couldn't get print message " Booting Linux on physical CPU 0xf00". It only hangs at "Starting kernel ...". Moreover, I add some asm code in __turn_mmu_on to print some simple characters, and I could get the print characters when CONFIG_VMSPLIT_3G is used. So I guess there is something wrong with the page tables. Best Regards, Alison Wang
On Thursday 15 October 2015 02:11:57 Huan Wang wrote: > > On Wednesday 14 October 2015 10:18:47 Huan Wang wrote: > > > > On Thursday 24 September 2015 07:27:10 Huan Wang wrote: > > > > > > On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang <alison.wang@freescale.com> wrote: > > > > > Any suggestion? Thanks. > > > > > > > > Try enabling DEBUG_LL for your platform to get some debug output, if > > > > you still don't get any helpful messages, try also inserting > > > > > > > > printascii(__func__); > > > > > > > > statements in the early boot process to see how far you get before the hang. > > > > > > > [Alison Wang] ls1021a uses duart as the default serial port, not lpuart. So > 8250/16550 serial driver is used. Let me explain my debug process in detail. Ah, I see. > When CONFIG_VMSPLIT_2G is used, I could boot up the whole kernel and get the > print message " Booting Linux on physical CPU 0xf00" after "Starting kernel" > as below. > > Starting kernel ... > [ 0.000000] Booting Linux on physical CPU 0xf00 > ..... > > But when CONFIG_VMSPLIT_3G is used, I couldn't get print message " Booting Linux > on physical CPU 0xf00". It only hangs at "Starting kernel ...". > > Moreover, I add some asm code in __turn_mmu_on to print some simple characters, and > I could get the print characters when CONFIG_VMSPLIT_3G is used. So I guess there > is something wrong with the page tables. Ok. What I was suggesting above though was to try to pinpoint exactly where it goes wrong. You have verified that it does not crash before the page tables are enabled, but that is very early. You have also shown that the kernel crashes before the point at which the 'Booting Linux on physical CPU 0xf00' message is printed to the kernel, but that is *much* later: setup_arch() calls parse_early_param(), which in turn sets up early_console_write(). This means the 'Booting Linux on physical CPU 0xf00' is still stuck in the log buffer and you may have crashed someone inbetween. If you can call printascii(), you can try to do that just after enabling the page tables to see if that was the problem like you suspect, or otherwise add more printascii() statements between __turn_mmu_on and parse_early_param() to pinpoint the exact code that breaks. Arnd
> On Thursday 15 October 2015 02:11:57 Huan Wang wrote: > > > On Wednesday 14 October 2015 10:18:47 Huan Wang wrote: > > > > > On Thursday 24 September 2015 07:27:10 Huan Wang wrote: > > > > > > > On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang > <alison.wang@freescale.com> wrote: > > > > > > Any suggestion? Thanks. > > > > > > > > > > Try enabling DEBUG_LL for your platform to get some debug > > > > > output, if you still don't get any helpful messages, try also > > > > > inserting > > > > > > > > > > printascii(__func__); > > > > > > > > > > statements in the early boot process to see how far you get > before the hang. > > > > > > > > > > [Alison Wang] ls1021a uses duart as the default serial port, not > > lpuart. So > > 8250/16550 serial driver is used. Let me explain my debug process in > detail. > > Ah, I see. > > > When CONFIG_VMSPLIT_2G is used, I could boot up the whole kernel and > > get the print message " Booting Linux on physical CPU 0xf00" after > "Starting kernel" > > as below. > > > > Starting kernel ... > > [ 0.000000] Booting Linux on physical CPU 0xf00 > > ..... > > > > But when CONFIG_VMSPLIT_3G is used, I couldn't get print message " > > Booting Linux on physical CPU 0xf00". It only hangs at "Starting > kernel ...". > > > > Moreover, I add some asm code in __turn_mmu_on to print some simple > > characters, and I could get the print characters when > > CONFIG_VMSPLIT_3G is used. So I guess there is something wrong with > the page tables. > > Ok. What I was suggesting above though was to try to pinpoint exactly > where it goes wrong. You have verified that it does not crash before the > page tables are enabled, but that is very early. You have also shown > that the kernel crashes before the point at which the 'Booting Linux on > physical CPU 0xf00' message is printed to the kernel, but that is *much* > later: setup_arch() calls parse_early_param(), which in turn sets up > early_console_write(). This means the 'Booting Linux on physical CPU > 0xf00' > is still stuck in the log buffer and you may have crashed someone > inbetween. > > If you can call printascii(), you can try to do that just after enabling > the page tables to see if that was the problem like you suspect, or > otherwise add more printascii() statements between __turn_mmu_on and > parse_early_param() to pinpoint the exact code that breaks. [Alison Wang] Thank you very much for your help. The issue is fixed. Best Regards, Alison Wang
On Tuesday 27 October 2015 14:40:21 Huan Wang wrote: > > > > Ok. What I was suggesting above though was to try to pinpoint exactly > > where it goes wrong. You have verified that it does not crash before the > > page tables are enabled, but that is very early. You have also shown > > that the kernel crashes before the point at which the 'Booting Linux on > > physical CPU 0xf00' message is printed to the kernel, but that is *much* > > later: setup_arch() calls parse_early_param(), which in turn sets up > > early_console_write(). This means the 'Booting Linux on physical CPU > > 0xf00' > > is still stuck in the log buffer and you may have crashed someone > > inbetween. > > > > If you can call printascii(), you can try to do that just after enabling > > the page tables to see if that was the problem like you suspect, or > > otherwise add more printascii() statements between __turn_mmu_on and > > parse_early_param() to pinpoint the exact code that breaks. > [Alison Wang] Thank you very much for your help. The issue is fixed. > Ah, very good. I'm curious what caused the problem in the end. Arnd
> On Tuesday 27 October 2015 14:40:21 Huan Wang wrote: > > > > > > Ok. What I was suggesting above though was to try to pinpoint > > > exactly where it goes wrong. You have verified that it does not > > > crash before the page tables are enabled, but that is very early. > > > You have also shown that the kernel crashes before the point at > > > which the 'Booting Linux on physical CPU 0xf00' message is printed > > > to the kernel, but that is *much* > > > later: setup_arch() calls parse_early_param(), which in turn sets up > > > early_console_write(). This means the 'Booting Linux on physical CPU > > > 0xf00' > > > is still stuck in the log buffer and you may have crashed someone > > > inbetween. > > > > > > If you can call printascii(), you can try to do that just after > > > enabling the page tables to see if that was the problem like you > > > suspect, or otherwise add more printascii() statements between > > > __turn_mmu_on and > > > parse_early_param() to pinpoint the exact code that breaks. > > [Alison Wang] Thank you very much for your help. The issue is fixed. > > > > Ah, very good. I'm curious what caused the problem in the end. [Alison Wang] The problem is caused by the wrong fdt_high setting (0xcfffffff). When 3G/1G user/kernel memory split is used, U-Boot relocates the device tree blob into high memory when booting the kernel and the kernel is unable to access the blob. Best Regards, Alison Wang
diff --git a/arch/arm/configs/ls1021a_defconfig b/arch/arm/configs/ls1021a_defconfig new file mode 100644 index 0000000..5ec5316 --- /dev/null +++ b/arch/arm/configs/ls1021a_defconfig @@ -0,0 +1,160 @@ +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_NO_HZ_IDLE=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_LOG_BUF_SHIFT=16 +CONFIG_BLK_DEV_INITRD=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS_ALL=y +CONFIG_EMBEDDED=y +CONFIG_PROFILING=y +CONFIG_OPROFILE=y +CONFIG_KPROBES=y +CONFIG_JUMP_LABEL=y +CONFIG_MODULES=y +CONFIG_MODULE_FORCE_LOAD=y +CONFIG_MODULE_UNLOAD=y +CONFIG_BLK_CMDLINE_PARSER=y +CONFIG_ARCH_MXC=y +CONFIG_SOC_LS1021A=y +CONFIG_ARM_LPAE=y +CONFIG_PCI=y +CONFIG_PCI_MSI=y +CONFIG_SMP=y +CONFIG_VMSPLIT_2G=y +CONFIG_ARM_PSCI=y +CONFIG_PREEMPT_VOLUNTARY=y +CONFIG_AEABI=y +CONFIG_HIGHMEM=y +CONFIG_CLEANCACHE=y +CONFIG_FRONTSWAP=y +CONFIG_CMDLINE="console=ttyS0,115200" +CONFIG_VFP=y +CONFIG_NEON=y +CONFIG_KERNEL_MODE_NEON=y +CONFIG_BINFMT_MISC=y +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_UNIX_DIAG=y +CONFIG_XFRM_USER=y +CONFIG_NET_KEY=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_MROUTE=y +CONFIG_INET_AH=y +CONFIG_INET_ESP=y +CONFIG_INET_IPCOMP=y +CONFIG_INET_UDP_DIAG=m +CONFIG_NETFILTER=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_ADV_OPTIONS=y +CONFIG_MTD_CFI_BE_BYTE_SWAP=y +CONFIG_MTD_CFI_GEOMETRY=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_CFI_STAA=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_NAND=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_SIZE=256000 +CONFIG_BLK_DEV_SD=y +CONFIG_CHR_DEV_SG=y +CONFIG_ATA=y +CONFIG_NETDEVICES=y +CONFIG_GIANFAR=y +CONFIG_VITESSE_PHY=y +CONFIG_BROADCOM_PHY=y +CONFIG_REALTEK_PHY=y +CONFIG_NATIONAL_PHY=y +CONFIG_MICREL_PHY=y +CONFIG_MDIO_BUS_MUX_MMIOREG=y +CONFIG_INPUT_EVDEV=y +CONFIG_SERIO_SERPORT=m +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_SHARE_IRQ=y +CONFIG_SERIAL_OF_PLATFORM=y +CONFIG_SERIAL_FSL_LPUART=y +CONFIG_SERIAL_FSL_LPUART_CONSOLE=y +CONFIG_HW_RANDOM=y +CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y +CONFIG_I2C_MUX=y +CONFIG_I2C_MUX_PCA954x=y +CONFIG_I2C_IMX=y +CONFIG_SPI=y +CONFIG_SPI_FSL_DSPI=y +CONFIG_GPIO_SYSFS=y +CONFIG_SENSORS_LM90=y +CONFIG_SENSORS_INA2XX=y +CONFIG_WATCHDOG=y +CONFIG_IMX2_WDT=y +CONFIG_REGULATOR=y +CONFIG_REGULATOR_DEBUG=y +CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_SOUND=y +# CONFIG_SOUND_OSS_CORE_PRECLAIM is not set +CONFIG_SND=y +CONFIG_SND_MIXER_OSS=y +CONFIG_SND_PCM_OSS=y +# CONFIG_SND_ARM is not set +CONFIG_SND_SOC=y +CONFIG_SND_SOC_FSL_SAI=y +CONFIG_SND_SOC_SGTL5000=y +CONFIG_SND_SIMPLE_CARD=y +CONFIG_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_PLTFM=y +CONFIG_MMC_SDHCI_OF_ARASAN=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_DS3232=y +CONFIG_DMADEVICES=y +CONFIG_FSL_EDMA=y +CONFIG_CLK_QORIQ=y +CONFIG_MEMORY=y +CONFIG_EXT2_FS=y +CONFIG_EXT2_FS_XATTR=y +CONFIG_EXT3_FS=y +CONFIG_FANOTIFY=y +CONFIG_ISO9660_FS=m +CONFIG_JOLIET=y +CONFIG_ZISOFS=y +CONFIG_UDF_FS=m +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_NTFS_FS=m +CONFIG_TMPFS=y +CONFIG_TMPFS_POSIX_ACL=y +CONFIG_JFFS2_FS=y +CONFIG_NFS_FS=y +CONFIG_NFS_V4=y +CONFIG_ROOT_NFS=y +CONFIG_NLS_DEFAULT="cp437" +CONFIG_NLS_CODEPAGE_437=y +CONFIG_NLS_ASCII=y +CONFIG_NLS_ISO8859_1=y +CONFIG_NLS_ISO8859_2=y +CONFIG_NLS_ISO8859_15=y +CONFIG_NLS_UTF8=y +CONFIG_DEBUG_SECTION_MISMATCH=y +CONFIG_MAGIC_SYSRQ=y +CONFIG_CRYPTO_LZO=y +CONFIG_CRC_CCITT=m +CONFIG_CRC_T10DIF=y +CONFIG_CRC7=m +CONFIG_LIBCRC32C=m