PocketBeagle 2 - Memory Sizes

Looking at the Block Diagram (Fig. 189) on the Designs and specifications page it shows a 4GB eMMC and 4G (16-bit) DDR4. The photos of the board look like the eMMC is not populated. Does anybody know what the memory sizes are for the supplied PB2?

512MB of DDR4 ram, no eMMC.

Thanks.
It looks pinned out for eMMC. Maybe it doesn’t work…

That seems typical, every time we touch something from Ti it is a CF. Just got a c2000 dev board from them and it does not connect so the code cannot be flashed.

I’m fairly certain that it’s due to the original 4G eMMC not being large enough to hold a usable image anymore and the next sizes up wouldn’t have allowed them to hit their price/availability targets so they just removed it.

1 Like

Oh hey man ouch but yeah anyway sometimes lol. I mean, this is AM62x so the 2 MMC controllers are used on a lot of end products at this point (and Beagle Play).

Daniel is right. Test boards had eMMC populated but it was hard/impossible to hit the <$30 price point with something really usable for most users. 4GB is fine for stuff like buildroot or a slim bistro but most people would probably prefer the cost savings.

Anyway for people that want a bit of lore and how these things evolve, DVT and EVT boards below. Left one is a pre-production variant of the board and right is the one you’d get today. Relatively minor changes on this one, you should have seen Play.

There’s a bunch of subtle changes but the low profile headers, the different micro-SD slot for space (and having one with a CD pin), adding that 3 pin UART debug port like BeagleY) and yeah removing the eMMC for cost reasons. Depending on how they sell or for custom ones it’s never out of the question to populate it though, just a volume/demand thing.

Also if you’re brave enough to try populating your own eMMC open challenge :slight_smile: I’d need to double check the schematic but I think all the passives are there so it’s just the one BGA you’d need on there. I’ve modded my switch eMMC with a similar BGA with just a cheap hot air gun so this shouldn’t be too difficult. Not melting the headers on the other side is the bigger challenge. Anyone, someone should take a stab at it :wink:


1 Like

I been using arago on the bbb and it loads faster and has a smaller footprint. Just load up what you need. Also got it up on the ai64 and that thing boots in about 9 seconds. Both are consoles, not gui. If a gui and video is needed its either a imx8m or tegra 234.

Its hard to say how much impact that has on a decision. It does not matter how cheap or how fast it is, if you cannot use it is worthless.

Not beating up on Pi, they the best for providing a product that people can actually use. Why, it is documented and its features work. If it had emmc I would more than likely use their stuff for serious stuff, it is the undeniable winner if you need to test senors or something, its up and running in minutes.

Arago sure, you’d be amazed how much a Debian image grows once you start doing anything.

Buildroot or something light is fine. Even 4GB eMMC is expensive though. Keep in mind at this point AM335 on BBB is much cheaper than AM62, and that’s just one part of the board. Stuff adds up. Believe me, on this board, Jason and Co have agonized over individual cents, both design and negotiation with every part vendor. $25 now is not $25 from 2010s BBB days with inflation.

I sent a note on discord to get the part number in docs for the DDR to be updated. It’s pointing to the 4GB version but it’s 512MB of LPDDR4 at 1600MT/s

And yeah point taken on eMMC being nice even for smaller size. I still am arguing for one with eMMC down the line. Good news is no redesign yay.

With arago that would be a fast board and your sensors and what ever should be up at least at same speed as the ai64 on arago. 4Gb would be more than enough and still plenty of room for an application. Myself, I am not handing a competitor our binary on a SD card.

@foxsquirrel , i admit the pi is easier, and better socumented, but i insist, these boards are not the same. BB are open source. Pi are not. O do not see them as competitors, or to be compared. I do mot see this comparison as fair. Just my opinion.

You’re correct—arago is the TI operating system within the BSP.

You’re absolutely right. The Raspberry Pi 5 allows you to rapidly build a prototype, making it more suitable for certain scenarios.

In our case, the factory BeagleBoard image wasn’t a good fit, so we opted for the TI BSP. Unfortunately, TI has deliberately implemented roadblocks to prevent users from effectively utilizing their BSP for meaningful testing.

For instance, with a lean Yocto build on arago, boot times are around 11 seconds on the BeagleBone AI-64, which is exactly what we need. However, TI’s decisions have slowed our progress. One major example is the intentional disabling of the => saveenv command, meaning that if you need to configure U-Boot, you’re forced to spend hours rebuilding ti3boot while hoping you’ve chosen the correct configurations.

Additionally, TI suggests using uEnv.txt to load device overlays, but the instructions in their manual are incorrect. The variables seem mismatched, as U-Boot claims to load uEnv.txt, but no overlay is actually applied. This implies that overlay loading is also disabled.

If the Raspberry Pi 5 had eMMC, we would consider it for certain projects. It’s a fine board for hobbyists, but not always practical for our specific needs.

You wish has come true!

It’s called the Compute Module 5… :smiling_face:

1 Like

Oh my, I just ordered a Radaxa 5B and will test that out. Thank you for sharing that I will have to look into that one.

The pinout works, but I had it removed for cost reasons. Some folks said that only sizes larger than 4GB would really be effective, so I thought it was better to simply remove it. If there is sufficient interest, we could create a SKU.

2 Likes

Yes, I’m one of those people who would rather pay a little more for a plug-and-play experience, so if possible, I’d like to have an emmc version to choose from.

1 Like

The only way to get a handle on that is shift from a bedrock distro to an ala-carte Yocto build. Several examples are Rock-5b on core-image-weston, 6 seconds the GUI is up. If memory is correct even the BBB is up to a console in a fraction of the time with a core-image-minimal.

Since Ti is breaking out a meta-beagle layer, it might be time to re-evaluate.

I know it is weird, but memory vendors like to report numbers in bits. 4Gb = 512MB.

One thing we’ve learned is the image that ships with it really matters. Now is the time to get that image right. We’ve got units in the wild to help with finalizing the image so that it is a great experience. We are working on the tutorials with various capes, starting with TechLab.

Please feel free to join in the fun. If people love PocketBeagle 2, they’ll love it even more with an included eMMC. But, don’t wait. Start today with microSD and give us feedback on the images and the work-in-progress examples.

See BeagleBoard.org / vsx-examples · GitLab and it’s forks as well as updates going into https://docs.beagle.cc (Documentation / docs.beagleboard.io · GitLab) on a very regular basis.

@ayush1325 do we have Github mirrors for both? We should be tracking issues on Github as well, I’m afraid.

While I can try setting up mirrors, I would really like the issue tracking to be done in a single place.
Since examples don’t really need much CI time, I can move the whole project to Github without much problem if that is better.