Migration from Beaglebone to OSD3358

[Mr.Current]

Hello,
I have a BeagleBone Black project and I’m trying to migrate it to OSD335x custom board. The BBB is am335x version, operating system is buildroot-generated Linux. The custom board is basically stripped down version of the OCTAVO reference design (left with eMMC, SD, UART0,1 and Ethernet) with the same operating system as BBB. UART is supposed to use the 8250 drivers.

The system boots up without problems (excluding the cant parse ‘X’ property of node ‘Y‘ kernel messages, but I don’t think it’s the curlpit here since BBB also has them after me tinkering with eeprom check bypass). Almost all peripherals work as intended with one exception – UART.  From the dmesg output I see that 8250 drivers don’t find serial devices during probing, even though both machines use the same OS. The omap_serial drivers do find UART0, I can use serial console and such.

My migration process went as follows:
1. Bypassed the eeprom check, and then reprogrammed it with u-boot according to the giudelines I found on OCTAVO pages.
2. Made an SD card recovery system, Flashed the OS onto eMMC (same system as on BBB).
3. Flashed the same .dtb file I used on BBB (later on I tried with recompiled/modified OCTAVO reference .dtb), dtc version 1.4.0.

My assumption is that I have to write new .dtb, but if this is the case why only UART has problems? Should it run out with the default device tree if the physical device is stripped of most peripherals?

Thanks in advance for any input.

 

Attachments:

1. uEnv.txt

[Mr.Current]

I almost got it, cat /proc/device-tree/ocp/serial@58022000/status shows me that OS is ignoring my device tree.

[Neeraj Dantu]

Hey Mr.Current,

Two files, refdesign.dts and OCTAVO_OUTPUT can’t be accessed because “This file type is not permitted for security reasons”. Can you please re-upload with a different name or ZIP them?

As for the issue, note that because of the EEPROM ID check in u-boot, different boards can go through different initializations that includes pin-multiplexing. Please make sure you have UART1 pin multiplexing in your device tree in the ‘am33xx_pinmux’ node. Also, please post the output of ‘cat /proc/device-tree/ocp/serial@58022000/status shows’

Best,

Neeraj

[Mr.Current]

Hello Neeraj,
sorry for messup, I forgot to give an update in this thread: my uEnv.txt points to /boot file in my mmcblk1p2 partition (eMMC OS partition), not the mmcblk1p1 which I anticipated, after putting the device tree file in the right location Linux boots with correct dts. The main issue still persists: during booting 8250 drivers dont find any UART devices, however omap-serial.c drivers do. It’s not a big deal since the omap-serial drivers also seem to use DMA, but I’d like to know why the system is behaving this way.
I will provide the neccessary files you mentioned as soon as I will be able to boot my Linux workstation.

Thanks for the heads up about the eeprom. If I change the last 4 bytes (from BBB default value value to ‘OS00’ bytes) can I expect any change in behavior? I dont think there is enough difference in both boards.

Thans for input and best regards,
MC

• This reply was modified 5 years, 7 months ago by Mr.Current.

[Mr.Current]

Hello,
the zip contains the device tree I’m using and dmesg output in .txt format. The dmesg output was made after I fixed the issue with wrong .dts location mentioned in my previous post.
Note that within .dts my pinmux starts at line 717 (just below pinmux@800) and UART1 configuration starts at line 1083 (serial@48022000).

Regards,
MC

Attachments:

1. dts_bootlog.zip

[Neeraj Dantu]

Hey MC,

There are a couple of ways to approach the issue. First, from what we understand, you have a BBB with a working Linux image that loads the correct drivers. In order to reproduce the exact same system on the custom board, please make sure of the following.

1. Switch the EEPROM ID from what is currently programmed to the BBB EEPROM ID which is currently programmed in the BBB so that same initialization is done on both boards. See https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/ for ways to program the EEPROM

2. Make sure the u-boot version and the boot source are the same on the custom board and the BBB. This may require you to extract the image in the BBB to an SD card and boot with the SD card on both the boards and compare the boot logs(including u-boot logs)

Secondly, from http://processors.wiki.ti.com/index.php/Sitara_Linux_UART_-_Switching_to_8250_Driver, it seems that the 2 changes that need to happen to use the 8250 driver instead of the omap serial are the change from ‘ttyO0’ to ‘ttyS0’ in u-boot and changing the kernel configuration to disable ‘omap serial port support’ and enable the internal 8250 drivers.

If the custom board you are booting is not booting from the same u-boot as BBB, that might be causing the incorrect loading of the driver. On the kernel level, make sure that you have the ‘omap serial port support’ disabled in your kernel configuration as it looks like these drivers are being loaded in the boot log attached.

Note that from boot log, the 8250 driver is being loaded: “[    0.498287] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled”, but the omap driver is taking precedence? (not sure) Disabling the omap driver could resolve this as discussed.

Best,

Neeraj

[Mr.Current]

Hello,
thanks for the tips, I will look into it as soon as I can (especially menuconfig setup, I didnt look there for a long time, something might have affected my setup), however for the time being I will stick to omap-serial drivers.

Best regards and thanks for help.

[Author]

Posts