The first cut at the second prototype schematic is done. The block diagram is nearly the same as the previous post but check it out for some changes. I am currently working on the bill of material so some parts may change. Also, this design does not include a connection to Insteon. So, more changes to come...

1. Block Diagram

A few things have been moved around.

The Insteon module (not currently implemented) will be an I2C connection and will share the same bus as the TAS5504 and the WM8580.

The Input-Output (WM8580) module has three I2S interfaces now. One interface for the phyCORE (MPC5200) to send data to the output (DACs or S/PDIF), one interface for phyCORE to receive data from the input (ADC and S/PDIF) and one interface to send data directly to the Amplifier (TAS5504).

The Boot UART has been moved to Programmable Serial Controller 6. It shares this port with the IrDA interface.

The SDIO flash drive support has been moved to the SPI interface in the Timer Group.

GPIO lines are now scattered around various groups (PSC3, Timers and Dedicated GPIO lines).

2. Amplifier

The Amplifier supports both BTL and SE operation. Make sure to follow the jumper settings for Headers 1 thru 10. Setting the jumpers wrong will cause serious damage to the amplifier. (tyler: I just noticed that the header labels in the tables are wrong. I will correct them in the next pass).

Notice that chip U1 is connected to GPIO line 7. A high on this line will make the amplifier source its music from the CPU. A low on this line will make the amplifier source its music from the output of the WM8580. This makes it possible to bypass the CPU when legacy devices are connected.

The funny looking circuit at the bottom of the page has two purposes. First, it creates a virtual ground (half of PVDD) when the amplifier is in SE mode. It also holds off the amplifier until the power is up and running by asserting the 'backend error' line.

3. Ethr-IrDA-Serial-SDIO

This is a 'catch all' page with four simple circuits on it. First, the Ethernet connector (with integrated magnetics) is connected to the Ethernet PHY. phyCORE has the Ethernet phy already. Second, it has a UART driver and connector. Third, it has the SDIO connector for the flash cards. And lastly, it has a IrDA transceiver.

4. Input-Output

External devices are connected to DigiSpeaker via a WM8580 from Wolfson Electronics. This device is a stereo input ADC, S/PDIF transceiver and six-channel output DAC. It is controlled via an I2C interface and has two separate I2S interfaces.

The primary I2S interface is split into separate receive and transmit sections. The part does this so that it is possible to route incoming data (via the ADC or S/PDIF receiver) to the CPU while the CPU routes outgoing data to connected devices (via the DACs or s/PDIF transmitter). DigiSpeaker takes advantage of the I2S interfaces by routing the primary I2S receiver to PSC2 of the MPC5200, the primary I2S transmitter to PCS3 of the MPC5200 and the secondary I2S transmitter to the TAS5504 directly. This give DigiSpeaker very flexible data routing.

Each channel of the ADC has an anti-aliasing filter on the front of it to minimize the noise to the ADC.

Each channel of the DACs has a two-pole low-pass filter (corner frequency = 50KHz) and DC blocking capacitor. They also have a small amount of amplification (2x). Notice that the primary I2S transmitter has three inputs to source the three DACs. However, DigiSpeaker only has a single stream of stereo data. The second and third primary inputs are connected to the first so the data is replicated on all three DACs.

5. miniPCI

The miniPCI connector has all the required PCI control, address and data lines. Both +5V and +3.3V are supplied. The inserted card can not consume more than 500mA.

The Local Bus signals of the MPC5200 have been routed to the reserved pins of the miniPCI connector. The idea here is to use these pins to control a flash chip(s) mounted on a miniPCI card. Chip Selects 1 thru 3 have also been routed to the chip. Although phyCORE does not route Chip Select 0 (the Boot Chip Select) to the miniPCI connector, it is believed that the production DigiSpeaker will be able to boot from a miniPCI card with a few jump changes. The advantage here is that 'bricked' DigiSpeakers could be recovered in the field by changing a few jumpers and inserting a 'boot card' into the miniPCI connector.

6. phyCORE

The phyCORE schematic has all the signal assignments for the system. Check it our for CODEC and GPIO line mappings.

7. Power

The prototype will require two external power supplies. The first is a Digital Supply and is required to supply both +-15V to +-20V. The second is an Analog Supply that supplies 0V to +32V .

The signals supplied by the Digital supply are cut down to +-12V, mostly to drive the gates of the Amplifier but are also used as the voltage rails for the op-amps. A 3A, 5V signal is also created from the +12V line. This voltage, in turn, is used to create a 2.5A, 3.3V signal that powers most of the DigiSpeaker logic.

The signals supplied by the Analog supply are not regulated. The external supply is expected to not exceed 32V.

All the signals are fitted with an LED that lights up when power is supplied. Not sequencer or monitor is used. The phyCORE module has a 'power good' module that holds the CPU in reset until all the power levels are up and stable.

8. USB

USB driver and power source.

The attachment contains a block diagram of the second prototype (Prototype II). This prototype is a new PCB based on the phyCORE tiny module. Essentially, it is our own version of the PhyTec development board provided with the phyCORE tiny development kit.

1. phyCORE Tiny

This is the main interface between the phyCORE tiny module and the rest of the system. The phyCORE tiny module has two 100 pin connectors that make most of the MPC5200B signals available to external logic. I nice block diagram of the phyCORE tiny module can be found in section 1.1 of the phyCORE hardware manual.

2. miniPCI

