Custom u-boot configuration fails to initialize timer (err 19)

General Discussion
21

Okay, I tested it on my Beagle Bone Black, and it works fine. So w/e the issue is, it’s related to how the OSD335x board is configured at boot.

1 Like
22

I do half think that @RobertCNelson was on the right track - that its a time issue early in uboot. Myself I don’t have this on my pocket beagle, my uboot was done when the PB first came out - based on mainstream 2018-03, but with this patch from @jkridner [U-Boot] [PATCH 1/4] Add support for BeagleBoard.org PocketBeagle . So I probably didn’t have @RobertCNelson patch above, and I was lucky my machine boots with out it.

The link you have shown from your u-boot, shows you already that the &timer2 - when you expand that out its what you get. This timer you get from am33xx-l4.dtsi - I’m at a loss as what you can change there - can’t change voltage or frequency, so all I can think is change the clock from <&timer2_fck> …

Really this is getting quite complex, and to my mind it will be tricky to fix.

23

I’m almost certain the fix has already been mentioned in the thread. I’m tabling my fix for the moment to work on more urgent issues, but I was able to work around my bug by using Robert’s port of u-boot (here).

There is probably something that our fork does that his doesn’t. Implementing those changes may fix it, but there’s also the issue that our fork is of mainline u-boot 2024.

I’m also hesitant to manipulate any of the dtsi’s. In my mind, those should be managed by TI, so any changes should come from upstream. It is unlikely I will discover any new bugs there, but if I did, I would suggest a patch.

24

One thing that still confuses me: when does u-boot load its device tree? There is a macro findfdt that is used in the bootcmd, but this doesn’t run until sometime after I drop into the initial console.

u-boot has something called the “control fdt”. Their wiki mentions this.

The control FDT is the one used by U-Boot itself to control various features, including driver model. This should only be changed if you really know what you are doing, since once U-Boot starts it maintains pointers into the FDT from the various driver model data structures.

I suppose that this is really the FDT I should care about in this case, but I haven’t found much information on how the control device tree is loaded or how to debug it.

My current assumption is that u-boot uses the KCONFIG to select the default device tree (CONFIG_DEFAULT_DEVICE_TREE) and supporting device trees (CONFIG_OF_LIST). These are compiled with u-boot. And are probably selected by the findfdt script. But when does that run? Some time after dropping into the initial console, so which device tree is used by SPL and u-boot prior to running that script?

25

My beagle board uses arch - and in the boot drive it loads a script to run:

if test -n ${distro_bootpart}; then setenv bootpart ${distro_bootpart}; else setenv bootpart 1; fi
part uuid ${devtype} ${devnum}:${bootpart} uuid

setenv bootargs "console=tty0 console=${console} root=PARTUUID=${uuid} rw rootwait"

if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/zImage; then
  gpio set 54
  echo fdt: ${fdtfile}
  if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
    gpio set 55
    fdt addr ${fdt_addr_r}
#    if load ${devtype} ${devnum}:${bootpart} 0x88060000 /lib/firmware/AM3359-PWM012.dtbo; then
#      fdt resize ${filesize}
#      fdt apply 0x88060000
#      fdt resize
#    fi;
    if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
      gpio set 56
      bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
    else
      gpio set 56
      bootz ${kernel_addr_r} - ${fdt_addr_r};
    fi;
  fi;
fi

And you can see how that loads kernel, device tree and bits like that. Device tree commented out - becuase in the last device tree, something changed, so my overlay doesn’t apply cleanly - so I’ve disabled it.

1 Like