>> a) Boards and software "chunks" need to be products.
>> Bflash
>> Balloon2
>> Balloon3
>> FPGA/CPLD
>> Command Line
>> JTAG Interface
>> Other Devices
>> NOR Device Interface
>> IO Interface
>This seems a lot of components for a relatively small bit of software.
>I haven't added the first two as I think they come under platforms,
>and I don;t actually understand what most of these mean. Does one of
>them (e.g 'JTAG interface') mean 'JTAG dongle' (It should appear
>somewhere)? Does 'Other devices' mean the CPU JTAG chain? What is 'IO
>interface'? Look at the curent descriptions and suggest clarifications
>please.
Agreed my original e-mail was scanty on explanation. OK so here is some
justification for the list.
Firstly my assumption is to bunch bugs wherever possible from a user
perspective (as opposed to a code perspective) this is so that we don't
expect someone reporting a bug to have intimate knowledge of the system and
its construction, and secondly so that when we change the structure we can
keep the outstanding bugs, and when we add functionality that the user sees
we add a category to the component list.
Therefore the above list of components is a user centric view of bflash
operation. These help to narrow down the search for bugs if you think you
have spotted a problem and you want to see if it has been reported and
similarly help to focus attention on the user perceived origin of the bug
when reporting new ones.
Balloon2/3 are there so that bugs that relate specifically to bflash on each
of these machine types can be recorded. There is quite a bit of platform
specific data in bflash and bugs could crop up differently between the two
platforms. It can't be related to the product Balloon and its version number
because there isn't a cross linking facility. (At least I havn't spotted
one). We could simply combine these as "platform" however it would be
important to know which platform caused the problem.
FPGA/CPLD relates to future functions for bflash so could be removed for
now.
Command line in bflash is complex because of the dual use i.e. when bflash
masquerades as jflash it is entirely possible that bugs will exist with
command line compatibility for jflash and in bflash.
JTAG interface represents the activation of the JTAG interface within
bflash, since bflash exclusively uses JTAG to communicate to the system
under test it is reasonable to include this. Yes it should also cover the
dongles (I expect that multiple dongle support will appear soon as well as
fast dongles) since the drivers for these are within bflash. Secondly this
category covers the intricacies of the JTAG interface, as bflash expands to
encompass different JTAG and multiple JTAG chains this will be an important
bug category.
Other devices refers to other JTAG devices that bflash could be used to
program. The internal data structures that code for devices and platforms in
bflash are based on BSDL, so any device with a BSDL description could be
coded into bflash. Bugs may well occur as people try to do this or with
specific devices that maybe don't quite conform to their BSLD description or
to the JTAG standard (which of course is open to interpretation).
NOR Interface. Obviously a key part of the functioning of bflash is the
programming of NOR flash so given the number of different devices and the
different NOR devices much could go wrong (See the "bring me the head of
someone from AMD" comments in the CFI reader in the Kernel, and the K3 mods
in jflashmm).
IO Interface. One of the main extensions in bflash is the ability to read
and write to static memory space on the external busses of the devices on
the platform, although this is currently only implemented on the PXA it is a
simple extension to make this work for say the SAMOSA bus on the CPLD.
>I'm not sure that we need a great pile of components for each bit of
>software. They need to make sense to people filing bugs,
Agreed we need to describe what each category means and this also implies as
I have suggested that they are "user operation centric".
>and we are
>not expecting insane numbers.
When we have a few hundred users I think it will hot up a little....
>A few basic categories is probably
>sufficient, at least for now.
Agreed but that is what I see the above list as, a basic set of categories
covering the broad functional parts of this bit of code. Many projects do
this on a file by file or class by class basis and there it is often very
hard to work out where a bug should go especially if you are a user
reporting a bug (which is most often the case). This is also the underlying
reason why Bugzilla is a good tool in that it is *not* connected to the
version control system thus forcing bug reporting into the same structure as
the code (the difference between developer focus and user focus).
>> Kernel
>> {Others are better placed than me to decide here}
>>
>> Root tree (could be sub divided? Thoughts...)
>>
>> Base Modules (PCMCIA, USB Ethernet, etc)
>I've put this under kernel
Modules are delivered in a separate way to the kernel and are likely to be
maintained in a different way by different people. I think they ought to be
a separate category. Even though some modules will end up in the kernel.
>> VHDL for CPLD/FPGA
>> CPLD
>> FPGA
>> Wishbone Interface
>> Module Extensions
>> PCMCIA
>> NAND
>> SAMOSA
>Again the component descptions could be improved (to explain to the
>less expert which one they might be wanting).
This is going to be a little more technical because many users won't see the
VHDL and so wont understand that a bug they have is the result of a VHDL
problem.
Hopefully the first two categories are obvious. Since the core VHDL is
common but the wrapper is unique bugs may appear in CPLD that don't in FPGA
and vice versa.
The Wishbone extension is an attempt to match the Wishbone interface
standard to the Balloon bus, which is a little fraught. However there are
many Wishbone peripherals and this category is designed to catch the likely
problems trying to use this slightly incompatible interface.
Module extensions refers to alternative module extensions, the Wishbone
interface is one such module but other modules can be used alongside the
balloon interface in VHDL. Preliminary documentation for this is included in
the P2 release and a basic sketch of how this works is included in the P2
VHDL. It would be a waste of silicon to just use the FPGA for the Balloon
interface.
PCMCIA/NAND/SAMOSA these are all components (in the VHDL sense) within the
Balloon module. Each obviously has a one to one map to the hardware, each is
critical to the operation of L3 and there are likely to be bugs reported for
each of these components.
If other standard components get added into the distribution then these can
have categories added.
>Currently most of these are allocated to me by default, bflash/VHDL
>stuff to Dave and XJTAG and PCB layout stuff to Chris. I would have
PCB/schematic stuff probably ought to come to me.
>allocated stuff to nick but he has devoisly not signed up yet...
>I suspect every product will need
>an 'other' or 'general' option.
Yes agreed.
I'd also like to suggest that we use Bugzilla as the means of capturing user
suggestions for improvements. The easiest way of doing this is to add a
"suggestion" component to each product. (Other bug reporting systems have
this as a "type" of bug). It makes sense to do this here as the mechanism
for reporting the inclusion of a suggestion is similar to the tracking of a
bug. Thoughts....
>Wookey
Once this discussion has settled I'll enter all the known P2 hardware bugs.
David
iTechnic Ltd
(text/plain)