BR4-Appliance rev. B bring up story

For starters, let me remind you that our BR4 Appliance (or BRI Appliance) is an open hardware BRI Asterisk Appliance running Astfin.
The schematic is distributed under a disjunctive tri-license that gives you the choice of one of the three following sets of free software/open source licensing terms:

* Mozilla Public License, version 1.1 or later
* GNU General Public License, version 2.0 or later
* GNU Lesser General Public License, version 2.1 or later

The software, Astfin2 is available under GNU General Public License, version 2.0 or later.
In this post I am referring to units manufactured by our friends at ATCOM in April 2008.

The new BRI Appliance rev2 board arrived a couple of days ago. Atcom did a pretty good job, thank you Peter, Edwin and the team; the board has been assembled professionally.
During visual inspection I did not find any problems. I confirmed that resistance between power plane and ground was reasonable and I was ready to connect the supplied 12V power adapter.
After powering it up, I confirmed main 3.3V voltage and 1.2V core voltage; Everything was in order.

I connected my USB jtag (ICEbear)and executed dumpreg to see CPU’s status. Ooops, CPU was not in a proper state…what a bummer, initial thoughts…problem related to BGA soldering?
After a quick break, I decided to go further and execute memtest, which also failed. This was really depressing. Despite my frustration, I decided to continue. It was time for another visual inspection…
After 15 mins, I concluded that unless the BGA is not soldered properly, the board is ok. Just to re-confirm the failure, I reconnected the JTAG , this time using my laptop, and…..this time memtest worked!!!! ;) .
Well, something was inconsistent….but I could communicate properly with my board;). My positive energy was back, and I am sure that you can imagine my excitement…
After several tests I was able to conclude that my PC was responsible for initial “failures”. All tests were working properly with my laptop running ICEbear software.
At this point I was ready to load uBoot….
For the initial testing I decided to use the original BR4 uboot available in astfin2 trunk. I used menuconfig to select 500MHz CPU, CPU, rev 2 and 64MB of SDRAM, CAS=3. After several minutes u-boot.ldr was ready.
To first clean the flash and to then flash it with uboot, I copied it to my laptop and executed the following:

./flashload.exe –backend=m25p80 –eraseall –program=u-boot.ldr

After about 15 secs, I had my u-boot copied to the flash. Some of you may notice that it took only 15 sec, and yes this is not a mistake. ICEbear JTAG works really fast and I would strongly recommend it for any serious development.
At this point I had to get my espresso and relax for a bit…
After 15 min I was back at my bench table. I connected a DB9 terminal cable, and restarted the unit.
Bingo, I could see the uBoot messages

U-Boot 1.1.6-svn (mark@astfin.org) (Apr 23 2008 – 07:55:06)

CPU: ADSP BF537 Rev.: 0.2
Board: BR4-Appliance board
Clock: VCO: 500 MHz, Core: 500 MHz, System: 125 MHz
SDRAM: 64 MB
In: serial
Out: serial
Err: serial
NAND: 256 MiB
Net: DP83848 PHY
I2C: ready
Hit any key to stop autoboot: 0

Our BRI Appliance was alive !
At this point I was ready to try Linux. I ran “make menuconfig” in Astfin and selected BR4-Appliance with the default options. After typing “make” and waiting 15 mins I had my first uImage ready for testing.
Well after all, I guess engineering live is not as easy as it may seem ;) This time I was not as fortunate and I experienced some errors related to the Cologne chip

BFSI TLG Driver ($Id: bfsi_tlg.c 1049 2008-03-28 10:34:09Z diego $). PCM slots:8
MTCS0=MRCS0=0xff, MCMC1=0×0
iRxBuffer1 = 0xff803f18 – size 2 * 8 * 8 = 64B
iTxBuffer1 = 0xff900320 – size 2 * 8 * 8 = 64B
ISR installed OK
Modular ISDN Stack core version (1_2_0) revision ($Revision: 1.40 $)
mISDN_dsp: Audio DSP Rev. 1.30 (debug=0×0) dtmfthreshold(100)
mISDN_dsp: DSP clocks every 64 samples. This equals 2 jiffies.
ISDN L1 driver version 1.20
ISDN L2 driver version 1.32
mISDN: DSS1 Rev. 1.47
XHFC: xhfc_init driver Rev. ??? (debug=0)
xhfc_spi_probe: entered
SPI CS bit: 5 enabled
xhfc_spi_probe: 0 devices found
Removing SPI CS bit: 5

The fun had just begun…..
I started reviewing the driver code looking for problems. I found that one of the macros was not executing as expected, a quick fix helped to solve this issue.
At this point we were able to detect the chip, however, we still could not initialize it properly:

HFC: xhfc_init driver Rev. ??? (debug=0)
xhfc_spi_probe: entered
SPI CS bit: 5 enabled
toggle reset
set reset to PF14
spi_xhfc_count: Found XHFC-4SU @ SPI address 0
xhfc_spi_probe: 1 device found
xhfc_spi_probe: xhfc[0].pcm_config = 0xd000000
XHFC_PI0 xhfc_spi_probe: Errors setting up instance 0
Removing SPI CS bit: 5

