Jump to content

U-Boot: Error: “autodetectfdt” not defined


mthmulders

Recommended Posts

Hi all,

 

After years of running Armbian on my Cubox i4 without problems, I am suddenly in a situation that I don't understand. For some reason, I decided to reboot it, and now it doesn't work anymore. Using a micro-USB cable and my Macbook, I connected to the serial line to grab some logging:


 

U-Boot SPL 2017.11-armbian (Jan 24 2018 - 22:39:16)
Trying to boot from MMC1


U-Boot 2017.11-armbian (Jan 24 2018 - 22:39:16 +0100)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 41C
Reset cause: POR
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

auto-detected panel HDMI
Display: HDMI (1024x768)
In:    serial
Out:   serial
Err:   serial
Net:   FEC
starting USB...
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
907 bytes read in 98 ms (8.8 KiB/s)
## Executing script at 12000000
## Error: "autodetectfdt" not defined
** File not found /boot/dtb/ **
** Unrecognized filesystem type **
** File not found /dtb/ **
5783761 bytes read in 483 ms (11.4 MiB/s)
5546904 bytes read in 427 ms (12.4 MiB/s)
## Loading init Ramdisk from Legacy Image at 14800000 ...
Image Name:   uInitrd
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:    5783697 Bytes = 5.5 MiB
Load Address: 00000000
Entry Point:  00000000
Verifying Checksum ... OK

I suspect that ## Error: "autodetectfdt" not defined is the culprit. Is there a way I can solve this? I would prefer not to flash the micro-SD, since it contains quite some data I'd like to preserve...

Link to comment
Share on other sites

Try this. Insert SD card on some Linux computer and flash attached files:

dd if=SPL of=/dev/SD_CARD_DEVICE bs=512 seek=2 status=noxfer
dd if=u-boot.img of=/dev/SD_CARD_DEVICE bs=1K seek=42 status=noxfer

 

Make sure you flash SDcard and not your hard drive. Device name on your computer will be something like /dev/sdb or /sdbc ... 

SPL

u-boot.img

Link to comment
Share on other sites

Thanks for the reply! I've modified the commands a bit since the version of dd on my Macbook doesn't know/support them:

sudo dd if=SPL of=/dev/disk3 bs=512 seek=2
78+0 records in
78+0 records out
39936 bytes transferred in 0.004992 secs (7999987 bytes/sec)

sudo dd if=u-boot.img of=/dev/disk3 bs=1024 seek=42
235+1 records in
235+1 records out
240776 bytes transferred in 0.019943 secs (12073209 bytes/sec)

 

But to no avail... Re-inserting the microSD in the Cubox, I still have

## Executing script at 12000000
## Error: "autodetectfdt" not defined
** File not found /boot/dtb/ **
** Unrecognized filesystem type **
** File not found /dtb/ **

 

Link to comment
Share on other sites

It might be completely wrong... But I noticed a definition for autodetect on GitHub. Imagine I would do the following:

  • drop to the U-Boot prompt
  • give this command:
    setenv autodetectfdt "if test ${cpu} = 6SOLO || test ${cpu} = 6DL; then setenv fdt_prefix imx6dl; else setenv fdt_prefix imx6q; fi; if test ${board} = mx6-cubox-i; then setenv fdt_file ${fdt_prefix}-cubox-i.dtb; else setenv fdt_file ${fdt_prefix}-hummingboard.dtb; fi;"
  • give this command:
    saveenv
  • reboot

... would that work? Or would it just completely mess up my U-Boot? ;-)

Link to comment
Share on other sites

Well, this is interesting... The autodetectfdt-related error is gone, but now I have this:

Found U-Boot script /boot/boot.scr
907 bytes read in 98 ms (8.8 KiB/s)
## Executing script at 12000000
** File not found /boot/dtb/-hummingboard.dtb **
** Unrecognized filesystem type **
** File not found /dtb/-hummingboard.dtb **
5783761 bytes read in 483 ms (11.4 MiB/s)
5546904 bytes read in 427 ms (12.4 MiB/s)
## Loading init Ramdisk from Legacy Image at 14800000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    5783697 Bytes = 5.5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
SCRIPT FAILED: continuing...
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part 
No port device detected!

Device 0: Model:  Firm:  Ser#: 
            Type: Hard Disk
            Capacity: not available
... is now current device
** Bad device size - sata 0 **
starting USB...
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: device type unknown
... is now current device
** Bad device usb 0 **
** Bad device usb 0 **
FEC Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY FEC
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3

It still says it doesn't have a flattened device tree (I hoped that having autodetectfdt would create the flattened device tree), but it seems I was wrong there. Any other thoughts, maybe?

Link to comment
Share on other sites

Well, good news: my Cubox is booting again! Thanks again for the support, Igor. Here's what I did:

 

I looked at the definition of autodetectfdt that I mentioned earlier. I saw it sets two other variables: fdt_prefix and fdt_file. I figured out their values based on the results of printenv cpu and printenv board.

Then I booted the Cubox with a micro-USB cable attached and stopped autoboot. I gave the following commands:

setenv fdt_prefix imx6q
setenv fdt_file ${fdt_prefix}-cubox-i.dtb
setenv autodetectfdt "if test ${cpu} = 6SOLO || test ${cpu} = 6DL; then setenv fdt_prefix imx6dl; else setenv fdt_prefix imx6q; fi; if test ${board} = mx6-cubox-i; then setenv fdt_file ${fdt_prefix}-cubox-i.dtb; else setenv fdt_file ${fdt_prefix}-hummingboard.dtb; fi;"
saveenv

Then the autoboot succeeded and I was able to log in, over the serial line. So I could upgrade U-Boot to 5.44 and reboot again. The system now boots fine!

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines