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] <20020319224420.GO3762@opus.bloom.county>
2002-03-19 23:00 ` Wolfgang Denk
2002-03-20 0:03 ` Gabriel Paubert
[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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.