The 720MHz will NOT have more RAM, same as C3, 256MB. Rev D is the next
major spin of the board due in April/May timeframe of next year which will
have more than you can handle in the way of changes.
If everyone chooses to ignore the 720MHZ on C4, as that is all we can get to
build these boards, then I guess that is for everyone to chime in on. The HW
will be marked C4.
Koen: While I agree that it would be nice to add rev D (0 0 0), too, I
wonder what might change until April/May and if we shouldn't wait a
little more until things are more settled?
I wouldn't expect the ID to change, but I know the mux needs a few big changes. My goal is to have rev C4 and rev D detection in upstream uboot ASAP, not to have a perfect revD experience
Updated patch with revD detection for review and testing in attachment.
We also need a workaround for an extremely rare NEON corner-case that
can cause processor lockup.
The Cortex-A8 L2 Cache Auxiliary Control Register bit [27] "Load data
forwarding disable" (also known as PLD_FWD) should be set to a 1, as
a workaround which does not add any significant performance impact.
We also need a workaround for an extremely rare NEON corner-case that
can cause processor lockup.
The Cortex-A8 L2 Cache Auxiliary Control Register bit [27] "Load data
forwarding disable" (also known as PLD_FWD) should be set to a 1, as
a workaround which does not add any significant performance impact.
Note this register can only be written in secure privileged state so
needs to be done via TI's secure world
I don't think we are able to switch Beagle into secure privileged state. I'm not sure if OMAP35x even can be switched into secure mode (in contrast to OMAP34x). If I'm wrong here, please correct me.
Please send a patch.
Mans: As our NEON expert: Any comments from your side?
FYI the official ARM erratum number is 725233 "PLD instructions
executed with PLD data forwarding enabled can result in a processor
deadlock" and could be usefully mentioned in any patch
The 720MHz will NOT have more RAM, same as C3, 256MB. Rev D is the next
major spin of the board due in April/May timeframe of next year which will
have more than you can handle in the way of changes.
If everyone chooses to ignore the 720MHZ on C4, as that is all we can get to
build these boards, then I guess that is for everyone to chime in on. The HW
will be marked C4.
Koen: While I agree that it would be nice to add rev D (0 0 0), too, I
wonder what might change until April/May and if we shouldn't wait a
little more until things are more settled?
I wouldn't expect the ID to change, but I know the mux needs a few big changes. My goal is to have rev C4 and rev D detection in upstream uboot ASAP, not to have a perfect revD experience
Updated patch with revD detection for review and testing in attachment.
Does anybody had a chance to test this patch on C3 and C4?
All GPIO pins are set properly on the Rev C4 board.
GPIO_171 Hi…assuming that you activate the internal pullup and set it to an input.
GPIO_172 lo…assuming that you set it to an input.
GPIO_173 Hi…assuming that you activate the internal pullup and set it to an input.
All GPIO pins are set properly on the Rev C4 board.
GPIO_171 Hi...............assuming that you activate the internal pullup and
set it to an input.
GPIO_172 lo...............assuming that you set it to an input.
GPIO_173 Hi...............assuming that you activate the internal pullup and
set it to an input.
Why different configuration for 172 compared to 171 + 173? I.e. why no pullup for 172? Is this compatible to older boards?
What else is expected to be needed to be put in the flash of the Rev C4?
* Gerald requires that the default is that something appears on the
display. Otherwise, people will complain that the display port is
dead. I think doing this with a default environment command should be
fine. I'd prefer a logo, but we may go with a single background
color.
* We likely need similar code for the S-Video port.
* I think we need a couple of diagnostic routines. Possibly something
for audio. The above video tests might be able to be put in as 'diag'
commands as long as they execute by default.
* I'd still like to see the USBTTY patches made suitable and sent
up-stream--and think this is important for the BeagleBoard out-of-box
experience.
A word about audio. Based on my calculations today it is possible to
generate +1.258 ppm accurate synchronous audio DAC clocks to the C3
Expansion Connector. The 12.288 MHz on McBSP3_CLKX (pin 8) and the
synchronous 49.152 MHz on McSPI1_CLKX make it possible to interface TI
PCM1792A to Beagleboard in the 192 kS/s 24-bit stereo mode. The clocks
are made by reprogramming DPLL3 and DPLL4. As the result all their
clocks become about 2.4 % faster. I think this should not disturb any
attached modules?
