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.
…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 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.