OSD335x C-SiP, bootloader issues

Hi Neeraj,

I’m starting to think that the issue has little to do with the EEPROM detection, I ran a side by side capture (Beaglebone Blue vs OSD) of I2C0, and the data captured during EEPROM transfers is exactly the same, the OSD appears to halt right before starting to deal with the device at address 0x48 (0x24 7b PMIC).
Find attached the spreadsheet (maybe you guys can spot some irregularity there).

Both boards are running (swapping sd from one to other) the same SD card. I have a couple of them just to see if there are any variations. One card with version 7.5 and other with the latest image 9.5 from beagleboard.

BTW: I had already tried coding different combos of board/version based on the contents of board.h inside u-boot source… Damn it, this things are frustrating!

Okay, that took a while and several DDings but I found part of the issue. Our board runs without the 32K RTC clock, and the SPL was freezing while executing this (note the commented lines):

#if defined(CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC)
static void rtc32k_enable(void)
{
struct davinci_rtc *rtc = (struct davinci_rtc *)RTC_BASE;

/*
* Unlock the RTC’s registers. For more details please see the
* RTC_SS section of the TRM. In order to unlock we need to
* write these specific values (keys) in this order.
*/
//writel(RTC_KICK0R_WE, &rtc->kick0r); <– COMMENTED
//writel(RTC_KICK1R_WE, &rtc->kick1r); <– COMMENTED

/* Enable the RTC 32K OSC by setting bits 3 and 6. */
//writel((1 << 3) | (1 << 6), &rtc->osc); <– COMMENTED
}

I guess it waits for a sync bit or something like that and just stays there forever. Note I commented the lines because I was unable to deselect this option from the menuconfig, looks like it’s a “standard” option. I don’t know if not initializing the RTC will have other repercussions….

Anyway, from that point on, I was able to properly load the SPL and finally to load u-boot!!! Great news after several days sitting in front of a bunch of “CCCCCCCCCCCCCCCCCC”

My joy lasted for 10-20ms, when an exeption rebooted the board. Narrowing down, it looks like some issue while loading stored variables in some nvs (I have no clue where they are actually stored).

Commenting this lines allowed u-boot to continue doing it’s thing:

‘/common/autoboot.c’

#ifdef CONFIG_BOOTCOUNT_LIMIT //CRASH HERE!!
//bootcount = bootcount_load(); <– COMMENTED
bootcount = 0; //Patch <– ADDED
bootcount++;
//bootcount_store(bootcount); <– COMMENTED
env_set_ulong(“bootcount”, bootcount);
bootlimit = env_get_ulong(“bootlimit”, 10, 0);

Now I can get up to the “starting kernel” message, where the board freezes…again…, but I guess it has something to do with not loading the kernel image/fdt ot overlapping kernel image/fdt file. I have attached a full print from the sequence. Any more ideas?

***********************************************************************
U-Boot SPL 2018.01 – MEDEA NO RTC32K – -dirty (Jun 05 2019 – 17:19:22)
Trying to boot from MMC1

U-Boot 2018.01-dirty (Jun 05 2019 – 17:16:24 +0200)

I2C: ready
DRAM: 512 MiB
No match for driver ‘omap_hsmmc’
No match for driver ‘omap_hsmmc’
Some drivers were not found
****BOARD INIT****.
Reset Source: Global external warm reset has occurred.
Reset Source: watchdog reset has occurred.
Reset Source: Power-on reset has occurred.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

