path: root/hw/xilinx.h
AgeCommit message (Collapse)AuthorFilesLines
2011-08-22xilinx: removed microbalze_pic_init from xilinx.hPeter A. G. Crosthwaite1-3/+0
This is a microblaze target specific function that belongs outside of xilinx.h (which is a collection of target independent device model instantiator functions) Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
2011-08-22xilinx.h: Added missing includesPeter A. G. Crosthwaite1-0/+2
Added some missing #includes for this file. Previously this file relied on its clients to pre-include its dependencies. Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
2011-03-16microblaze: Add PetaLogix ml605 MMU little-endian ref designMichal Simek1-0/+39
Add the first Microblaze little endian platform. Platform uses uart16550, axi ethernet, timer, intc. Signed-off-by: Michal Simek <monstr@monstr.eu> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@petalogix.com>
2009-10-27xilinx_ethlite: use qdev properties for configuration.Gerd Hoffmann1-1/+1
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-10-07New qdev_init_nofail()Markus Armbruster1-3/+3
Like qdev_init(), but terminate program via hw_error() instead of returning an error value. Use it instead of qdev_init() where terminating the program on failure is okay, either because it's during machine construction, or because we know that failure can't happen. Because relying in the latter is somewhat unclean, and the former is not always obvious, it would be nice to go back to qdev_init() in the not-so-obvious cases, only with proper error handling. I'm leaving that for another day, because it involves making sure that error values are properly checked by all callers. Patchworks-ID: 35168 Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-10-01Revert "Get rid of _t suffix"Anthony Liguori1-3/+3
In the very least, a change like this requires discussion on the list. The naming convention is goofy and it causes a massive merge problem. Something like this _must_ be presented on the list first so people can provide input and cope with it. This reverts commit 99a0949b720a0936da2052cb9a46db04ffc6db29. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-10-01Get rid of _t suffixmalc1-3/+3
Some not so obvious bits, slirp and Xen were left alone for the time being. Signed-off-by: malc <av1474@comtv.ru>
2009-07-16qdev: rework device properties.Gerd Hoffmann1-6/+6
This patch is a major overhaul of the device properties. The properties are saved directly in the device state struct now, the linked list of property values is gone. Advantages: * We don't have to maintain the list with the property values. * The value in the property list and the value actually used by the device can't go out of sync any more (used to happen for the pci.devfn == -1 case) because there is only one place where the value is stored. * A record describing the property is required now, you can't set random properties any more. There are bus-specific and device-specific properties. The former should be used for properties common to all bus drivers. Typical use case is bus addressing, i.e. pci.devfn and i2c.address. Properties have a PropertyInfo struct attached with name, size and function pointers to parse and print properties. A few common property types have PropertyInfos defined in qdev-properties.c. Drivers are free to implement their own very special property parsers if needed. Properties can have default values. If unset they are zero-filled. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-05-26microblaze: Add petalogix s3a1800dsp MMU linux ref-design.Edgar E. Iglesias1-0/+50
This setup was designed by petalogix and is supported by upstream linux. The design targets a xilinx spartan-3a-1800 dsp board with MMU. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>