After restarting in full debug mode, I discovered that I was initializing SPORT1 not SPORT0 as required by our ISDN Appliance. I forgot to pass necessary arguments to “make”, a quick fix was in place after several minutes.
In the meantime, Dimitar began to review the schematic. He quickly discovered that one of our buffers had open drain outputs which was not what we had planned…. We had 2 options, either to remove the buffer all together and use jumpers, or to connect pull-up resistors to Open Drain outputs in an attempt to “hack it”. I decided to simply remove the chip (74LV07APWR) and shorten a few traces together. After reworking the board, our BRI Appliance was ready for its final test. I therefore loaded the new uClinux distribution to the NAND flash and restarted the board:

br4> tftp 2000000 uImage-br4
Using DP83848 PHY device
TFTP from server 207.225.3.12; our IP address is 207.225.3.54
Filename ‘uImage-br4′.
Load address: 0×2000000
Loading: ###################
######## SNIP
#####################
done
Bytes transferred = 6557038 (640d6e hex)
br4> nand erase clean;nand erase, nand write 0×2000000 0×0 0×650000;reset

This time everything worked as expected ;)

BFSI TLG Driver ($Id: bfsi_tlg.c 1049 2008-03-28 10:34:09Z diego $). PCM slots:8
iRxBuffer1 = 0xff803f18 – size 2 * 8 * 8 = 64B
iTxBuffer1 = 0xff900320 – size 2 * 8 * 8 = 64B
ISR installed OK
Modular ISDN Stack core version (1_2_0) revision ($Revision: 1.40 $)
mISDN_dsp: Audio DSP Rev. 1.30 (debug=0×0) dtmfthreshold(100)
mISDN_dsp: DSP clocks every 64 samples. This equals 2 jiffies.
ISDN L1 driver version 1.20
ISDN L2 driver version 1.32
24 Apr 20:36:34 ntpdate[128]: step time server 192.43.244.18 offset 1209058712.812501 sec
mISDN: DSS1 Rev. 1.47
XHFC: xhfc_init driver Rev. ??? (debug=0)
xhfc_spi_probe: entered
SPI CS bit: 5 enabled
toggle reset
set reset to PF14
spi_xhfc_count: Found XHFC-4SU @ SPI address 0
xhfc_spi_probe: 1 device found
xhfc_spi_probe: xhfc[0].pcm_config = 0xd000000
XHFC_PI0 xhfc_spi_probe: adapter(0) ‘XHFC:SPI’ found on SPI bus
XHFC: 1 card installed

One interesting observation. As you can see in the boot messages above:

iRxBuffer1 = 0xff803f18 – size 2 * 8 * 8 = 64B
iTxBuffer1 = 0xff900320 – size 2 * 8 * 8 = 64B

We are using L1 cache block A and block B for our DMA buffers allocations.
In the original bfsi only the block A of L1 cache was available for DMA buffer allocation. This was perfectly fine for BF532/BF533 based boards but could have caused some problems in a case of BF537 boards running kernel with L1 cache available to the internal MAC.
You can see sram allocation by viewing /proc/sram on your hardware.
In our case, this is what appears in /proc/sram:

— L1 Data A Size PID State
ff8000c0-ff803f18 15960 1 ALLOCATED
ff803f18-ff803f98 128 139 ALLOCATED
ff803f98-ff804000 104 0 FREE
00000000-00000000 0 0 NULL
—snip—
— L1 Data B Size PID State
ff900000-ff900320 800 1 ALLOCATED
ff900320-ff9003a0 128 139 ALLOCATED
ff9003a0-ff904000 15456 0 FREE

you can see that the majority of BANK A was already allocated (MAC) even before our request to allocate DMA buffers.

ff8000c0-ff803f18 15960 1 ALLOCATED

Even with our tiny 128B buffers we were able to allocate only enough sram to accommodate for the RxBuffer

ff803f18-ff803f98 128 139 ALLOCATED

and there was not enough SRAM left in Bank A to accommodate for our TxBuffer

ff803f98-ff804000 104 0 FREE

so we used a tiny portion of Block B as follows:

ff900320-ff9003a0 128 139 ALLOCATED

The above allocations were “automated” thanks to
replacing the l1_data_A_sram_alloc() with the l1_data_sram_alloc(). For some reason statement L1_DATA_A_SRAM Allocate data A bank SRAM [Currently, it will allocate data B bank SRAM if data A bank cannot be allocated.] did not work for me.
Since we were only allocating DMA buffers at the initialization time there is no performance penalty for using generic L1 data allocation routines.

At this time we were ready to make our first call, results will be available in the next post…..
Stay tuned…
Mark

UPDATE: The BR4-Appliance is shipping, for details please visit this post.

This entry was posted in BRI, Hardware, Software and tagged , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

One Comment

  1. Posted April 29, 2008 at 5:31 pm | Permalink

    Nice work guys – thanks for the detailed log of your exploits. Helps other understand the design and excitement involved in bringing up cool hardware like this.

    - David

Post a Comment

You must be logged in to post a comment.