****LATE INIT****.
Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
****LATE INIT DONE****.
Net: eth0: MII MODE
Could not get PHY for cpsw: addr 0
cpsw, usb_ether
****U BOOT MAIN LOOP****.
CLI init
CLI init done
preboot cmd
preboot cmd done
bootdelay_process
bootdelay process done
autoboot cmd
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] …
board_rev=[00C0] …
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Bad device 0:2 0x82000000 **
** Bad device 0:2 0x82000000 **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1…
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt …
Checking for: /boot.scr …
Checking for: /boot/boot.scr …
Checking for: /boot/uEnv.txt …
gpio: pin 55 (gpio 55) value is 1
2099 bytes read in 37 ms (54.7 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt…
gpio: pin 56 (gpio 56) value is 1
Running uname_boot …
loading /boot/vmlinuz-4.14.67-ti-r73 …
10379776 bytes read in 683 ms (14.5 MiB/s)
loading /boot/dtbs/4.14.67-ti-r73/am335x-boneblack.dtb …
60317 bytes read in 53 ms (1.1 MiB/s)
loading /boot/initrd.img-4.14.67-ti-r73 …
4530411 bytes read in 321 ms (13.5 MiB/s)
debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet] …
debug: [bootz 0x82000000 0x88080000:4520eb 0x88000000] …
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Ramdisk to 8fbad000, end 8ffff0eb … OK
Loading Device Tree to 8fb9b000, end 8fbacb9c … OK

Starting kernel …

Neeraj you are the man!

After the proposed shanges I was able to boot the kernel and – finally – see some real progress, thanks!

I’ve been playing around with the system and seems stable, but I have a couple major things that do not work, the WL1831 module and the USB interface to a cellular modem.

Debugging steps taken for the WL1831:

– Verify power rails (ok)
– Verify 32.768khz clock (ok)
– Verify mii1_txd0 // BT ena(HIGH)
– Verify mii1_tx_clk //WL ena(LOW)!
– Verify kernel module is loaded (lsmod) seems consistent with the output of lsmod on a working beaglebone blue

Module: Size: USED by:
wl18xx 110592 0
wlcore 237568 1 wl18xx

I can observe few clock bursts at 400KHz on mii1_rxd1 (sdio clock to wl module) during boot (I guess it’s trying to initialize the “card”), nothing on uart3 tx/rx. I have tested the same image on our board and on the Beaglebone Blue,
and the wireless module works OK on the BBBlue. I can see both enable signals going high and activity on both uart and sdio buses.

There are some warings thrown by the dtb rebuilder at compilation, maybe it has something to do see the attached files (if you feel like testing it yourself). I have moved away all the other .dts files.

dtb rebuilder make:

DTC src/arm/am335x-boneblue.dtb
src/arm/am335x-boneblue.dtb: Warning (unit_address_format): Node /ocp/epwmss@48300000/eqep@0x48300180 unit name should not have leading “0x”
src/arm/am335x-boneblue.dtb: Warning (unit_address_format): Node /ocp/epwmss@48302000/eqep@0x48302180 unit name should not have leading “0x”
src/arm/am335x-boneblue.dtb: Warning (unit_address_format): Node /ocp/epwmss@48304000/eqep@0x48304180 unit name should not have leading “0x”
src/arm/am335x-boneblue.dtb: Warning (simple_bus_reg): Node /ocp/l4_wkup@44c00000/scm@210000/scm_conf@0/clocks missing or empty reg/ranges property
src/arm/am335x-boneblue.dtb: Warning (simple_bus_reg): Node /ocp/l4_wkup@44c00000/scm@210000/clockdomains missing or empty reg/ranges property
src/arm/am335x-boneblue.dtb: Warning (simple_bus_reg): Node /ocp/mailbox@480C8000 simple-bus unit address format error, expected “480c8000”
src/arm/am335x-boneblue.dtb: Warning (simple_bus_reg): Node /ocp/mcasp@4803C000 simple-bus unit address format error, expected “4803c000”
src/arm/am335x-boneblue.dtb: Warning (simple_bus_reg): Node /ocp/P9_19_pinmux missing or empty reg/ranges property
src/arm/am335x-boneblue.dtb: Warning (simple_bus_reg): Node /ocp/P9_20_pinmux missing or empty reg/ranges property
src/arm/am335x-boneblue.dtb: Warning (simple_bus_reg): Node /ocp/cape-universal missing or empty reg/ranges property
src/arm/am335x-boneblue.dtb: Warning (phys_property): Missing property ‘#phy-cells’ in node /ocp/usb@47400000/usb-phy@47401300 or bad phandle (referred from /ocp/usb@47400000/usb@47401000:phys[0])
src/arm/am335x-boneblue.dtb: Warning (phys_property): Missing property ‘#phy-cells’ in node /ocp/usb@47400000/usb-phy@47401b00 or bad phandle (referred from /ocp/usb@47400000/usb@47401800:phys[0])

