Have a question about the Next-Gen BeagleBone? Ask it here!

Hi,

How does the XAM3359AZCZ on the initial run of beaglebone compare to AM3358BZCZ100 which would feature on the final runs ?

What are the feature differences ? and why is this processor switch being done ?

--

Kunal

Kunal Ghosh wrote:

 

How does the XAM3359AZCZ on the initial run of beaglebone compare to AM3358BZCZ100 which would feature on the final runs ?

What are the feature differences ? and why is this processor switch being done ?

I'm not a TI employee or representative, but I believe the A->B means that the silicon revision has gone from 2.0 to 2.1.  According to TI's Silicon Errata document, the only behavioral change is improved latch-up.  The "100" is the important part -- it's now a 1 GHz part.  The initial "X" means it's an "experimental" part rather than a fully-qualified device, i.e., you get to be a pioneer

Hi John, by PRUSS were you referring to -> http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem ?

Quite an insight ( I am completely new to all of this ) . Does the "X" usually (by most manufacturers) refer to experimental ?

I went through the BeagleBoneBlack system reference manual, as suggested by selsinork, and it atleast made one thing clear:

"We do not expect any benefit from moving to this device and there should be no impact seen as a result of making this move."

So, the early adopter wouldn't be at a loss when Circuitco decides to move to the newer chip

Kunal Ghosh wrote:

 

Hi John, by PRUSS were you referring to -> http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem ?

Yes.  PRUSS is one of those nice acronyms that doesn't have many meanings like IP or PCI.

Kunal Ghosh wrote:

 

Quite an insight ( I am completely new to all of this ) . Does the "X" usually (by most manufacturers) refer to experimental?

Many manufacturers use a designation like this for "preproduction" chips.  Generally they're functionally correct, but they may not meet all the timing and electrical parameters over the full temperature and voltage range.  Since chips vary between fabrication runs, it takes a while before you really have a full picture of how they're going to perform under all conditions.  The manufacturer may need to tweak the timing specs or tweak the process to make chips that match the data sheets.

The "X" parts let designers get started using actual chips.  We generally are using accurate power supplies and running everything at room temperature, so if the chip doesn't work properly at 85C and 3.0V we're not going to notice during development.  We hope that the fully qualified chip is ready by the time we need it for full temperature range testing and for production.

s ork wrote:

 

coder27 wrote:

and what is the DDR3 clock speed?

I've seen 300MHz, 400MHz, 600MHz, and 800MHz.

I'd suggest grabbing a copy of the SRM from

http://circuitco.com/support/index.php?title=BeagleBoneBlack#LATEST_PRODUCTION_FILES_.28A5A.29

it lists the DDR3L as running at 606Mhz (303Mhz base clock).

And the version of the SRM I've just downloaded says 400Mhz/800Mhz.  I've received mine, but it's not immediately obvious how to verify what speed it's actually running the DDR3 at.

Hi Selsinork,

