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]http://processors.wiki.ti.com/index.php/AM335x_board_bringup_tips[/url] and
[url]http://www.ti.com/lit/ug/spruh73n/spruh73n.pdf[/url]
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.
ā¦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.
@ 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.
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.
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.
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.
@ 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.
