Re: [U-Boot-Users] mpc83xx boot error
- You need to use version 17 (simply don't specify -V 0x10).
- As Kim mentioned, you need -S padding to allow extra space for the /chosen node.
- Since you burned the blob into flash, bootm has to relocate the blob to RAM. This is what is giving you the "fdt move failed" error in your first example, it is moving the blob to 0x007fe000 - is this a valid address (seems like it should be)? Perhaps it is simply because you didn't pad it? Perhaps we let a bug slip in?
Oops, I missed the -R 8 that Kim recommended (very correctly). This makes more reserved map entries which is important as well as the -S extra space.
I don't think this fully describes it, I just came across the same error when porting from 1.3.1 to 1.3.2-rc2:
dtc -I dts -O dtb -S 0x3000 -R 8
with dtc 1.1.0
still gives the following when booting u-boot-1.3.2-rc2:
## Booting image at fe700000 ... Image Name: Linux-2.6.24 Created: 2008-02-25 15:38:37 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 930624 Bytes = 908.8 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0xfefe0000 Loading Device Tree to 007fe000, end 007ff4e1 ... OK WARNING: could not create /chosen FDT_ERR_NOSPACE. ERROR: /chosen node create failed - must RESET the board to recover. Resetting the board.
Marc Leeman wrote:
- You need to use version 17 (simply don't specify -V 0x10).
- As Kim mentioned, you need -S padding to allow extra space for the /chosen node.
- Since you burned the blob into flash, bootm has to relocate the blob to RAM. This is what is giving you the "fdt move failed" error in your first example, it is moving the blob to 0x007fe000 - is this a valid address (seems like it should be)? Perhaps it is simply because you didn't pad it? Perhaps we let a bug slip in?
Oops, I missed the -R 8 that Kim recommended (very correctly). This makes more reserved map entries which is important as well as the -S extra space.
I don't think this fully describes it, I just came across the same error when porting from 1.3.1 to 1.3.2-rc2:
dtc -I dts -O dtb -S 0x3000 -R 8
with dtc 1.1.0
still gives the following when booting u-boot-1.3.2-rc2:
## Booting image at fe700000 ... Image Name: Linux-2.6.24 Created: 2008-02-25 15:38:37 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 930624 Bytes = 908.8 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0xfefe0000 Loading Device Tree to 007fe000, end 007ff4e1 ... OK WARNING: could not create /chosen FDT_ERR_NOSPACE. ERROR: /chosen node create failed - must RESET the board to recover. Resetting the board.
Hi Marc,
Hmmm, this is an interesting line:
Loading Device Tree to 007fe000, end 007ff4e1 ... OK
I have not looked who generates this printout, but it seems to indicate the fdt is 0x14e1 in length.
Is the "interesting line" indicating that the blob got moved *and truncated*? If it is being truncated, that would be why it runs out of space creating the /chosen node.
What sort of image/combination are you booting? I'm booting a separate linux image, fdt blob, and RAM disk and my boot sequence looks different, including not having the "Loading Device Tree..." line.
=> tftp $ramdiskaddr $ramdiskfile ; tftp $fdtaddr $fdtfile ; tftp $loadaddr $bootfile UEC: PHY is Marvell 88E11x1 (1410cc2) FSL UEC0: Full Duplex switching to rgmii 100 FSL UEC0: Speed 100BT FSL UEC0: Link is up Using FSL UEC0 device TFTP from server 192.168.47.8; our IP address is 192.168.47.214 Filename 'mpc8360emds/uRamdisk'. Load address: 0x1000000 Loading: T ################################################################# ######################################## done Bytes transferred = 1531127 (175cf7 hex) Using FSL UEC0 device TFTP from server 192.168.47.8; our IP address is 192.168.47.214 Filename 'mpc8360emds/mpc836x_mds.dtb'. Load address: 0x400000 Loading: # done Bytes transferred = 12288 (3000 hex) Using FSL UEC0 device TFTP from server 192.168.47.8; our IP address is 192.168.47.214 Filename 'mpc8360emds/uImage'. Load address: 0x200000 Loading: ################################################################# ########################## done Bytes transferred = 1329289 (144889 hex) => bootm $loadaddr $ramdiskaddr $fdtaddr ## Booting image at 00200000 ... Image Name: Linux-2.6.25-rc3-00001-g5fb74e4- Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1329225 Bytes = 1.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 01000000 ... Image Name: Simple Embedded Linux Framework Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 1531063 Bytes = 1.5 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Booting using the fdt at 0x400000 Loading Ramdisk to 0fe2b000, end 0ffa0cb7 ... OK Using MPC836x MDS machine description Linux version 2.6.25-rc3-00001-g5fb74e4-dirty (vanbaren@dellserver) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #1 Mon Feb 25 20:38:46 EST 2008 Found initrd at 0xcfe2b000:0xcffa0cb7 console [udbg0] enabled setup_arch: bootmem mpc836x_mds_setup_arch() : [snip] : root:~>
Best regards, gvb
I have not looked who generates this printout, but it seems to indicate the fdt is 0x14e1 in length.
My fault: I was loading the wrong dtb file while developing. U-Boot was loading the dtb from the upgrade location, not from the factory location as I assumed it was doing.
tnx.
Hi there,
Does anyone perhaps have SPI code for u-boot for the mpc83xx chips that perhaps needs testing out? :P
Richard
------------------------------------------------------------------------------ Cambridge Broadband Networks Limited
Registered in England and Wales under company number: 03879840 Registered office: Selwyn House, Cambridge Business Park, Cowley Road, Cambridge CB4 0WZ, UK. VAT number: GB 741 0186 64
This email and any attachments are private and confidential. If you believe you have received this email in error please inform the sender and delete it from your mailbox or any other storage mechanism. Cambridge Broadband Networks Limited cannot accept liability for any statements made which are clearly the individual sender's own and not expressly made on behalf of Cambridge Broadband Networks Limited.
Richard Parsons wrote:
Hi there,
Does anyone perhaps have SPI code for u-boot for the mpc83xx chips that perhaps needs testing out? :P
It depends which 83xx chip you're talking about. There's a driver in the tree (mpc8xxx_spi) that works with MPC834x and with a little tweaking should also work on the others in CPU mode. I believe you'd just need to add some code to set SPI up to operate in CPU mode, but don't know for sure.
regards, Ben
------------------------------------------------------------------------------ Cambridge Broadband Networks Limited
Registered in England and Wales under company number: 03879840 Registered office: Selwyn House, Cambridge Business Park, Cowley Road, Cambridge CB4 0WZ, UK. VAT number: GB 741 0186 64
This email and any attachments are private and confidential. If you believe you have received this email in error please inform the sender and delete it from your mailbox or any other storage mechanism. Cambridge Broadband Networks Limited cannot accept liability for any statements made which are clearly the individual sender's own and not expressly made on behalf of Cambridge Broadband Networks Limited.
-----Original Message----- From: Ben Warren [mailto:biggerbadderben@gmail.com] Sent: 28 February 2008 14:41 To: Richard Parsons Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] mpc83xx SPI
Richard Parsons wrote:
Hi there,
Does anyone perhaps have SPI code for u-boot for the mpc83xx chips
that
perhaps needs testing out? :P
It depends which 83xx chip you're talking about. There's a driver in the tree (mpc8xxx_spi) that works with MPC834x and with a little tweaking should also work on the others in CPU mode. I believe you'd just need to add some code to set SPI up to operate in CPU mode, but don't know for sure.
regards, Ben
Thanks, will take a look that side of the tree. I am attacking the mpc8323 processor and really don't feel like re-inventing the wheel :D
Richard Parsons
participants (4)
-
Ben Warren -
Jerry Van Baren -
Marc Leeman -
Richard Parsons