I got mine today too, but I only connected it up via the serial port (I'm going to get a microSD card and upgrade the image before I do much more with it).

This is what cat /proc/cpu revealed:

CPU implementer : 0x41

CPU architecture: 7

There was also a cpufreq-info and a cpufreq-set command. The former revealed it was running a profile to set the speed between 300MHz and 1GHz, and that it was called 'ondemand'. There was another profile called 'performance', and when I set that, then the cat /proc/cpu went up to 990.68 BogoMIPS.

The syntax was cpufreq-set -g performance (I set it back to ondemand afterwards, just-in-case).

I didn't know what DDR3L was but according to here, it is Low-voltage DDR3, and that it achieves twice the throughput of DDR2 because of 8-bit prefetch tech  compared to DDR2's 4-bit. The prefetch was described on RAMBUS's page (I remember vaguely maybe they had the patent on it or something?).

Anyway, it seems DDR, DDR2, and DDR3, if all run at, say, 200MHz, then DDR obtains 400MT/s, DDR2 is double at 800MT/s (because it has 4 bit prefetch compared to DDR 2-bit prefetch) and DDR3 achieves 1600MT/s (double DDR2 because of 8-bit prefetch), if the RAMBUS diagram is correct with the 8-bit prefetch explanation. So, at 1600MT/s, this would be 3200Mbyte/sec (3.2Gbyte/sec) for a 16-bit wide bus.

This doesn't entirely agree with the SRM nor with Wikipedia's DDR entry, but they could be wrong (or the deductions above could be wrong). The 800MHz referred to in the SRM could be the interface speed (in the RAMBUS diag, they show a clock with one cycle and they call it the core speed, and next to it is 4 clock cycles, and they call that the interface speed). The Micron part datasheet says the memory is capable of 1600MT/s too.

By the way, if you are planning to connect up the serial interface, since they don't show the arrows, it was hard to know the point of view, but basically this is the arrow direction showing who sends and who receives:

Beagleboard J1 pin 4 <---------------PC

Beagleboard J1 pin 5---------------->PC

So for me, with a TTL-232RG-VIP-WE cable, the orange wire went to pin 4, yellow to pin 5. The VIP cable requires power, so I used the Port 9, (black to pin1, red to pin 3).

shabaz wrote:

 

I got mine today too, but I only connected it up via the serial port (I'm going to get a microSD card and upgrade the image before I do much more with it).

Yeah, I was somewhat puzzled that the only way to upgrade the eMMC is to write an image to SD, boot from that and that the upgrade will take 45 minutes. Why not upgrade over USB, network etc.

Also you boot from eMMC regardless and need to hold down S2 to boot from SD I thought that was a bit strange, theres an bit on the wiki that suggests it will boot from SD if you wipe the eMMC clean which seems to leave you in a position where you can't boot from SD but use eMMC for a persistent /home while you try out different distros.

That and you can't use the pins on the headers that are shared with the eMMC without software disabling the eMMC and then software enabling whatever device you have sharing those connections. 

All leaves me wondering if the eMMC is really worth it, don't get me wrong, I understand the attraction of a device where essentially everything you need to get it operational is on the board (no confused windows users unable to write an image to an SD card etc).

However that didn't work for me anyway.. I followed the suggested route, plugged it in to the PC via usb and waited for the mass storage device to appear... and waited... and waited...

Confirmed the board had booted by plugging in an ethernet cable and logging into it that way, but no device appeared on USB

By the way, if you are planning to connect up the serial interface,

I'm thinking that a serial connection is absolutely going to be required for anything beyond the most basic use. Especially if the tethering method fails, you'll need some way to see what's going on.

The VIP cable requires power, so I used the Port 9, (black to pin1, red to pin 3).

Yeah, my serial adapter needs power too, not quite sure what the thinking is in not providing 3.3v on J1

Would be interested in your opinion of Angstrom, I'm not impressed so far..

I've not used Angstrom before, it looks like it is supposed to cater for embedded apps (rather than desktop) and I saw busybox was installed too. Unfortunately I didn't get much time to experiment. Maybe with an external MicroSD then there is more room for a bigger Linux distribution. According to docs, apparently update-over-USB and update-over-serial are supported by the processor, but may require some software from TI. I'm going to use a bit of kynar wire to patch a 3.3v supply to one of the blank pins on the serial header (e.g. pin 2) from the underside, so I can just plug the cable in to one port.

shabaz wrote:

 

I've not used Angstrom before, it looks like it is supposed to cater for embedded apps (rather than desktop) and I saw busybox was installed too.

Yep, Angstrom supposedly came from the OpenEmbedded stuff. Busybox presence appears to be a bit of a red-herring here. Run opkg list-installed and you'll see 99% of the desktop stuff, and a good chunk of server-side stuff too. There are a few omissions and a couple of bizarre substitutions along with a load of stuff that doesn't immediately appear to be of any use at all.

I'm going to use a bit of kynar wire to patch a 3.3v supply to one of the blank pins on the serial header (e.g. pin 2) from the underside, so I can just plug the cable in to one port.

I'd pretty much decided on doing exactly that too.

I also forgot to order a micro-HDMI cable, so I currently can't see whatever appears on the display. The Pi wins there by using the more usual connector that people are more likely to have available when they forget to order one.

Mine boots from microSD automagically, no need to press the buttom.  If I want to boot from eMMC I have to pop out the card.  My card has the wheezy demo image on it from the elinux site.

Mine boots from microSD automagically, no need to press the buttom.  If I want to boot from eMMC I have to pop out the card.  My card has the wheezy demo image on it from the elinux site.

Barry Mark wrote:

 

Mine boots from microSD automagically, no need to press the buttom.  If I want to boot from eMMC I have to pop out the card.  My card has the wheezy demo image on it from the elinux site.

Not here, it boots u-Boot SPL and then u-boot.img from eMMC unless I press the button. The main u-boot on eMMC then goes and touchy-feelies any microSD and if it doesn't find what it's looking for aborts. No attempt to fallback to eMMC boot.

This isn't so bad if your card has whatever the eMMC version of u-boot is looking for - you can probably arrange for the eMMC u-boot to boot linux off the card and I assume that's what you are seeing.  It's a problem if you don't want that version of u-boot, or if your OS doesn't want u-boot at all.

I may have a go at swapping R68 for R93, but not sure that's going to be easy as R93 is quite close to P8.

A small dip switch for S2 instead of a push button would be an interesting change for a future version.

Barry Mark wrote:

 

Mine boots from microSD automagically, no need to press the buttom.

this turns out to be a known problem

https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/OKuX9iapA78

you are booting from eMMC, it just happens that you have a fat partition on your microSD that has a useful uEnv.txt on it. Without that, current versions of the code leave you in limbo with a hung system, you can't even use the microSD as additional storage while booting from the eMMC due to this.

Ah well, now I have a good excuse to go build my own u-boot for it