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 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).