[PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Alison Wang]

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.

Enable I2C, LPUART, eDMA, WDT, GIANFAR, Sound, DSPI at default.

Signed-off-by: Haikun Wang <haikun.wang@freescale.com>
Signed-off-by: Alison Wang <alison.wang@freescale.com>
---
Changes since v3:
- Modify the commit.
Changes since v2:
- Enable PSCI, as PSCI is enabled in u-boot.
Changes since v1:
- Enable GIANFAR, Sound and DSPI.

 arch/arm/configs/ls1021a_defconfig | 160 +++++++++++++++++++++++++++++++++++++
 1 file changed, 160 insertions(+)
 create mode 100644 arch/arm/configs/ls1021a_defconfig

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
-- 
2.1.0.27.g96db324

Re: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Russell King - ARM Linux]

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.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Huan Wang]

> 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

Re: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Fabio Estevam]

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?

RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Huan Wang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 777 bytes --]

> 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
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Arnd Bergmann]

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

RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Huan 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.
> 
[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

Re: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Arnd Bergmann]

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

RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Huan 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?
> 
[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

Re: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Arnd Bergmann]

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

RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Huan Wang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 2627 bytes --]

> 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
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Arnd Bergmann]

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

RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

[Huan 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.
[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