[U-Boot] Linux kernel hang with FDT changes
Hi, I am using customized ppc440 based board. We have created a .dtb file, u-boot should not update the file because of that we have added following macro in config file #define CONFIG_OF_LIBFDT 1 #undef CONFIG_OF_BOARD_SETUP With the above change kernel code gets hang with following log:
Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00030000 MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 195072 Kernel command line: PID hash table entries: 4096 (order: 12, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 755584k/786432k available (1860k kernel code, 30508k reserved, 112k data , 60k bss, 116k init) Kernel virtual memory layout: * 0xffffe000..0xfffff000 : fixmap * 0xfde00000..0xfe000000 : consistent mem * 0xfddfe000..0xfde00000 : early ioremap * 0xf1000000..0xfddfe000 : vmalloc & ioremap SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS:512 UIC0 (32 IRQ sources) at DCR 0x20 UIC1 (32 IRQ sources) at DCR 0x30 UIC1 (32 IRQ sources) at DCR 0x60
When we debug the u-boot code by added the following flag #define CONFIG_OF_BOARD_SETUP 1 Kernel works fine. Is there any dependency of CONFIG_OF_BOARD_SETUP flag for .dtb file?
Ronny
Hi Ronny,
On Monday 14 June 2010 12:00:38 Ronny D wrote:
I am using customized ppc440 based board.
BTW: Do you plan to send the U-Boot changes to the mailing list and some time?
We have created a .dtb file, u-boot should not update the file because of that we have added following macro in config file #define CONFIG_OF_LIBFDT 1 #undef CONFIG_OF_BOARD_SETUP
With the above change kernel code gets hang with following log:
Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00030000 MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 195072 Kernel command line: PID hash table entries: 4096 (order: 12, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 755584k/786432k available (1860k kernel code, 30508k reserved, 112k data , 60k bss, 116k init) Kernel virtual memory layout:
- 0xffffe000..0xfffff000 : fixmap
- 0xfde00000..0xfe000000 : consistent mem
- 0xfddfe000..0xfde00000 : early ioremap
- 0xf1000000..0xfddfe000 : vmalloc & ioremap
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS:512 UIC0 (32 IRQ sources) at DCR 0x20 UIC1 (32 IRQ sources) at DCR 0x30 UIC1 (32 IRQ sources) at DCR 0x60
When we debug the u-boot code by added the following flag #define CONFIG_OF_BOARD_SETUP 1 Kernel works fine.
Is there any dependency of CONFIG_OF_BOARD_SETUP flag for .dtb file?
With CONFIG_OF_BOARD_SETUP defined, the function ft_board_setup() will be called to modify the dtb before passing it to the Linux kernel. I suggest you check the code to see, what exactly gets changed/patched by this routine.
Cheers, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
Hi Ronny,
Just adding to Stefan's comments...
On Mon, 2010-06-14 at 13:27 +0200, Stefan Roese wrote:
Hi Ronny,
On Monday 14 June 2010 12:00:38 Ronny D wrote:
I am using customized ppc440 based board.
BTW: Do you plan to send the U-Boot changes to the mailing list and some time?
We have created a .dtb file, u-boot should not update the file because of that we have added following macro in config file #define CONFIG_OF_LIBFDT 1 #undef CONFIG_OF_BOARD_SETUP
Is there a reason you *don't* want the board setup to run?
With the above change kernel code gets hang with following log:
Without the fixup, linux hangs.
[snip]
When we debug the u-boot code by added the following flag #define CONFIG_OF_BOARD_SETUP 1 Kernel works fine.
Is there any dependency of CONFIG_OF_BOARD_SETUP flag for .dtb file?
With the fixup, it works.
In all cases I'm aware of, the fixup is a *good* thing. Check the source to see what is being fixed up. The evidence is pretty clear that you want the fixup.
With CONFIG_OF_BOARD_SETUP defined, the function ft_board_setup() will be called to modify the dtb before passing it to the Linux kernel. I suggest you check the code to see, what exactly gets changed/patched by this routine.
...and it is a good thing to run unless you have specific reasons not to run it. If you really don't want to run the fixup, it is indicating you have a problem with your DTB (DTS) that you will have to figure out. As Stefan points out, the answer lies in the fixup code vs. your DTB.
Cheers, Stefan
Best regards, gvb
Thanks jerry i verified the fdt fixup code and found problem with my DTB creation. By adding fixup for timebase-frequency in DTB kernel works fine. -Ronny
--- On Wed, 16/6/10, Jerry Van Baren gvb.uboot@gmail.com wrote:
From: Jerry Van Baren gvb.uboot@gmail.com Subject: Re: [U-Boot] Linux kernel hang with FDT changes To: "Ronny D" ronny_d37@yahoo.com Cc: "Stefan Roese" sr@denx.de, "U-boot" u-boot@lists.denx.de Date: Wednesday, 16 June, 2010, 3:01 AM
Hi Ronny,
Just adding to Stefan's comments...
On Mon, 2010-06-14 at 13:27 +0200, Stefan Roese wrote:
Hi Ronny,
On Monday 14 June 2010 12:00:38 Ronny D wrote:
I am using customized ppc440 based board.
BTW: Do you plan to send the U-Boot changes to the mailing list and some time?
We have created a .dtb file, u-boot should not update the file because of that we have added following macro in config file #define CONFIG_OF_LIBFDT 1 #undef CONFIG_OF_BOARD_SETUP
Is there a reason you *don't* want the board setup to run?
With the above change kernel code gets hang with following log:
Without the fixup, linux hangs.
[snip]
When we debug the u-boot code by added the following flag #define CONFIG_OF_BOARD_SETUP 1 Kernel works fine. Is there any dependency of CONFIG_OF_BOARD_SETUP flag for .dtb file?
With the fixup, it works.
In all cases I'm aware of, the fixup is a *good* thing. Check the source to see what is being fixed up. The evidence is pretty clear that you want the fixup.
With CONFIG_OF_BOARD_SETUP defined, the function ft_board_setup() will be called to modify the dtb before passing it to the Linux kernel. I suggest you check the code to see, what exactly gets changed/patched by this routine.
...and it is a good thing to run unless you have specific reasons not to run it. If you really don't want to run the fixup, it is indicating you have a problem with your DTB (DTS) that you will have to figure out. As Stefan points out, the answer lies in the fixup code vs. your DTB.
Cheers, Stefan
Best regards, gvb
I compared ft_board_setup() body with my .dts file for missing parameters, difference was timebase-frequency. I have updated .dts file with the timebase-frequency parameter. Now working fine Thanks. Ronny
--- On Mon, 14/6/10, Stefan Roese sr@denx.de wrote:
From: Stefan Roese sr@denx.de Subject: Re: Linux kernel hang with FDT changes To: "Ronny D" ronny_d37@yahoo.com Cc: "U-boot" u-boot@lists.denx.de Date: Monday, 14 June, 2010, 11:27 AM
Hi Ronny,
On Monday 14 June 2010 12:00:38 Ronny D wrote:
I am using customized ppc440 based board.
BTW: Do you plan to send the U-Boot changes to the mailing list and some time?
We have created a .dtb file, u-boot should not update the file because of that we have added following macro in config file #define CONFIG_OF_LIBFDT 1 #undef CONFIG_OF_BOARD_SETUP With the above change kernel code gets hang with following log:
Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00030000 MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 195072 Kernel command line: PID hash table entries: 4096 (order: 12, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 755584k/786432k available (1860k kernel code, 30508k reserved, 112k data , 60k bss, 116k init) Kernel virtual memory layout: * 0xffffe000..0xfffff000 : fixmap * 0xfde00000..0xfe000000 : consistent mem * 0xfddfe000..0xfde00000 : early ioremap * 0xf1000000..0xfddfe000 : vmalloc & ioremap SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS:512 UIC0 (32 IRQ sources) at DCR 0x20 UIC1 (32 IRQ sources) at DCR 0x30 UIC1 (32 IRQ sources) at DCR 0x60
When we debug the u-boot code by added the following flag #define CONFIG_OF_BOARD_SETUP 1 Kernel works fine. Is there any dependency of CONFIG_OF_BOARD_SETUP flag for .dtb file?
With CONFIG_OF_BOARD_SETUP defined, the function ft_board_setup() will be called to modify the dtb before passing it to the Linux kernel. I suggest you check the code to see, what exactly gets changed/patched by this routine.
Cheers, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
participants (3)
-
Jerry Van Baren -
Ronny D -
Stefan Roese