The phyCORE tiny module makes the PCI signals of the MPC5200 available. We are going to hook these signals up to a miniPCI connector (type IIIA) so we can plug in PC adapter cards. Right now, the only reasonable way to get wireless functionality is via wireless modules (chip manufacturers basically won't talk to us). Most wireless modules come with miniPCI and SPI interfaces. So, we plan on using this interface to try out several wireless cards. At the time of this writing, 802.11n wireless modules with miniPCI connectors are just becoming available. DigiSpeaker might benefit greatly from this new technology and including a miniPCI connector in the design gets us that ability while preserving the flexibility to try other cards.

Not shown in the block diagram is the ability to boot the system from the miniPCI connector. We are thinking that we might route the LocalBus signals to the miniPCI connector (via jumpers) so it is possible to boot the phyCORE tiny card from a flash card of our own creation. The idea here is to make it possible to recover DigiSpeaker from a miniPCI flash card if the system has been 'bricked' by one of our users. phyCORE tiny modules do not route chip select zero to their expansion connector. However, we think it might be possible to scratch off the CS0 line and reroute it to our board (as an experiment with this prototype). Of course, the final DigiSpeaker system will not use the phyCORE tiny module so we will have control over chip select zero.

3. Reset

We plan on providing a push button to reset the system.

4. JTAG

We will probably bring the JTAG signals out to a header so they can be used to test/debug the system. So far, it looks like JTAG equipment is a bit expensive. Our thinking is that the 'boot flash' option discussed in the miniPCI section is a better option.

5. TAS5504/TAS5142

This is the amplifier. It needs a number of connections from the phyCORE tiny card. It needs four GPIO lines for reset, mute, ...etc. It needs I2C for command and control. It needs I2S for signal source. It also needs all three power rails (+30V, +12V & +3.3V) to operate.

The output stage will be laid out so that it is possible to drive two speakers in BTL configuration or four speakers in SE configuration.

6. Power

For this prototype, power will be provided by a lab bench power supply. It will provide +30V and +12V. The power section of this prototype will make +3.3V from the +12V line. Note that the phyCORE tiny module makes +1.5V and +2.5V out of the +3.3V rail.

7. WM8580

This is the input/output section of the prototype. The Wolfson WM8580 provides both analog and digital input and output of signal. It is controlled with I2C and some GPIO lines. Of course, if has to have I2S from the MPC5200 for signal transfer. Notice that the WM8580 is not connected to the TAS5504 directly. All signals (coming or going) pass through the MPC5200.

8. Serial

The phyCORE tiny module provides a UART transceiver on PSC3. This transceiver is used for the serial port of the system. The serial boot is needed for accessing the system during boot.

9. SDCard/MMC

The SPI lines of PSC3 are brought out to an SDcard/MMC connector. They will also be brought out to a header. The thought here is that we can use these signals to control a wireless module or plug in SPI compatible flash cards for more memory. Flash memory on SPI is potentially faster than flash sticks plugged into the USB port.

10. USB

The USB lines of the MPC5200 will be brought out to a USB connector. This was successfully done in the first prototype (see the schematic of the first prototype). The idea here, once again, is to use it for wireless access (there are many cheap wireless USB sticks) or it can be used for flash memory.

11. Ethernet

The phyCORE tiny module provides an Ethernet PHY. This will be reused in the second prototype.

12. InfraRed

The IrDA lines of the MPC5200 have been brought out on the phyCORE connector. We plan on building up a IrDA receiver so remote controls can be used with the system.

13. Insteon

The Insteon prototype kit comes with a board that decodes the control signals into I2C. This prototype will be connected to this prototype so it can be control via Insteon switches and software.

The Linux kernel is finally getting real support for SD cards.
http://kerneltrap.org/Linux/MMC_Flash_Memory_Card_Support

Pierre went on to discuss the Serial Peripheral Interface (SPI) stack, "the second large feature is the fact that you can now use your SPI controllers for MMC, SD and SDIO. Yes, even SDIO works nicely over SPI. This means that a lot more systems can get storage and expansion I/O at basically the cost of a connector."

This is good for Digispeaker since we have an SD Card hooked up with SPI. Now we have a device driver for it!

"I'm pleased to announce another release of Squashfs. This is the 22nd release in just over five years. Squashfs 3.3 has lots of nice improvements, both to the filesystem itself (bigger blocks and sparse files), but also to the Squashfs-tools Mksquashfs and Unsquashfs," stated Phillip Lougher.

Squash developers are focused next on getting squash into the mainline kernel.
http://kerneltrap.org/Linux/Squashfs_Aiming_For_Mainline_Kernel

22 revisions and five years. I've only been working on getting the Digispeaker patches in for about a month.

Good thing squash is going in, we use it for our root flash file system.

Digispeaker is based on open source software. The main operating system is the Linux kernel running on the PowerPC MPC5200B. My past kernel programming projects have all been based on x86 hardware so I'm learning a lot about how things are done on the PowerPC. Instead of a BIOS like x86 machines, the PowerPC uses a standard called Open Firmware. Open Firmware contains a device tree language for describing the hardware layout of a particular PowerPC based design. Here's a small section of a device tree description:

i2c@3d40 {

compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";

reg = <3d40 40>;

interrupts = <2 10 0>;

interrupt-parent = <&mpc5200_pic>;

rtc@51 {

compatible = "epson,rtc8564";

reg = <51>;

};

codec@27 {

compatible = "ti,tas5504";

reg = <27>;

};

};

This section describes the i2c controller. The i2c controller implements a bus. The rtc and codec are attached to this bus.

I'm implementing code for supporting this syntax of describe the i2c devices as children of the i2c bus in the device tree. Reading this email thread will give you an idea of what needs to be done to get code into the Linux kernel.