Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1246500 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig Huan Wang <alison.wang@freescale.com> - 2015-10-14 12:40 +0200
    Re: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig Arnd Bergmann <arnd@arndb.de> - 2015-10-14 15:00 +0200
      RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig Huan Wang <alison.wang@freescale.com> - 2015-10-15 04:20 +0200
        Re: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig Arnd Bergmann <arnd@arndb.de> - 2015-10-15 14:20 +0200

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

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1246688

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1247340

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1247734

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web