From: Jakob Viketoft <jakob.viketoft@bitsim.se>
To: Kumar Gala <kumar.gala@freescale.com>
Cc: Andrei Konovalov <akonovalov@ru.mvista.com>,
Sylvain Munaut <tnt@246tNt.com>,
Linux PPC Embedded list <linuxppc-embedded@ozlabs.org>
Subject: Re: Platform bus/ppc sys model...
Date: Wed, 30 Mar 2005 18:12:33 +0200 [thread overview]
Message-ID: <424ACFF1.5000403@bitsim.se> (raw)
In-Reply-To: <5a325f210dccfd254541824008e8c5a1@freescale.com>
Kumar Gala wrote:
> On Mar 30, 2005, at 7:52 AM, Andrei Konovalov wrote:
>> Do I understand correct that the ppc_sys model used by 85xx, 83xx, and
>> 52xx
>> SOCs is not so well suited for Virtex-II Pro (which Jakob and me bear
>> in mind)?
>> In case of Xilinx ???_devices.c could be the list of all the IPs
>> supported in linux.
>> But ???_sys.c has little sense as for any given combination of the
>> particular
>> Virtex-II Pro chip and the particular board the set of IPs (as well
>> as the memory
>> map, interrupt numbers, some hardware options (if ethernet has SGDMA
>> or not))
>> is not fixed. I.e. ideally we would need some kind of run time system
>> configuration
>> instead of compiled time system configuration implemented by ???_sys.c.
>
>
> This is correct. There is nothing that precludes us from building up a
> way to dynamically create the information. Is there some way to query
> the hardware itself, or is the information implied something else?
>
> - kumar
My intention was to give a device tree structure to the kernel at boot
time via a (pseudo?) pointer in bd_info or similar. Then you would only
need to recompile a little bootloader (which is needed for setting up
the FPGA anyway) with this structure for every specific card. You could
even be shrewd enough to have a single kernel image but several
structures to launch several processors on the same chip. Does it sound
like a sane solution?
Otherwise, I'm a bit unsure as to whether a system with a gigantic list
of devices in ???_devices.c is the right way to go. In the Xilinx case,
not only is a list of possible IP:s needed, but also the usual standard
circuits which can be connected from outside to the chip. Wouldn't it be
more realistic to have knowledge of the compiled in drivers somehow?
/Jakob
next prev parent reply other threads:[~2005-03-30 16:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-30 8:00 Platform bus/ppc sys model Jakob Viketoft
2005-03-30 9:54 ` Sylvain Munaut
2005-03-30 13:52 ` Andrei Konovalov
2005-03-30 15:06 ` Kumar Gala
2005-03-30 16:12 ` Jakob Viketoft [this message]
2005-03-30 17:26 ` Kumar Gala
2005-03-31 12:33 ` Jon Masters
2005-03-31 15:55 ` Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...] Jon Loeliger
2005-04-04 7:20 ` Jakob Viketoft
2005-04-04 7:31 ` Jon Masters
2005-04-04 10:56 ` Andrei Konovalov
2005-04-04 11:01 ` Jon Masters
2005-04-04 11:08 ` Jakob Viketoft
2005-04-04 16:45 ` Wolfgang Denk
2005-04-04 16:58 ` Andrei Konovalov
2005-04-04 16:56 ` Jon Masters
2005-04-07 17:20 ` Tom Rini
2005-04-07 17:35 ` Jon Loeliger
2005-04-07 17:49 ` Tom Rini
2005-04-11 15:58 ` Jon Loeliger
2005-04-14 9:54 ` Jakob Viketoft
2005-04-15 14:22 ` Jon Loeliger
2005-04-22 17:33 ` Andrei Konovalov
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=424ACFF1.5000403@bitsim.se \
--to=jakob.viketoft@bitsim.se \
--cc=akonovalov@ru.mvista.com \
--cc=kumar.gala@freescale.com \
--cc=linuxppc-embedded@ozlabs.org \
--cc=tnt@246tNt.com \
/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.