linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

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