New BeagleBoard Rev C5 Shipping

[Gerald Coley]

For those of you buying the original BeagleBoards, we are now shipping the new Rev C5 version. Documentation can be found here:

 

www.circuitco.com/support

 

The reason for the change was that Micron stopped producing the memory that we were using on the Rev C4. So, we had to change the memory. We will no longer be building the Rev C4 version.

 

This new revision results in a change being required to the UBoot and Xloader.  As I understand it, you should be able to replace the UBoot and the Xloader and your current SW should work, but no guarantees. The board ships from the factory with a GNOME desktop in it and will boot to the desktop from NAND.

 

To get the new UBoot and xloader, you can create an SD card using the.img file from the link above and then create a new card using the Uboot and xloader from that SD card. Check back at the link above often for SW updates. We anticipate a newer release in the coming days.

 

 If you have any issues please post your questions to the mailing list or IRC.

 

Gerald

 

[svrsig]

URL broken

[Gerald Coley]

I just tried it and it works for me.

 

Gerald

 

--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.

[emeb]

Google groups is prepending a 'google.com' to the URL. Remove that and
it works fine.

Eric

[Gerald Coley]

I am viewing it form GMAIL and it worksfine. Yes, indeed Google group is messing it up. You can just type in what you see and not click the link.

 

Gerald

 

[svrsig]

Thanks.

Is the Wiki correct: 512Mbytes NAND and only 256Mbytes RAM?

[Gerald Coley]

The wiki is correct. The orignal version was 256MB NAND and 256MB DDR.

 

Gerald

 

On Mon, Jul 25, 2011 at 3:57 AM, svrsig <ch...@svrsig.org> wrote:

Thanks.

Is the Wiki correct: 512Mbytes NAND and only 256Mbytes RAM?

--

[Cliff Brake]

The Micron MT29C4G48MAZAPAKQ-5 IT appears to require 4-bit ECC (please
correct if this is not accurate). Have there been any efforts made to
support this level of ECC in the beagleboard sw?

Thanks,
Cliff

--
=================
http://bec-systems.com

[Gerald Coley]

I will defer to the SW team on this one.

 

Gerald

[Torben Frenzel]

We are using the MT29C4G48MAZAPAKQ-5 IT Micron part on an OMAP3530 in
our custom design. It was necessary to modify the x-loader and u-boot,
because the old Micron PoP had two 128MB RAM parts, one on each chip
select line. The new one has only one of 256MB. However, no
modification to the ECC code in u-boot was made, so it seems that the
new part does not require any changes beyond this. Writing MLO, u-boot
and kernel from u-boot to NAND works just fine.

Torben

[Jason Kridner]

> On Mon, Jul 25, 2011 at 4:30 PM, Cliff Brake <cliff...@gmail.com> wrote:
>>
>> The Micron MT29C4G48MAZAPAKQ-5 IT appears to require 4-bit ECC (please
>> correct if this is not accurate).  Have there been any efforts made to
>> support this level of ECC in the beagleboard sw?

What ends up shipping on the C5 boards today is a kernel built with
this recipe[1] which is based on this kernel baseline[2]. There was
some discussion on a TI support thread regarding 4-bit and 8-bit ECC
support[3]. The tag being pointed to by that thread nor the
particular patch in quesiton[4] is NOT in the history of the tree
being pulled in for this release of the boards.

So, no, we aren't handling it today. Looks like we should pull in
that[4] patch.

[1] http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp_2.6.32.bb?h=2011.03-maintenance
[2] http://arago-project.org/git/projects/linux-omap3.git?p=projects/linux-omap3.git;a=commit;h=5fc29e7b2a76a64a739f857858ef0b98294aa155
[3] http://e2e.ti.com/support/embedded/f/354/p/53309/196908.aspx
[4] http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=6a49a8032d94554909d4f14654675c67d71c9d8a

[Cliff Brake]

On Tue, Jul 26, 2011 at 5:11 AM, Torben Frenzel
<tfren...@googlemail.com> wrote:
> We are using the MT29C4G48MAZAPAKQ-5 IT Micron part on an OMAP3530 in
> our custom design. It was necessary to modify the x-loader and u-boot,
> because the old Micron PoP had two 128MB RAM parts, one on each chip
> select line. The new one has only one of 256MB. However, no
> modification to the ECC code in u-boot was made, so it seems that the
> new part does not require any changes beyond this. Writing MLO, u-boot
> and kernel from u-boot to NAND works just fine.

Even though your software may work, if you are using a part that is
rated assuming 4-bit ECC, and you are only doing 1-bit ECC, then the
life of the part will be drastically reduced. As NAND geometries get
smaller, the error rate goes up, so better ECC algorithms are required
to compensate.

We've been using the Micron embedded 4-bit ECC engine, and that seems
to work fairly well. I'm not sure how it compares to sw solutions,
but Micron suggested to us that 4/8-bit ECC gets pretty slow in sw.

[Torben Frenzel]

After reading up on the issue I realized that I didn't really
understand the problem (which I now do).

Cliff, could you give me any pointers on how you are using the Micron
ECC? Is this something you can enable during NAND init, or will I have
to patch the relevant ECC routines in the kernel to take advantage of
the hardware?

Thanks,
Torben

On Jul 26, 5:12 pm, Cliff Brake <cliff.br...@gmail.com> wrote:
> On Tue, Jul 26, 2011 at 5:11 AM, Torben Frenzel
>

[Cliff Brake]

On Mon, Aug 8, 2011 at 5:41 AM, Torben Frenzel
<tfren...@googlemail.com> wrote:
> After reading up on the issue I realized that I didn't really
> understand the problem (which I now do).
>
> Cliff, could you give me any pointers on how you are using the Micron
> ECC? Is this something you can enable during NAND init, or will I have
> to patch the relevant ECC routines in the kernel to take advantage of
> the hardware?

Attached are my current patches. While they seem to function, they
need cleaned up, are not tested for error handling, and are in no way
guaranteed to be complete.