From: benh@kernel.crashing.org
To: Tom Rini <trini@kernel.crashing.org>,
Michael Sokolov <msokolov@ivan.Harhan.ORG>
Cc: <linux-galileo@source.mvista.com>, <linuxppc-dev@lists.linuxppc.org>
Subject: Re: EV-64260-BP & GT64260 bi_recs
Date: Wed, 20 Mar 2002 17:58:25 +0100 [thread overview]
Message-ID: <20020320165825.31210@mailhost.mipsys.com> (raw)
In-Reply-To: <20020320161931.GF3762@opus.bloom.county>
Ok, here is my older document, though now that I re-read it, I find
it rather too bloated. Food for though...
Ben.
/* Here's a try at defining new birecs a bit more
*
* Of course, most of this is _optional_, OF based machines
* won't use but a few of these, embedded developers may use
* and customize these, we will try to make embedded specific
* driver rely solely on defined bi_recs....
*
* Note. The high 8 bits of the size field contains a type code
* for the bi_rec. The types are defined below. The composite
* type allow embedding of "properties", in that case the birec
* tag is considered as a "name". For records of type meminfo,
* bootinfo, and cpuinfo, the tag identify the information passed.
* All lowercase tags are reserved for future use by the kernel,
* All uppercase or mixed case tags can be freely used by board
* implementors for custom applications.
*/
struct bi_record {
unsigned long tag; /* tag ID */
unsigned long size; /* size of record (in bytes) */
unsigned long data[0]; /* data */
};
#define BI_SIZEMASK 0x00ffffff
#define BI_TYPEMASK 0xff000000
#define BI_TYPE_FIRST 0x01000000
#define BI_TYPE_CPUINFO 0x02000000 /* single values, fixed type */
#define BI_TYPE_BOARDINFO 0x03000000 /* single values, fixed type */
#define BI_TYPE_MEMINFO 0x04000000 /* physical memory layout */
#define BI_TYPE_BOOTINFO 0x05000000 /* boot infos (cmdline, ...) */
#define BI_TYPE_COMPOSITE 0x42000000 /* more birecs after a bi_composite */
#define BI_TYPE_SINGLE_MASK 0x80000000 /* single value (no size, value in
size field */
#define BI_TYPE_END_COMPOSITE 0xfe000000
#define BI_TYPE_LAST 0xff000000
/*
* CPU Info
*/
#define BI_CPU_4xx_CORE_CLOCK 'cclk' /* Core clock of a 4xx (ulong, Hz) */
#define BI_CPU_4xx_PLB_CLOCK 'pclk' /* PLB clock of a 4xx (ulong, Hz) */
#define BI_CPU_4xx_OPB_CLOCK 'oclk' /* OPB clock of a 4xx (ulong, Hz) */
#define BI_CPU_4xx_PCI_CLOCK 'iclk' /* PCI clock of a 4xx (ulong, Hz) */
/*
* Board info
*/
#define BI_BOARD_NAME 'name' /* 0 term string */
#define BI_BOARD_MACHINE_TYPE 'mach' /* Machine type (common config) */
#define BI_BOARD_MACHINE_MODEL 'modl' /* Model within machine type */
#define BI_BOARD_MACHINE_FAMILY 'fami' /* Familly within machine type */
#define BI_BOARD_SERIALNUMBER 'sern' /* Why not ? 0 term string */
/* To be defined, or specific to a given board */
/*
* Mem info
*/
#define BI_MEM_TOTALMEM 'totm' /* Total memory */
#define BI_MEM_PHYSMAP 'phym' /* Physmap, contiguous @ 0 if absent */
#define BI_MEM_DIMMMAP 'dimm' /* Why not ? ... */
/*
* Boot info
*/
#define BI_BOOT_CMDLINE 'cmdl' /* Command line (0 term string) */
#define BI_BOOT_INITRD 'rimg' /* Initial ramdisk */
struct bi_boot_initrd {
unsigned long addr; /* Physical address */
unsigned long csize; /* Compressed size */
unsigned long msize; /* Memory size (max rd driver size) */
};
/* Note: we may want to define a format for scattered ramdisks */
#define BI_BOOT_ROOT_DEVICE 'root' /* Major & minor of root device in
2x32 bits ! */
/*
* Composite record format is a suite of bi_recs finishing
* with a BI_TYPE_END_COMPOSITE.
* They have a "name" which is the tag of the composite
* record, and they begin with a "type" long. Then, is
* a suite of bi_recs.
*/
struct bi_composite {
unsigned long type_tag; /* type tag */
unsigned long data[0]; /* more birecs */
};
/* Here are some defined type tags */
#define BI_COMP_DEVGROUP 'dgrp' /* A group of devices (more composite) */
#define BI_COMP_DEVICE 'devi' /* Generic device */
#define BI_COMP_PCI_HOST 'phst' /* PCI host (contains it's devices !) */
#define BI_COMP_PCI_DEVICE 'pdev' /* PCI device */
#define BI_COMP_CPU_DEVICE 'pdev' /* CPU embedded device */
#define BI_COMP_IRQ_NODE 'irqn' /* Interrupt node (controller or bridge) */
/*
* An interrupt node defines interrupt routing.
*/
/* To be written ;) */
/*
* A device has those generic properties defined.
*/
/* An IO resource is an abstract entity to designate a memory
* or IO region used by a device. The exact meaning of those
* fields depends on the atualy type of device (the bus where
* resides). A generic device is meant to be used for your own
* motherboard devices, you can use the values below the way
* you want, each driver defines it's own meaning there.
* It wouldn't be efficient to provide more abstraction imho.
*/
#define BI_PROP_IO_RESOURCE 'iors'
struct bi_prop_io_resource {
unsigned long base_addr;
unsigned long size;
unsigned long flags;
};
/* An interrupt is designated by a parent node ID and a
* number. The parent node structure will be then define
* routing informations. If the interrupt is wired to the
* CPU's internal interrupt controller directly, it's parent
* node ID is 0, and the number represents an interrupt number
* in the native CPU numbering.
* Additionally, flags are added to the interrupt definition.
* Only 2 bits are currently defined for those, the high 16
* bits are free to be used by the implementor of a given board.
*/
#define BI_PROP_INTERRUPT 'irq '
struct bi_prop_interrupt {
unsigned long parent; /* tagID of the parent node */
unsigned long number; /* Interrupt number */
unsigned long flags; /* see below */
};
#define BI_IRQ_LEVEL 0x00000000 /* bit 0 = 0 */
#define BI_IRQ_EDGE 0x00000001 /* bit 0 = 1 */
#define BI_IRQ_NEG 0x00000000 /* bit 1 = 0 */
#define BI_IRQ_POS 0x00000002 /* bit 1 = 1 */
/* The device type (or class), mostly for information purpose for now */
#define BI_PROP_DEVICE_CLASS 'clas' /* ulong */
#define BI_DEV_CLASS_ETHERNET 'eth '
#define BI_DEV_CLASS_UART 'uart'
#define BI_DEV_CLASS_SCC 'scc '
/* etc... */
/* The driver is used to define "standard" type of devices, like
* PC-like uart. Note that devices defined below rely on a specific
* format of the io resources and eventual additional properties
*/
#define BI_PROP_DEVICE_DRIVER 'drvr' /* ulong */
/* define required properties of legacy serial here */
/*
* Properties relative to PCI hosts
*/
/* define bus numbers, and bases here along with a type
* property indicating the host type, a generic type can
* be used for indirect
*/
/*
* Properties relative to PCI devices. This includes the
* above properties (all of them eventually). The IO resource
* property additionally defines some flags. The actual mapping
* of the host bridge (ISA, etc...) isn't defined here but is
* defined
*/
#define BI_PROP_PCI_DEVFN 'dvfn' /* ulong */
#define BI_PROP_PCI_VENDORID 'vid ' /* Do we need that here ? */
#define BI_PROP_PCI_DEVICEID 'did ' /* Do we need that here ? */
/* Note: I appologize for bit numbering ;) */
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-03-20 16:58 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-20 0:43 EV-64260-BP & GT64260 bi_recs Michael Sokolov
2002-03-19 23:00 ` Mark A. Greer
2002-03-20 7:55 ` Wolfgang Denk
2002-03-20 13:19 ` benh
2002-03-20 15:30 ` Michael Sokolov
2002-03-20 16:19 ` Tom Rini
2002-03-20 16:58 ` benh [this message]
2002-03-23 4:01 ` Val Henson
2002-03-23 13:07 ` Murray Jensen
2002-03-24 12:22 ` Benjamin Herrenschmidt
2002-03-24 12:20 ` Benjamin Herrenschmidt
2002-03-24 19:09 ` Val Henson
2002-03-24 16:46 ` Benjamin Herrenschmidt
2002-03-25 8:51 ` Geert Uytterhoeven
2002-03-24 18:16 ` Benjamin Herrenschmidt
2002-03-26 2:16 ` Val Henson
2002-03-26 10:05 ` Benjamin Herrenschmidt
2002-03-24 19:38 ` Geert Uytterhoeven
2002-03-24 16:55 ` Benjamin Herrenschmidt
2002-03-24 17:18 ` Benjamin Herrenschmidt
2002-03-25 0:44 ` Murray Jensen
2002-03-25 22:05 ` Val Henson
2002-03-26 3:21 ` Val Henson
2002-03-26 4:14 ` Murray Jensen
2002-03-26 10:14 ` benh
2002-03-26 12:05 ` Gabriel Paubert
2002-03-26 12:18 ` benh
2002-03-26 23:24 ` Mark A. Greer
2002-03-26 21:40 ` benh
2002-03-27 15:13 ` Mark A. Greer
-- strict thread matches above, loose matches on Subject: below --
2002-03-27 20:09 Michael Sokolov
2002-03-27 18:53 Michael Sokolov
2002-03-27 19:37 ` benh
2002-03-27 18:34 Michael Sokolov
2002-03-27 18:32 Michael Sokolov
2002-03-27 18:46 ` benh
2002-03-27 18:03 Michael Sokolov
2002-03-27 16:16 ` Mark A. Greer
2002-03-27 16:24 ` Mark A. Greer
2002-03-27 18:40 ` benh
2002-03-27 18:02 ` Mark A. Greer
2002-03-27 18:06 ` Mark A. Greer
2002-03-27 17:32 Michael Sokolov
2002-03-27 15:46 ` Mark A. Greer
2002-03-27 17:48 ` benh
2002-03-27 15:59 ` Mark A. Greer
2002-03-27 2:37 Michael Sokolov
2002-03-26 21:52 ` benh
2002-03-27 14:15 ` Matt Porter
2002-03-27 15:10 ` Mark A. Greer
2002-03-27 15:15 ` Mark A. Greer
2002-03-27 17:47 ` benh
2002-03-28 9:14 ` Geert Uytterhoeven
2002-03-27 1:35 Michael Sokolov
2002-03-26 23:48 ` Mark A. Greer
2002-03-24 16:02 Michael Sokolov
2002-03-21 2:13 Michael Sokolov
2002-03-21 6:39 ` Dan Malek
2002-03-31 8:32 ` Paul Mackerras
2002-04-01 18:39 ` Dan Malek
2002-04-02 5:32 ` Paul Mackerras
2002-04-02 16:33 ` Tom Rini
2002-04-02 17:29 ` Dan Malek
2002-04-02 14:42 ` Armin
2002-04-02 20:12 ` Tom Rini
2002-04-02 21:02 ` Dan Malek
2002-04-03 0:21 ` Tom Rini
[not found] <dan@embeddededge.com>
[not found] ` <3C98DA15.50302@embeddededge.com>
2002-03-21 1:11 ` Murray Jensen
2002-03-21 6:50 ` Dan Malek
2002-03-21 11:05 ` Murray Jensen
2002-03-21 1:10 Michael Sokolov
2002-03-21 0:57 Michael Sokolov
2002-03-21 6:58 ` Dan Malek
2002-03-21 0:47 Michael Sokolov
[not found] <3C98B189.78A92DFE@mvista.com>
2002-03-20 18:12 ` Wolfgang Denk
[not found] ` <3C98DB49.2C3A2F79@mvista.com>
2002-03-23 3:49 ` Val Henson
2002-03-20 17:11 Michael Sokolov
2002-03-20 18:06 ` Wolfgang Denk
2002-03-20 17:04 Michael Sokolov
2002-03-20 17:25 ` Tom Rini
2002-03-21 20:36 ` Troy Benjegerdes
2002-03-21 19:17 ` Mark A. Greer
2002-03-21 21:36 ` Jim Potter
[not found] <20020320164025.31626@mailhost.mipsys.com>
2002-03-20 16:59 ` Wolfgang Denk
[not found] <20020320155551.GD3762@opus.bloom.county>
2002-03-20 16:18 ` Wolfgang Denk
[not found] <20020320150119.GB3762@opus.bloom.county>
2002-03-20 15:43 ` Wolfgang Denk
2002-03-20 1:02 Michael Sokolov
[not found] <20020320000500.GV3762@opus.bloom.county>
2002-03-20 0:28 ` Wolfgang Denk
[not found] <20020319235815.GU3762@opus.bloom.county>
2002-03-20 0:24 ` Wolfgang Denk
[not found] <20020319231628.GQ3762@opus.bloom.county>
2002-03-19 23:46 ` Wolfgang Denk
[not found] <3C97A9C1.EBA150B6@mvista.com>
2002-03-19 23:36 ` Wolfgang Denk
[not found] <20020319224420.GO3762@opus.bloom.county>
2002-03-19 23:00 ` Wolfgang Denk
2002-03-20 0:03 ` Gabriel Paubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020320165825.31210@mailhost.mipsys.com \
--to=benh@kernel.crashing.org \
--cc=linux-galileo@source.mvista.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=msokolov@ivan.Harhan.ORG \
--cc=trini@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).