The bluettoth interface does not work either, HCI commands only print the following. Again, no activity on uart3 bus during any of this prints/system boot.
*****
debian@beaglebone:~$ hciconfig version
hci0: Type: Primary Bus: UART
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:16 acl:0 sco:0 commands:4 errors:0
******
And a bunch of errors HCI-related the console throws during startup

[ 36.331871] NET: Registered protocol family 31
[ 36.387606] Bluetooth: HCI device and connection manager initialized
[ 36.467742] Bluetooth: HCI socket layer initialized
[ 36.547568] Bluetooth: L2CAP socket layer initialized
[ 36.611823] Bluetooth: SCO socket layer initialized
[ 37.144555] Bluetooth: HCI UART driver ver 2.3
[ 37.209994] Bluetooth: HCI UART protocol H4 registered
[ 37.346076] Bluetooth: HCI UART protocol LL registered
[ 37.613843] Bluetooth: HCI UART protocol ATH3K registered
[ 37.859176] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 38.037270] Bluetooth: HCI UART protocol QCA registered
[ 38.610466] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 38.633955] Bluetooth: BNEP filters: protocol multicast
[ 38.650961] Bluetooth: BNEP socket layer initialized
[ 39.519578] Bluetooth: hci0 command 0x1001 tx timeout
[ 47.583428] Bluetooth: hci0: Reading TI version information failed (-110)
[ 47.590323] Bluetooth: hci0: download firmware failed, retrying…
[ 49.727424] Bluetooth: hci0 command 0x1001 tx timeout

Regarding the USB interface to the cellular modem, I guess it’s some sort of configuration of the OS, it only lists the root hub and it did create a couple usb-eth adapters via software. Any insights on how to gain control over the USB ports?

Thanks!

Let me attach also the full console prints from reset to linux login.

Hi Neeraj

I’m stuck XD could you please provide the dtb rebuilder folder you used to do the changes please??

Thanks!

Hi Neeraj!

Thanks for the files, I cross checked your changes against mines and they were the same, the issue lied on one silly pull up resitor on the wlan_irq line. Cross checking my schematics against the BBBlue schematics, the pull-up reistor on that particular line is marked as DNP, removing it made the module work 🙂

Again, there’s another issue, I cannot boot from the internal emmc, I executed the emmc flasher script (by uncommenting the variable in /boot/uEnv.txt), and the emmc loads everything correctly, however it does not seem to execute the bootloader upon power-up. If I execute the bootloader from the Sd card and then remove the SD card, the system boots correctly from the emmc.

I tried manually loading the MLO and u-boot.img to mmcblk1 to the same offsets as in the SD but it makes no difference. Any tips there?

To future readers encountering similar issues, I’ve compiled a “guide” outlining the steps to boot the SIP and to disable the RTC nodes. I hope it helps. Neeraj, if it’s not too much to ask, could you please review it?

Thanks!

I cannot attach the file (1.4MB vs 512KB)… I’m sharing the google drive link instead!

https://docs.google.com/document/d/1mLe8aKckKvg9QwjWJkdTg8gPltMKCRK__lkcNBFa6k0/edit

Hi Neeraj,

I had to leave the project aside for a short while, apologies for getting back to you so late.

After carefully checking the OSD_BOOT_SD# upon power up, the line does not appear to be pulled low, however there’s no way I can manage the device to boot from the emmc.

I confirm that the line does make electrical connection to the device itself (pulling high/low does force the device to boot from the SD or from the eMMC), however when the eMMC is selected as boot device i get zip on the UART.

Do you have of any possible (even remote) idea of what might be going on there? We are using the generic eMMC flasher script on the standard beagleboard released images, is there any tweak we need to apply to that script?

Is it possible that the device not booting is in any way related to the changes made in u-boot and device tree?

Thanks,