* Re: [PATCH 13/16] ehca: firmware InfiniBand interface
From: Kyle Moffett @ 2006-04-27 17:13 UTC (permalink / raw)
To: Jörn Engel
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <20060427123701.GG32127@wohnheim.fh-wedel.de>
On Apr 27, 2006, at 08:37:01, J=F6rn Engel wrote:
> On Thu, 27 April 2006 12:49:36 +0200, Heiko J Schick wrote:
>> +u64 hipz_h_alloc_resource_qp(const struct ipz_adapter_handle
>> adapter_handle,
>> + struct ehca_pfqp *pfqp,
>> + const u8 servicetype,
>> + const u8 daqp_ctrl,
>> + const u8 signalingtype,
>> + const u8 ud_av_l_key_ctl,
>> + const struct ipz_cq_handle send_cq_handle,
>> + const struct ipz_cq_handle =
receive_cq_handle,
>> + const struct ipz_eq_handle async_eq_handle,
>> + const u32 qp_token,
>> + const struct ipz_pd pd,
>> + const u16 max_nr_send_wqes,
>> + const u16 max_nr_receive_wqes,
>> + const u8 max_nr_send_sges,
>> + const u8 max_nr_receive_sges,
>> + const u32 ud_av_l_key,
>> + struct ipz_qp_handle *qp_handle,
>> + u32 * qp_nr,
>> + u16 * act_nr_send_wqes,
>> + u16 * act_nr_receive_wqes,
>> + u8 * act_nr_send_sges,
>> + u8 * act_nr_receive_sges,
>> + u32 * nr_sq_pages,
>> + u32 * nr_rq_pages,
>> + struct h_galpas *h_galpas);
>
> 25 parameters? If you tell me which drugs were involved in this =20
> code, I know what to stay away from. Might be the current record =20
> for any code ever proposed for inclusion.
>
> The whole patch is full of parameter-happy functions with this one =20
> being the ugly top of the iceberg. I sincerely hope this is not a =20
> defined ABI and can still be changed.
What's worse; look at the stack usage on that sucker alone:
10 pointers, 6 u8, 2 u16, 2 u32, and topped off with 3 unknown-sized =20
"struct ipz_cq_handle", an unknown-sized "struct ipz_pd". The =20
alignment alone probably chews up at least another couple bytes in =20
there somewhere too. That's at _least_ 98 + 3*sizeof(struct =20
ipz_cq_handle) + sizeof(struct ipz_pd) on a 64-bit platform (58 + =20
3*sizeof(struct ipz_cq_handle) + sizeof(struct ipz_pd) on 32-bit). =20
Not to mention the fact that you totally screwed the compiler's =20
chances of ever passing the important stuff in registers. And you =20
haven't even gotten into local variables yet.
Cheers,
Kyle Moffett
^ permalink raw reply
* RE: [QUESTION] MPC834x DMA Support
From: KRONSTORFER Horst @ 2006-04-27 17:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Donnerstag, 27. April 2006 17:25
> To: KRONSTORFER Horst
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [QUESTION] MPC834x DMA Support
>=20
>=20
> On Apr 27, 2006, at 5:37 AM, KRONSTORFER Horst wrote:
>=20
> > hi!
> >
> > does anyone know if the mpc834x's dma unit supports dma=20
> operation only=20
> > between pci and csb or also between csb and csb, f.e. devices=20
> > connected via the lbc (f.e. ram and a dsp)?
>=20
> You should be able to do csb to csb devices.
thanks for the hint!
-h
>=20
> - kumar
>=20
^ permalink raw reply
* RE: [QUESTION] MPC834x DMA Support
From: KRONSTORFER Horst @ 2006-04-27 17:23 UTC (permalink / raw)
To: wd; +Cc: linuxppc-dev
> -----Original Message-----
> From: wd@denx.de [mailto:wd@denx.de]=20
> Sent: Donnerstag, 27. April 2006 18:28
> To: KRONSTORFER Horst
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [QUESTION] MPC834x DMA Support=20
>=20
> In message=20
> <C5BA91F04186584EB68FD42BB4993E6BC1B5C6@FRQWOLEX01.frequentis.
> frq> you wrote:
> >=20
> > does anyone know if the mpc834x's dma unit supports dma=20
> operation only=20
> > between pci and csb or also between csb and csb, f.e. devices=20
> > connected via the lbc (f.e. ram and a dsp)?
>=20
> This should work. We used this to initialize ECC memory. =20
> But be careful about your performance expectations - ask=20
> Freescale what you can get out of memory to memory DMA.=20
> [Sorry, I'm still waiting for replies from FSL myself.]
>
thanks for the hints!
-h
=20
> Best regards,
>=20
> Wolfgang Denk
>=20
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:=20
> wd@denx.de You speak of courage. Obviously you do not know=20
> the difference bet- ween courage and foolhardiness. Always=20
> it is the brave ones who die, the soldiers.
> -- Kor, the Klingon Commander, "Errand of Mercy",
> stardate 3201.7
>=20
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Eugene Surovegin @ 2006-04-27 18:01 UTC (permalink / raw)
To: Stephen Williams; +Cc: linuxppc-embedded
In-Reply-To: <445008E1.70404@icarus.com>
On Wed, Apr 26, 2006 at 04:57:21PM -0700, Stephen Williams wrote:
> Is there a git tree for main line 2.4 maintenance
> (against which I could maintain patches)
git://git.kernel.org/pub/scm/linux/kernel/git/marcelo/linux-2.4.git
--
Eugene
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Eugene Surovegin @ 2006-04-27 18:07 UTC (permalink / raw)
To: Matt Porter; +Cc: Stephen Williams, linuxppc-embedded
In-Reply-To: <20060426163540.H16236@cox.net>
On Wed, Apr 26, 2006 at 04:35:40PM -0700, Matt Porter wrote:
> linuxppc-2.4 tree to linux-2.4. Oh, and Marcelo didn't want
> to take "new stuff" into linux-2.4 at that time either.
>
> There's still rsync://source.mvista.com/linuxppc-2.4 available with
> the 405gpr/sycamore support.
There are bigger problems with 4xx support in 2.4 mainline than just
missing some chips support.
Some parts which are already in 2.4 (e.g. ethernet driver) are of
non-production quality.
I can imagine Marcelo agreeing to commit 405GPr/405EP support as this
change shouldn't break anything, but this will not make 2.4 support
really useful for real world deployments. I think we are stuck with
maintaining our own 2.4 trees with backports from 2.6. This is what I
do myself of all our products (and yeah, diff between stock 2.4.32 and
my internal version has already grown quite big to be acceptable for
2.4 inclusion).
--
Eugene
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-27 18:18 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <20060426191957.14C4F353DAC@atlas.denx.de>
On Apr 26, 2006, at 2:19 PM, Wolfgang Denk wrote:
> In message <A8793E99-83C1-4FD9-8735-
> D2E8F98B3003@kernel.crashing.org> you wrote:
>>
>> I think thats part of the idea with arch/powerpc defining a standard
>> mechanism for how a boot loader should pass information to the kernel
>> (via a flat device tree).
>
> Yet another standard.
>
>> How would you propose that we handle booting arch/powerpc kernels
>> from u-boot going forward? (for new board ports and existing board
>> ports).
>
> Ideally, I'd like to see a common kernel interface for all archi-
> tectures, PowerPC and ARM and MIPS and ... But last time I dared to
> suggest this I've been told what a nincompoop I am.
>
> I will accept what is decided by the P.T.B., but I request not to
> break backwards compatibility with existing systems.
I've been thinking about the various issues related to booting an
arch/powerpc kernel via u-boot. I was hoping to get some ideas/
comments on what people thought about the various issues/questions
related to producing a system that can boot an arch/powerpc kernel
for an embedded system. I'm using u-boot as the boot loader since
its a popular choice (I imagine the issues are similar for others):
[NOTE: dts, flat dev tree, etc are used interchangeably]
1. boot with an "old" u-boot (via bd_t):
* Have a boot wrapper that takes bd_t and dts and merges them @ runtime
* Boot wrapper has to be custom based on bd_t definition for the system
* dts owned by kernel??
2. boot with a "new" u-boot (has a .dts in it):
* capable of booting arch/powerpc kernel directly w/o modification
* in a production system don't want to update u-boot
* dts owned by u-boot??
Some questions/issues:
* ownership of .dts is problematic. I hate having a file duplicated
by both u-boot and kernel. However it also seems bad to make the
build of either depend on the user grabbing a dts from some third
party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS
port. Boards ship with an "old" u-boot, thus we need a kernel
wrapper with .dts. However, newer u-boot's can (hopefully will) have
a dts in them
* updating of dts: In case 1, this is trivial since its part of the
kernel blob. Case 2. is more difficult. What do people think of
treating the dts like the environment. You have a version compiled
in, but can alternately have a blob in another location that will be
used if exists. This would allow one to update the dts portion w/o
effecting the actual boot loader.
* one solution to the copies of .dts is that we make the wrapper
portion of the kernel the owner of the official latest and
greatest .dts. Every so often a maintainer can sync their .dts with
u-boot to keep them relatively in sync. However, the main mechanism
would be to load the latest .dts blob into the secondary location.
We can provide scripts/tools to do this via u-boot and linux.
comments, other issues people have thought of?
- kumar
^ permalink raw reply
* Re-configuring busybox that comes with DENX's ELDK SELF
From: Randy Smith @ 2006-04-27 18:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060427180743.GB11206@gate.ebshome.net>
Hello,
I have a weird situation that I am very confused about and I was
wondering if some kind soul would point me in the right direction?
I have a working powerpc embedded system using the 2.4 kernel built with
DENX' ELDK and root file system from DENX' SELF.
I am trying to enable some additional applets in the busybox (well, tftp
anyway) that came with SELF. I am using the ELDK cross toolchain on an
x86 box to build everything and the powerpc board itself is based on an
Icecube board. I thought I could do the following...
1. Download the source for busybox and compile it using the cross tools
from DENX.
2. Install it in my target root file system
3. Make the jffs2 file system image and flash it into the unit under test.
When I do this, the kernel loads and boots just like before and then
hangs after is says it is freeing unused memory. I am assuming that this
is where it is trying to run the new init that I just installed, so
obviously it isn't working like I planned.
Where did I go wrong?
I am thinking that I have a library mismatch/issue and that the new init
binary can't/won't run with the runtime libraries that come with SELF,
but I don't know how to go about correcting this if this is the case.
Opinions or urls to tutorials welcome.
Thanks,
-Randy Smith
Software Engineer
Imagemap, Inc.
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Stephen Williams @ 2006-04-27 18:32 UTC (permalink / raw)
To: Matt Porter, linuxppc-embedded
In-Reply-To: <20060427180743.GB11206@gate.ebshome.net>
Eugene Surovegin wrote:
> There are bigger problems with 4xx support in 2.4 mainline than just
> missing some chips support.
>
> Some parts which are already in 2.4 (e.g. ethernet driver) are of
> non-production quality.
>
> I can imagine Marcelo agreeing to commit 405GPr/405EP support as this
> change shouldn't break anything, but this will not make 2.4 support
> really useful for real world deployments. I think we are stuck with
> maintaining our own 2.4 trees with backports from 2.6. This is what I
> do myself of all our products (and yeah, diff between stock 2.4.32 and
> my internal version has already grown quite big to be acceptable for
> 2.4 inclusion).
>
Of course we are going to have to keep our own per-board trees.
but the blatantly common stuff, like the core 405gpr support and
certain drivers, might as well go in if the gatekeeper can be
convinced. You and I both probably have huge drivers for custom
devices hanging off our PPCs, with various hacks to squeeze extra
performance out. These make our transition to 2.6 difficult, and
surely we are not alone.
So 2.4 is going to be around for a while longer for us, so we might
as well make an effort to keep the house in some sort of order. It
serves no one to keep these fixes a secret:-)
In any case, if the patches I sent are rejected, then that's that.
We'll see.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Eugene Surovegin @ 2006-04-27 19:04 UTC (permalink / raw)
To: Stephen Williams; +Cc: linuxppc-embedded
In-Reply-To: <44510E4D.5040504@icarus.com>
On Thu, Apr 27, 2006 at 11:32:45AM -0700, Stephen Williams wrote:
> Eugene Surovegin wrote:
> > There are bigger problems with 4xx support in 2.4 mainline than just
> > missing some chips support.
> >
> > Some parts which are already in 2.4 (e.g. ethernet driver) are of
> > non-production quality.
> >
> > I can imagine Marcelo agreeing to commit 405GPr/405EP support as this
> > change shouldn't break anything, but this will not make 2.4 support
> > really useful for real world deployments. I think we are stuck with
> > maintaining our own 2.4 trees with backports from 2.6. This is what I
> > do myself of all our products (and yeah, diff between stock 2.4.32 and
> > my internal version has already grown quite big to be acceptable for
> > 2.4 inclusion).
> >
>
> Of course we are going to have to keep our own per-board trees.
> but the blatantly common stuff, like the core 405gpr support and
> certain drivers, might as well go in if the gatekeeper can be
> convinced. You and I both probably have huge drivers for custom
> devices hanging off our PPCs, with various hacks to squeeze extra
> performance out. These make our transition to 2.6 difficult, and
> surely we are not alone.
Well, personally, I don't migrate to 2.6 not because I have many custom
drivers in my tree (if they are properly written, migration is
relatively easy), but because 2.6 in my opinion isn't production
ready, at least for architectures I work with. 2.6 is slower, bigger,
is constantly being broken by huge amount of changes, etc. I spent
enough time making 2.4 work on our hardware given limitations and
requirements put on performance, resources etc. I just don't have time
to go through this cycle again. And I'm not talking about PPC stuff, I
mean mostly generic stuff - filesystems, scheduling, networking, etc.
> So 2.4 is going to be around for a while longer for us, so we might
> as well make an effort to keep the house in some sort of order. It
> serves no one to keep these fixes a secret:-)
They aren't secret, but I can understand the simple fact that 2.4 is
closed for a new stuff, we might not like that (although I do, just
look at the mess "stable" 2.6 is :).
There is a point in every piece of software life-cycle when you have
to stop adding features. 2.4 is already at this point, and we should
accept that.
--
Eugene
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-27 19:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <6E3621C5-A379-4ABC-99C0-9A02B48D525D@kernel.crashing.org>
In message <6E3621C5-A379-4ABC-99C0-9A02B48D525D@kernel.crashing.org>
Kumar Gala wrote:
>
> 1. boot with an "old" u-boot (via bd_t):
> * Have a boot wrapper that takes bd_t and dts and merges them @ runtime
> * Boot wrapper has to be custom based on bd_t definition for the system
> * dts owned by kernel??
Since we cannot go back in time and fix the "old" U-Boot this seems
to be the only option.
> 2. boot with a "new" u-boot (has a .dts in it):
> * capable of booting arch/powerpc kernel directly w/o modification
OK.
> * in a production system don't want to update u-boot
Let's say we have to support such situations, too.
> * dts owned by u-boot??
I'm not sure about this. I tend to believe the dts belongs to the
kernel.
> Some questions/issues:
> * ownership of .dts is problematic. I hate having a file duplicated
> by both u-boot and kernel. However it also seems bad to make the
> build of either depend on the user grabbing a dts from some third
> party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS
> port. Boards ship with an "old" u-boot, thus we need a kernel
> wrapper with .dts. However, newer u-boot's can (hopefully will) have
> a dts in them
Can we provide the dts as a separate blob that gets built with the
kernel image? From U-Boot's point of view, this could be a multi-file
image which combines the dts and the kernel into a single file so
that users don't have to care much about this.
> * updating of dts: In case 1, this is trivial since its part of the
> kernel blob. Case 2. is more difficult. What do people think of
> treating the dts like the environment. You have a version compiled
I don't like this idea.
> in, but can alternately have a blob in another location that will be
> used if exists. This would allow one to update the dts portion w/o
> effecting the actual boot loader.
If we consider this, then we might as well combine the dts with the
kernel image. Alternatively, the dts might be stored in a separate
location in memory. It would be easy to extend the "bootm" command to
take an additional argument (dts address).
> * one solution to the copies of .dts is that we make the wrapper
> portion of the kernel the owner of the official latest and
> greatest .dts. Every so often a maintainer can sync their .dts with
> u-boot to keep them relatively in sync. However, the main mechanism
> would be to load the latest .dts blob into the secondary location.
Why not load it separately or as part of the Linux kernel image?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
No user-servicable parts inside. Refer to qualified service personnel.
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-27 19:20 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <20060427190547.1DD90353DAC@atlas.denx.de>
> Let's say we have to support such situations, too.
>
>> * dts owned by u-boot??
>
> I'm not sure about this. I tend to believe the dts belongs to the
> kernel.
>
>> Some questions/issues:
>> * ownership of .dts is problematic. I hate having a file duplicated
>> by both u-boot and kernel. However it also seems bad to make the
>> build of either depend on the user grabbing a dts from some third
>> party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS
>> port. Boards ship with an "old" u-boot, thus we need a kernel
>> wrapper with .dts. However, newer u-boot's can (hopefully will) have
>> a dts in them
>
> Can we provide the dts as a separate blob that gets built with the
> kernel image? From U-Boot's point of view, this could be a multi-file
> image which combines the dts and the kernel into a single file so
> that users don't have to care much about this.
The problem is that there are somethings that u-boot knows that needs
to go into the blob (memory size, boot args, initrd info,
frequencies, etc.)
>> * updating of dts: In case 1, this is trivial since its part of the
>> kernel blob. Case 2. is more difficult. What do people think of
>> treating the dts like the environment. You have a version compiled
>
> I don't like this idea.
>
>> in, but can alternately have a blob in another location that will be
>> used if exists. This would allow one to update the dts portion w/o
>> effecting the actual boot loader.
>
> If we consider this, then we might as well combine the dts with the
> kernel image. Alternatively, the dts might be stored in a separate
> location in memory. It would be easy to extend the "bootm" command to
> take an additional argument (dts address).
How would we distinguish the bootm command that takes a blob versus
the ones we have today?
>> * one solution to the copies of .dts is that we make the wrapper
>> portion of the kernel the owner of the official latest and
>> greatest .dts. Every so often a maintainer can sync their .dts with
>> u-boot to keep them relatively in sync. However, the main mechanism
>> would be to load the latest .dts blob into the secondary location.
>
> Why not load it separately or as part of the Linux kernel image?
As stated before, the main issue is doing some runtime fix ups to the
blob before its handed to the kernel.
The following pieces of info are setup at runtime that are board
specific:
linux,stdout_path
cpus/<foo>/clock-frequency
cpus/<foo>/timebase-frequency
cpus/<foo>/bus-frequency
<soc>/pci/bus-range
<soc>/bus-frequency
<soc>/serial/clock-frequecny
<soc>/ethernet/address
We could hand bootm a memory location with a blob and do the fix ups
at runtime, we would still have some coupling between the blob and u-
boot build. At least the blob wouldn't be built into u-boot.
- kumar
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-27 19:40 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, U-Boot Users
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859673@ismail.innsys.innovsys.com>
On Apr 27, 2006, at 2:30 PM, Rune Torgersen wrote:
> Would it be possible to have the kernel smart enough that if it gets
> passed a bd_t pointer, it updates the dts before booting fully.
> Newer u-boot versions that support dts then would pass a NULL bd_t
> pointer to a kernel that supports dts. Kernel would then not update
> the
> dts, but use the one it gets handed.
What you are describing is the boot shim method.
U-boot is already capable of effectively doing this. You can set a u-
boot environment variable to make bootm do different things if you
have flat device tree support built into u-boot.
> bootm should be able to see if the kernel has an attached dts,
> update it
> with runtime parameters, and hand it off to the kernel. If it is an
> old
> kernel, hand it the bd_t pointer.
We can do this w/o too much modification to what is happening in u-
boot today. I'd probably like to keep the ability to build a dev
tree into the u-boot binary, but make the preferred means to pass a
blob into the bootm command.
- kumar
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-27 19:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org>
In message <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org> you wrote:
>
> The problem is that there are somethings that u-boot knows that needs
> to go into the blob (memory size, boot args, initrd info,
> frequencies, etc.)
Yes. Can we append auch variable data to the fixed part of the dts?
> How would we distinguish the bootm command that takes a blob versus
> the ones we have today?
Arg count. For example:
OLD: bootm <kernel_addr>
or bootm <kernel_addr> <ramdisk_addr>
NEW: bootm <kernel_addr> - <dts_addr>
or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
> As stated before, the main issue is doing some runtime fix ups to the
> blob before its handed to the kernel.
Let's do exactly this: runtime fix ups.
> We could hand bootm a memory location with a blob and do the fix ups
> at runtime, we would still have some coupling between the blob and u-
> boot build. At least the blob wouldn't be built into u-boot.
OK.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It is necessary to have purpose.
-- Alice #1, "I, Mudd", stardate 4513.3
^ permalink raw reply
* RE: FT u-boot shim
From: Rune Torgersen @ 2006-04-27 19:30 UTC (permalink / raw)
To: Kumar Gala, Wolfgang Denk; +Cc: linuxppc-dev, U-Boot Users
Would it be possible to have the kernel smart enough that if it gets
passed a bd_t pointer, it updates the dts before booting fully.=20
Newer u-boot versions that support dts then would pass a NULL bd_t
pointer to a kernel that supports dts. Kernel would then not update the
dts, but use the one it gets handed.
bootm should be able to see if the kernel has an attached dts, update it
with runtime parameters, and hand it off to the kernel. If it is an old
kernel, hand it the bd_t pointer.
^ permalink raw reply
* Re: [U-Boot-Users] Re: FT u-boot shim
From: Kumar Gala @ 2006-04-27 19:42 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <44511C88.1010107@smiths-aerospace.com>
[snip]
> A thought that keeps recurring (but I've suppressed because I don't
> have time to play...) is that it would be Really Cool[tm] to store
> the u-boot env variables in a flat tree and then pass the env/tree
> to linux. It also sounds like a major change & disruption to u-
> boot :-(. I haven't looked at what it would do to code size either.
I believe this is already supported in u-boot as a config option.
You can also pass the bd_t to the kernel via the flat dev tree if you
want.
- kumar
^ permalink raw reply
* Re: [U-Boot-Users] Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-27 19:43 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <44511C88.1010107@smiths-aerospace.com>
In message <44511C88.1010107@smiths-aerospace.com> you wrote:
>
> A thought that keeps recurring (but I've suppressed because I don't have
> time to play...) is that it would be Really Cool[tm] to store the u-boot
> env variables in a flat tree and then pass the env/tree to linux. It
If somebody wants to read the environment variables, you don't need
to create a flat tree from it.
Also, it doesn't solve the original problem as most of the informa-
tion you need to pass is NOT part of the environment (and shall not
become such a part).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I thought my people would grow tired of killing. But you were right,
they see it is easier than trading. And it has its pleasures. I feel
it myself. Like the hunt, but with richer rewards.
-- Apella, "A Private Little War", stardate 4211.8
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-27 19:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, U-Boot Users
In-Reply-To: <2CD98C5D-E51C-49CA-9BDC-6FE4C1B67854@kernel.crashing.org>
In message <2CD98C5D-E51C-49CA-9BDC-6FE4C1B67854@kernel.crashing.org> you wrote:
>
> We can do this w/o too much modification to what is happening in u-
> boot today. I'd probably like to keep the ability to build a dev
> tree into the u-boot binary, but make the preferred means to pass a
I don't like this, as it's a very Linux-centric view, but U-Boot is
supposed to be OS unaware and independent.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Q: Why do PCs have a reset button on the front?
A: Because they are expected to run Microsoft operating systems.
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-27 19:46 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <20060427194055.3EED1353A57@atlas.denx.de>
On Apr 27, 2006, at 2:40 PM, Wolfgang Denk wrote:
> In message
> <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org> you wrote:
>>
>> The problem is that there are somethings that u-boot knows that needs
>> to go into the blob (memory size, boot args, initrd info,
>> frequencies, etc.)
>
> Yes. Can we append auch variable data to the fixed part of the dts?
appending is not really how it works, but the runtime fixup is doable.
>> How would we distinguish the bootm command that takes a blob versus
>> the ones we have today?
>
> Arg count. For example:
>
> OLD: bootm <kernel_addr>
> or bootm <kernel_addr> <ramdisk_addr>
>
> NEW: bootm <kernel_addr> - <dts_addr>
> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
>
>> As stated before, the main issue is doing some runtime fix ups to the
>> blob before its handed to the kernel.
>
> Let's do exactly this: runtime fix ups.
>
>> We could hand bootm a memory location with a blob and do the fix ups
>> at runtime, we would still have some coupling between the blob and u-
>> boot build. At least the blob wouldn't be built into u-boot.
>
> OK.
Let me play with this some now that I've got some direction.
- kumar
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-27 19:54 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, U-Boot Users
In-Reply-To: <20060427194522.6FA1B353A57@atlas.denx.de>
On Apr 27, 2006, at 2:45 PM, Wolfgang Denk wrote:
> In message <2CD98C5D-
> E51C-49CA-9BDC-6FE4C1B67854@kernel.crashing.org> you wrote:
>>
>> We can do this w/o too much modification to what is happening in u-
>> boot today. I'd probably like to keep the ability to build a dev
>> tree into the u-boot binary, but make the preferred means to pass a
>
> I don't like this, as it's a very Linux-centric view, but U-Boot is
> supposed to be OS unaware and independent.
Hmm, I guess. There really isn't anything about the device tree that
is Linux specific. Other OSes could choice to use it. But lets
argue about that one once I've got the mechanism in which we pass the
blob in via the bootm command.
The only difference I see would be that the address of the blob would
be implicit if the blob was built into u-boot. We would still use a
passed in blob via the bootm command if given.
- kumar
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-27 19:59 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <20060427194055.3EED1353A57@atlas.denx.de>
>> How would we distinguish the bootm command that takes a blob versus
>> the ones we have today?
>
> Arg count. For example:
>
> OLD: bootm <kernel_addr>
> or bootm <kernel_addr> <ramdisk_addr>
>
> NEW: bootm <kernel_addr> - <dts_addr>
> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
do you mean a literal '-' char for the no ramdisk, but dts case?
- kumar
^ permalink raw reply
* Re: FT u-boot shim
From: Jerry Van Baren @ 2006-04-27 19:33 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org list; +Cc: U-Boot Users
In-Reply-To: <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org>
Kumar Gala wrote:
>> Let's say we have to support such situations, too.
>>
>>> * dts owned by u-boot??
>> I'm not sure about this. I tend to believe the dts belongs to the
>> kernel.
>>
>>> Some questions/issues:
>>> * ownership of .dts is problematic. I hate having a file duplicated
>>> by both u-boot and kernel. However it also seems bad to make the
>>> build of either depend on the user grabbing a dts from some third
>>> party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS
>>> port. Boards ship with an "old" u-boot, thus we need a kernel
>>> wrapper with .dts. However, newer u-boot's can (hopefully will) have
>>> a dts in them
>> Can we provide the dts as a separate blob that gets built with the
>> kernel image? From U-Boot's point of view, this could be a multi-file
>> image which combines the dts and the kernel into a single file so
>> that users don't have to care much about this.
>
> The problem is that there are somethings that u-boot knows that needs
> to go into the blob (memory size, boot args, initrd info,
> frequencies, etc.)
[snip]
> - kumar
A thought that keeps recurring (but I've suppressed because I don't have
time to play...) is that it would be Really Cool[tm] to store the u-boot
env variables in a flat tree and then pass the env/tree to linux. It
also sounds like a major change & disruption to u-boot :-(. I haven't
looked at what it would do to code size either.
U-boot could then be a better OpenBoot than OpenBoot ;-)
gvb
^ permalink raw reply
* Re: [U-Boot-Users] Re: FT u-boot shim
From: Jerry Van Baren @ 2006-04-27 20:40 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org list; +Cc: U-Boot Users
In-Reply-To: <20060427194316.CBFBC353A57@atlas.denx.de>
Wolfgang Denk wrote:
> In message <44511C88.1010107@smiths-aerospace.com> you wrote:
>> A thought that keeps recurring (but I've suppressed because I don't have
>> time to play...) is that it would be Really Cool[tm] to store the u-boot
>> env variables in a flat tree and then pass the env/tree to linux. It
>
> If somebody wants to read the environment variables, you don't need
> to create a flat tree from it.
Understood. That is why it is Really Cool[tm] rather than Really
Useful[tm] ;-)
> Also, it doesn't solve the original problem as most of the informa-
> tion you need to pass is NOT part of the environment (and shall not
> become such a part).
>
> Best regards,
> Wolfgang Denk
I agree and disagree with the parenthetical part of your statement.
Agree because it _wouldn't_ be a part of u-boot (technically it would be
if someone put it in their default env for their specific board, but why
would denx.de care?).
Disagree because, while u-boot needs/uses some env variables,
engineers/companies/end users are free to add variables and, I dare say,
most do. If a given board needs to pass certain non u-boot parameters
to linux, it would simply add that to its env (which already happens).
I'm not sure you (Wolfgang and Kumar) are following my thought fully (or
my ignorance is showing to everybody but me). The thought is to change
the native format of the u-boot environment storage from the
key-string/value-string pairs to the flat tree (OpenFirmware) format
which still supports the same key-string/value-string capability (but
can do more than that).
The advantage, as I see it, is that it would be unifying and thus easier
to maintain the common variables (call it the GRand Unifying Flat Tree
(GRAFT) ;-). One language (flat tree), no shims, equivalent key/value
utility (but a different underlying storage format), no visible
difference for the users (but potentially an upgrade challenge for
existing boards and env variables).
The disadvantage is that it would be disruptive to u-boot and may cause
some bloating and discomfort.
gvb
(the naive)
P.S. For the non-USA readers: "may cause some bloating and discomfort"
is a standard disclaimer on medicines advertised on TV over here.
^ permalink raw reply
* Re: [PATCH 00/16] ehca: IBM eHCA InfiniBand Device Driver
From: Heiko Joerg Schick @ 2006-04-27 19:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, linux-kernel, openib-general
In-Reply-To: <20060427125726.GK32127@wohnheim.fh-wedel.de>
On 2006-04-27 14:57:26 +0200, Jörn Engel <joern@wohnheim.fh-wedel.de> said:
> Don't expect much cheer and rejoicing over this. I suspect that akpm
> or Linus will either want the 17 patches merged into one or have a
> patchset where every single patch leaves the kernel in a working
> state, including working eHCA driver.
I don't like the idea to put the whole driver in one patch file. I
would propose to put the patch "ehca: integration in Linux kernel" last
instead
of first, as Arnd mentioned. With that change we leave the kernel in a
working state when applying the patches.
Regards,
Heiko
^ permalink raw reply
* TI1520 Cardbus with CF troubles
From: Travis B. Sawyer @ 2006-04-27 21:12 UTC (permalink / raw)
To: linuxppc-embedded
Greetings:
I'm working on getting some cardbus support into a 8540 based platform.
We're using a TI1520 cardbus controller (pci<->cardbus bridge) and
compact flash.
(Note: this is using 2.4.30 kernel.org kernel + some patches from the
vendor)
At first I was getting no interrupts when the yenta driver was starting
up, but
I back ported some stuff from 2.6 and now the ti1520 is routing the
interrupts
properly through pci:
[root@mbc80-4 01]$ cat /proc/interrupts
CPU0
8: 0 None Edge rtc
83: 12106 OpenPIC Edge enet_tx
84: 19011 OpenPIC Edge enet_rx
88: 0 OpenPIC Edge enet_error
90: 1805 OpenPIC Edge serial
91: 137 OpenPIC Level MPC I2C
98: 1 OpenPIC Level Texas Instruments PCI1250 PC card
Cardbus Controller
99: 1 OpenPIC Level Texas Instruments PCI1250 PC card
Cardbus Controller (#2)
101: 0 OpenPIC Level sb/ife0
102: 0 OpenPIC Level sbqe0
104: 0 OpenPIC Level phy_interrupt
BAD: 0
I have a cf card in the second controller socket. I've strewn printk's
all over and what I'm
finding is that pcmcia_request_io is called with base=0 numports=0x10,
ioAddrLines=4, and
returns with a base of 0x8100.
Here's the pci dump of both functions of the TI device (note, the card
is plugged into the
socket associated with func 1 not func 0):
[root@mbc80-4 01]$ lspci -v -s 01:01
01:01.0 CardBus bridge: Texas Instruments PCI1250 PC card Cardbus
Controller (rev 01)
Flags: bus master, medium devsel, latency 168, IRQ 98
Memory at eafff000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=01, secondary=02, subordinate=02, sec-latency=176
Memory window 0: ea600000-ea61f000 (prefetchable)
Memory window 1: ea700000-ea7ff000
I/O window 0: 00008000-000080ff
I/O window 1: 00008400-000084ff
16-bit legacy interface ports at 0001
01:01.1 CardBus bridge: Texas Instruments PCI1250 PC card Cardbus
Controller (rev 01)
Flags: bus master, medium devsel, latency 168, IRQ 99
Memory at eabfe000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=01, secondary=03, subordinate=03, sec-latency=176
Memory window 0: ea620000-ea63f000 (prefetchable)
Memory window 1: ea800000-ea8ff000
I/O window 0: 00008800-000088ff
I/O window 1: 00008c00-00008cff
16-bit legacy interface ports at 0001
I added printks to the ide do_probe, and all hwif->INB() calls return 0.
My /etc/pcmcia/config.opts adds the following lines:
include port 0x0000-0xffff
include memory 0xe0000000-0xeaffffff
Any ideas?
-travis
more dumps below:
[root@mbc80-4 01]$ cardctl status
Socket 0:
no card
Socket 1:
3.3V 16-bit PC Card
function 0: [ready]
[root@mbc80-4 01]$ cardctl config
Socket 0:
not configured
Socket 1:
Vcc 3.3V Vpp1 3.3V Vpp2 3.3V
ide_config linkio: nports: 0 baseport 0
pcmcia_request_io calling alloc io spaces BLP1 NP1 IOADDRLines: 0 10 4
alloc_io_space s->io BP NP Inuse: 8100 10 10
pcmcia_request_io called alloc io spaces BLP1 NP1 IOADDRLines: 8100 10 4
ide_config b4Config base 8100
ide_config AFConfig base 8100
SELECT_DRIVE sending a0 to 8106
SELECT_DRIVE sending b0 to 8106
SELECT_DRIVE sending a0 to 8106
probing for hda: present=0, media=32, probetype=ATA
[root@mbc80-4 01]$ SELECT_DRIVE sending a0 to 8106
do_probe after select inb= 0
do_probe error reg 0
do_probe nsect reg 0
do_probe sect reg 0
do_probe lcyl reg 0
do_probe hcyl reg 0
do_probe selct reg 0
do_probe stats reg 0
do_probe cntrl reg 0
[root@mbc80-4 ~]$ dump_cis
Socket 0:
no CIS present
Socket 1:
dev_info
fn_specific 120ns, 2kb
common_jedec 0xdf 0x01
manfid 0x0045, 0x0401
vers_1 4.1, "SanDisk", "SDP", "5/3 0.6"
funcid fixed_disk [post]
disk_interface [ide]
disk_features [silicon] [unique] [single]
[sleep] [standby] [idle] [low power]
config base 0x0200 mask 0x000f last_index 0x07
cftable_entry 0x00 [default]
[rdybsy] [mwait] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
memory 0x0000-0x07ff @ 0x0000
cftable_entry 0x00
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x01 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
io 0x0000-0x000f [lines=4] [8bit] [16bit]
irq mask 0xffff [level] [pulse] [shared]
cftable_entry 0x01
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x02 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
io 0x01f0-0x01f7, 0x03f6-0x03f7 [lines=10] [8bit] [16bit] [range]
irq 14 [level] [pulse] [shared]
cftable_entry 0x02
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x03 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
io 0x0170-0x0177, 0x0376-0x0377 [lines=10] [8bit] [16bit] [range]
irq 14 [level] [pulse] [shared]
cftable_entry 0x03
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x07
^ permalink raw reply
* Re: [U-Boot-Users] Re: FT u-boot shim
From: Pantelis Antoniou @ 2006-04-27 21:25 UTC (permalink / raw)
To: u-boot-users; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <44512C25.2080105@smiths-aerospace.com>
On Thursday 27 April 2006 23:40, Jerry Van Baren wrote:
> Wolfgang Denk wrote:
> > In message <44511C88.1010107@smiths-aerospace.com> you wrote:
> >> A thought that keeps recurring (but I've suppressed because I don't have
> >> time to play...) is that it would be Really Cool[tm] to store the u-boot
> >> env variables in a flat tree and then pass the env/tree to linux. It
> >
> > If somebody wants to read the environment variables, you don't need
> > to create a flat tree from it.
>
> Understood. That is why it is Really Cool[tm] rather than Really
> Useful[tm] ;-)
>
> > Also, it doesn't solve the original problem as most of the informa-
> > tion you need to pass is NOT part of the environment (and shall not
> > become such a part).
> >
> > Best regards,
> > Wolfgang Denk
>
> I agree and disagree with the parenthetical part of your statement.
> Agree because it _wouldn't_ be a part of u-boot (technically it would be
> if someone put it in their default env for their specific board, but why
> would denx.de care?).
>
> Disagree because, while u-boot needs/uses some env variables,
> engineers/companies/end users are free to add variables and, I dare say,
> most do. If a given board needs to pass certain non u-boot parameters
> to linux, it would simply add that to its env (which already happens).
>
> I'm not sure you (Wolfgang and Kumar) are following my thought fully (or
> my ignorance is showing to everybody but me). The thought is to change
> the native format of the u-boot environment storage from the
> key-string/value-string pairs to the flat tree (OpenFirmware) format
> which still supports the same key-string/value-string capability (but
> can do more than that).
>
> The advantage, as I see it, is that it would be unifying and thus easier
> to maintain the common variables (call it the GRand Unifying Flat Tree
> (GRAFT) ;-). One language (flat tree), no shims, equivalent key/value
> utility (but a different underlying storage format), no visible
> difference for the users (but potentially an upgrade challenge for
> existing boards and env variables).
>
> The disadvantage is that it would be disruptive to u-boot and may cause
> some bloating and discomfort.
>
> gvb
> (the naive)
>
> P.S. For the non-USA readers: "may cause some bloating and discomfort"
> is a standard disclaimer on medicines advertised on TV over here.
>
Since I'm the guy responsible let me weigh in a bit.
For starters, yes it's possible to pass the whole env using the FT tree.
Use CONFIG_OF_HAS_UBOOT_ENV to pass the u-boot env to the FT tree.
As for the rest of the cat-fight, I'm afraid I don't have the energy
to jump in at the moment.
Perhaps tomorrow :)
Regards
Pantelis
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox