Hmm. Probably worth going over how uboot works, as the background is part of what is discussed here. Assuming that uboot has managed to get running in the first place (an art form in itself) - it then has to work out how to bring up the kernel. Now this is dependent on several factors, for all boards, and the am335x in particular.
E.g. a generic am335x may be booting off MMC chip, or an sD card, these may be wired on certain pins (different for each am335x type), and there may be provisos (early EVM boards and initially you could only access the sD card in 1 bit mode). In particular the am335x pinmux needs to be configured so that which ever pins the mmc/sD is wired to are configured in the am335x to use the part of the chip that handles such devices (e.g. they probably aren’t a general GPIO pin, but have a specific am335x driver).
Now historically uboot would have a different configuration for each board, that would give the configuration needed. Some when in the past (about 2020) there we a lot of am33x boards, each of which in eeprom had a signature for that board. So uboot merged all of these into am335x_env_defconfig. In order to give the different configuration of each of these boards, uboot has a fragment of the device tree in uboot, for all the boards. This fragment gives how the pins need to be accessed for each board. So first uboot identifies the board through the eeprom, then selects the right device tree fragment, and then applies whatever is there for accessing the kernel and deice root.
The uboot loads the kernel, with the right device tree (both taken from the mmc/sd) and boots the machine. Then linux when coming up, does the proper am335x configuration, with the proper device tree.
Why this is relevant, is it sounds like some of the timings, in you case have been messed with. This could be in uboot (so how its identified the board), or in the device tree that uboot tells the kernel to use when it boots (usually it selects the correct one).
You’ll need to identify which of these has been messed with. Has uboot identified the correct board time from the eeprom. Has uboot set the right am335x configuration to load the kernel and device tree? Has uboot selected the right device tree to use?
Each of these could have been messed with in modifying uboot - you’ll need to understand which. The crux is why not use a generic uboot, and the just have it boot the correct device tree, with whatever overlays you need for your particular configuration.