cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Participant
Participant
593 Views
Registered: ‎07-06-2018

eFuse suddenly required

I have an existing design that I've been using for a couple of years. Using a new workstation I made a small change to the design and rebuilt BOOT.bin from it, and now when I boot I receive the following error:

U-Boot 2014.07-dirty (Nov 20 2014 - 17:07:55)

Board:  Xilinx Zynq
I2C:   ready
DRAM:  ECC disabled 1 GiB
MMC:   zynq_sdhci: 0
SF: Detected N25Q128A with page size 256 Bytes, erase size 64 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   Gem.e000b000
Hit any key to stop autoboot:  0
Device: zynq_sdhci
Manufacturer ID: 3
OEM: 5344
Name: SS08G
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 7.4 GiB
Bus Width: 4-bit
reading uEnv.txt
415 bytes read in 8 ms (49.8 KiB/s)
Loaded environment from uEnv.txt
Importing environment from SD ...
Running uenvcmd ...
Copying Linux from SD to RAM...
reading uImage
4109416 bytes read in 420 ms (9.3 MiB/s)
reading devicetree.dtb
22770 bytes read in 37 ms (600.6 KiB/s)
reading uramdisk.image.gz
** Unable to read file uramdisk.image.gz **
## Booting kernel from Legacy Image at 03000000 ...
   Image Name:   Linux-4.9.0-g2398d50
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4109352 Bytes = 3.9 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a00000
   Booting using the fdt blob at 0x2a00000
   Loading Kernel Image ... OK
   Loading Device Tree to 1fff7000, end 1ffff8f1 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.9.0-g2398d50 (jenkins@romlx1) (gcc version 6.2.1 20161114 (Linaro GCC Snapshot 6.2-2016.11) ) #189 SMP PREEMPT Tue Jun 26 09:52:32 IST 2018
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt:Machine model: Xilinx Zynq ZC702
bootconsole [earlycon0] enabled
cma: Reserved 480 MiB at 0x01c00000
Memory policy: Data cache writealloc
percpu: Embedded 13 pages/cpu @ef6dc000 s23564 r8192 d21492 u53248
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260608
Kernel command line: console=ttyPS0,115200 cma=480M root=/dev/mmcblk0p2 rw earlyprintk rootfstype=ext4 rootwait
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 538232K/1048576K available (5603K kernel code, 242K rwdata, 2208K rodata, 256K init, 154K bss, 18824K reserved, 491520K cma-reserved, 262144K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
    lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc0580f0c   (5604 kB)
      .init : 0xc07d2000 - 0xc0812000   ( 256 kB)
      .data : 0xc0812000 - 0xc084ea80   ( 243 kB)
       .bss : 0xc084ea80 - 0xc08753b4   ( 155 kB)
Preemptible hierarchical RCU implementation.
        Build-time adjustment of leaf fanout to 32.
        RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
zynq_early_efuse_init: no efuse node found
------------[ cut here ]------------
kernel BUG at arch/arm/mach-zynq/efuse.c:59!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-g2398d50 #189
Hardware name: Xilinx Zynq Platform
task: c0817b00 task.stack: c0812000
PC is at zynq_early_efuse_init+0x34/0x8c
LR is at zynq_early_efuse_init+0x34/0x8c
pc : [<c07db0a4>]    lr : [<c07db0a4>]    psr: 200000d3
sp : c0813fa8  ip : 00000000  fp : 00000000
r10: effffd00  r9 : c0800a30  r8 : c084ea80
r7 : ffffffff  r6 : c0815000  r5 : c084ea80  r4 : 00000000
r3 : c0812000  r2 : 00000001  r1 : 600000d3  r0 : 0000002a
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment none
Control: 18c5387d  Table: 0000404a  DAC: 00000051
Process swapper/0 (pid: 0, stack limit = 0xc0812210)
Stack: (0xc0813fa8 to 0xc0814000)
3fa0:                   c0800a20 c07db008 c0800a20 c07d532c 00000000 c07d2b20
3fc0: ffffffff ffffffff 00000000 c07d2678 00000000 c0800a30 c084ed14 c0815018
3fe0: c0800a2c c0818ce8 0000406a 413fc090 00000000 0000807c 00000000 00000000
[<c07db0a4>] (zynq_early_efuse_init) from [<c07db008>] (zynq_irq_init+0x8/0x14)
[<c07db008>] (zynq_irq_init) from [<c07d532c>] (init_IRQ+0x2c/0x88)
[<c07d532c>] (init_IRQ) from [<c07d2b20>] (start_kernel+0x24c/0x394)
[<c07d2b20>] (start_kernel) from [<0000807c>] (0x807c)
Code: e3020ae4 e34c1058 e34c006f ebe3390e (e7f001f2)
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task!

I looked this up and saw a solution was to add eFuse to the device tree: 

efuse@f800d000 {
                        compatible = "xlnx,zynq-efuse";
                        reg = <0xf800d000 0x20>;
                };

I put this into the amba section of the device tree and I could boot, but then some of the drivers for the custom IP blocks that I didn't change stop working.

If I go back to my old BOOT.bin and devicetree.dts files that do not contain the efuse entry they work fine. When I check the Security tab in Create Boot Image in XSDK the Authentication and Encryption boxes are both unchecked. I don't plan on using the eFuse feature at the moment. Is there a setting somewhere I can change so that I just don't need this entry anymore? 

All work was done with Vivado/XSDK 2016.2

Tags (3)
0 Kudos
1 Reply
Highlighted
Visitor
Visitor
296 Views
Registered: ‎02-05-2019

Re: eFuse suddenly required

I ran into this today as well when upgrading the kernel. The problem was introduced by b3db0598f8ec ("ARM: zynq: Add support for Zynq-7000S devices") and there is no way to get around it than providing the efuse entry you mentioned (apart from changing the code). IMHO this is a bug and the code should simply return instead of ooopsing. This can be accomplished by changing the BUG in the error case of of_find_compatible_node to simply return (I'd use -1 but it is not checked anyway).

Oh, there is already a pull request for this very issue that was ignored by Xilinx for months: https://github.com/Xilinx/linux-xlnx/pull/128

Thanks for wasting hours of my lifetime (again), xilinx. Can't wait till you get replaced by a company that understands FOSS.

0 Kudos