{5} Assigned, Active Tickets by Owner (Full Description) (39 matches)

The 15693 tag rcvr device must be refactored. It interleaves all kinds of protocols:

• 15693 1-oo-4
• 15693 1-oo-256, polling
• 15693 1-oo-256, interrupt-only
• 14443A
• 14443B

These must be torn apart into separate files, and one common module to poll the input pin.

After each power-down, the FPGA program must be reloaded. We must do this from the CPU. (For debugging the FPGA, using a PC JTAG cable is fine.)

Parts:

• Intel PXA270 or BlackFin
• Altera Cyclone II FPGA, ep2c8t114; or newer Altera on RFC40

The FPGA is programmed through an SVF script generated with an Altera tool.

Tools: openwince JTAG, which is badly maintained, or UrJtag, which tries to take over maintenance from openwince, or the branch of UrJtag at uCLinux/BlackFin. 'Abbreviate': [OW|Ur]Jtag. There is a patch to play SVF files in [OW|Ur]Jtag.

Steps:

• configure, patch, run [OW|Ur]Jtag. Done by 11 dec 07; not done for RFC40
• patch CPU into [OW|Ur]Jtag, if it is on the same JTAG chain. Create description for FPGA from Altera BSDL. Done by 13 dec 07; not done for RFC40
• test [OW|Ur]Jtag via PC serial cable. detect works 14 dec 07;
• test SVF via PC serial cable;
• create backend to use GPIO pins to drive the JTAG lines on V3; this amounts to creating a new [OW|Ur]Jtag 'cable'; done in 07;
• port [OW|Ur]Jtag to a library to fit into MRG;
• decide where we will generate JTAG line manipulation commands: off-line or on the PXA270. Pros/Cons:
  • off-line: must think up a little language to describe JTAG line commands, incl timings
  • off-line: generate and parse this little language
  • off-line: trust that detection and part selection works without any change <-- this bothers me
  • on-line: need to include the SVF parser/player and the complete [OW|Ur]Jtag library into MRG; this is no problem because there is a file system on the Guardian.
• Current preference is for the last option;
• the fastest development track? No idea. Sorry.

Right now, ui/stdin does upload/download directly from the stdin UI handler. It should assemble the file and send it to the impl. Think of a stdin UI over ethernet on a separate host.

On BF548 EZ-Kit, the YAFFS device generated by eCos was recognized by u-boot. At the first glance, that seems to be different for RadioTuna u-boot and eCos.

Based on port to EZ-Kit BF548 and U-Boot port to RadioShark-547.

Basic devices needed:

• memory (128MB) (inherit 64MB from BF548-EZKit)
• serial (BF548-EZKit has no RTS/CTS)
• Ethernet (AX88796B i.s.o. SMC, different intpt)
• RTC (inherit)
• Watchdog (inherit?)

The XScale had a postprocessing phase to lock critical code and data into the caches. For the BlackFin, I guess some gcc annotations are necessary in the code.

Notes:

• is L1 memory alone sufficient, or do we desperately need L2?
• can we come up with a unified scheme that can handle both approaches: postprocessing and annotation?
• L1 annotation is fairly common. Find out about L2 annotation.

Current eCos has no support for NAND Flash.

We wrote a package for that. It will harbour:

• a NAND flash chip package

chips differ in their interrogation, in factory-bad marks

• a NAND flash controller package

NAND flash requires a controller.

+ The BlackFin has an on-board controller. + Provide a template GPIO controller

• an Abstract NAND Chip package that hides the presence of multiple (heterogeneous) controllers and multiple (heterogeneous) chips

Work started in september, around the date of Melanie's PhD Defence.

mrg errno currently is global. It must be glocal, with a mechanism to transfer error status between client and server threads.

Now, it's round-robin. My guess is that it is easy to replace it with LRU (maybe even by disabling the custom strategy).

Currently, XYZmodem (to be honest: XYmodem) in MRG is a copy from eCos. Xmodem has a bug. Zmodem is unimplemented.

I'd like to replace XYZmodem with some other implementation, like legacy lrzsz (from 1999!).

I already add tftp, to follow the same command interface UI> upload -t remotefile localfile

Add:

• (f)sync command to browser
• do sync after write operations (complete files?)
• do sync from "cron"

Currently hal_virtual_vector_table is explicitly set to 0xFF803000 in arch/current/src/bfin.ld. Would it be possible, and wouldn't it be better to use a linker directive to put it anywhere in the L1.data.A segment? Also, there may be other identifiers that have explicit linkage for which the same refactoring would be appropriate.

BlackFin's NAND NFC can automatically handle NAND nCE if so configured, and if there is only one NAND chip.

• configure NAND nCE auto
• update eCos Bfin NFC driver to remove all things nCE

Check if it's possible to use LINK/UNLINK in the eCos assembly routines

Need an interactive utility to handle NAND flash, a bit like u-boot's nand command

It's an NE2000 compatible, so it should be doable

This little module duplicates lots of the code in console. Move it away.