Questions about OSD3358TH

Regarding the information in the Dev Document ([url][/url])

So then if I wanted to override the os on the eMMC then I would just insert a valid boot image into the SD card? Is this really an issue, I sounds like a nice option to have enabled for development but disabled for production.

Will the module support USB hubs (assuming that is does), Will it support USB Ethernet and USB Displays, with the appropriate device drivers? I am assuming also for WIFI, Bluetooth and other accessories.

Does not been tested mean not at all or not thoroughly? Once populated, will the module support the Gigabit Ethernet?
EDIT: I understand now. LAN8710A ← 10/100 interface ic.

SD card booting: It’s not supposed to work like that. You should have to hold down the SD_BOOT button to make it boot from the SD. That drives a pin that changes the AM3358 boot sequence. U-boot (the first-stage boot loader) however may be grabbing images from the SD card even after having booted from the eMMC version of U-boot. That’s all documented here :
[url][/url] and

JTAG - I have soldered a JTAG header in place and connected a Segger JLink, but I haven’t done much other than verify that it is electrically sound. I will do a writeup on JTAG debugging shortly.

1 Like

@ mcalsyn - I thought the only the TI JTAG debugger worked with the Beagle Bone Black?

@ Mr. John Smith - I am hoping that’s not the case. This (and other articles) indicate some success with Segger : [url]Beaglebone Black support? - J-Link/Flasher related - SEGGER - Forum

…but it will be a day or two more before I have first-hand experience with getting it to work. You can use Segger with the TI development platform, but it’s pricey, so I am trying with OpenOCD and related tools. If I get it to work, I’ll publish a KB article on it.

@ mcalsyn - Are you using a development board or the TH ?

@ Mr. John Smith - @ mcalsyn is correct about SD_BOOT.

The module does expose the USB host pins. If you can find drivers for a USB device, it should work fine. We don’t do any special customizing of the software image, it’s the regular BeagleBone Black image.

The two headers have not been tested at all by us yet.

TH for the moment - one with a JTAG header and adapter from tincan : [url][/url]
and one without - both populated with headers so that I can make proper rats-nest out of them.

FWIW, I have both a BBB board & the OSD3358 developer board. If you have a bootable uSD card inserted they both will boot from it first on power up, if its not inserted or not bootable it will then boot from eMMC.

I dug into this more. The SD_BOOT button does switch the boot order, but the uboot code always checks for a bootable SD card as part of the boot sequence. Hence, even if you boot from MMC1 first (eMMC) it will still load the OS from MMC0 (sd card). I hope that’s configurable in uboot options, but have not found where yet.

This article describes what the action of S2 (BBB) / SD_BOOT (OSD3358 ) is, but switching the boot order doesn’t matter because once uboot starts, it checks for an SD card with a bootable image. You can also watch UART0 to see that the boot sequence changes.

The five pins that set the dozens of boot options can be found here :
[url][/url] page 4960 (yes, 4960)

EDIT: See also : [url][/url]

@ mcalsyn - So then this is the same thing on the BBB?

@ Mr. John Smith - Yup - I have a bbb here and just saw the same behavior.

Well that’s a security hole. This uboot thing, is it possible to modify its code?

I’m still pretty wet behind the ears here, but it appears that there are uboot options (not code changes) that can control this. And those options can be set in uEnv.txt. I think it’s just an exercise in uboot configuration.

EDIT: And worse case, there are numerous blogs on how to compile uboot, but again, I doubt that’s necessary.

Another SD card note - the SD card detect on the current TH board is missing a pull-up (it’s noted in the dev guide). This means that sd cards inserted after booting are not noticed, and cannot be mounted. The sd card has to to be there at boot time if you don’t add the pull-up.

It looks like you need a 10K pullup on pin 131 of the SOM, but I am waiting for confirmation from GHI before I commit to soldering one in place.

If you do boot from an sd card, even if it is 16 or 32G, you need to run some fdisk commands to create a partition so that you can access the rest of the sd card space.

Some of the instructions for expanding SD cards were out of date and won’t work, so here’s a KB article that covers expanding sd cards for the Octavo and Debian-8.4-lxqt-4gb image : [url][/url]

So, it appears that the SD_BOOT button does do what it is advertised to do. Without the SD_BOOT button, the AM3358 tries to boot from eMMC first, and moves on to the SD card only if it fails to boot from there.

If you hold down the SD_BOOT button, then the AM3358 tries the SD card first.

The reason it looks like it isn’t working is because after the first-stage boot from eMMC, uboot (loaded from the eMMC) tries to complete the boot from the SD card first, and then completes the boot from eMMC only if that fails.

I verified this by watching UART0 output, and by putting a completely different OS (Ubuntu Snappy*) into the SD slot. It would boot that OS only when the SD_BOOT button was down.

*Ubuntu Snappy is an IoT-specific build of Ubuntu, with a minimal footprint and containerized transactional installation and application isolation for a “carrier-grade update experience”.

EDIT: I have hacked my OSD3358TH to include the missing pull-up resistor on SD.CD (SD card detect). That might matter - I don’t know because I don’t have an unmodified board to try.

Can you send a pic of the modification. Also how did you get a the module so fast :smiley:

@ Mr. John Smith - Forgive the crappy photo please (and the wayward solder blob on pin 3). A 10K resistor goes between pin 5 and 19 on the JTAG pads.

Note that this will not cause the OS to notice a card inserted after boot (that’s true of the BBB too). The OS is not set up to watch that pin. If you use a USB host interface and an SD card reader, it will notice inserted cards, but not using the onboard SD slot. I suspect there may be hacks to use scripting and kernel probe commands for getting around that, but I have not taken time to figure that out yet.

As for getting the card, GHI’s new faster-than-light shipping is not available in all areas.

Hat tip to John@ GHI for pointing me toward this fix.

You had to solder it to the JTAG header? I’ll have to keep that in mind. Hum, perhaps I’ll keep the module as the production environment and use my BBB as the dev.

You could also solder it topside on the SOM pin, but it’s a bit more tricky and I think the nearest Vcc pin is a bit far away. I have another board with a jtag header afffixed, and it’s still not hard to get the resistor on there. It’s a preview board and I’ve got to believe there’s another rev coming.