* Re: [U-Boot-Users] Re: FT u-boot shim
From: Tolunay Orkun @ 2006-04-27 21:55 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <20060427194055.3EED1353A57@atlas.denx.de>
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?
>
>> 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>
How would you like to handle the case when dts is packed into
multi-image file? Is bootm going to assume that the 3rd Image is dts?
Since dts is tightly coupled to kernel I would prefer something like:
bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
Best regards,
Tolunay
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Mark A. Greer @ 2006-04-27 22:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1146174809.30710.14.camel@localhost.localdomain>
On Fri, Apr 28, 2006 at 07:53:29AM +1000, Benjamin Herrenschmidt wrote:
>
> > There are many mv64x60 based platforms working just fine today with
> > CONFIG_NOT_COHERENT_CACHE defined. The reason for turning coherency off
> > is that there is a bug in the bridge requiring a hardware workaround.
> > Unfortunately, not all of the hardware vendors have implemented that
> > workaround and I know of one that considers it infeasible and will
> > not implement it.
>
> Define "working fine" ... With the current implementation, and according
> to the spec, it will randomly crap out or checkstop due to the same page
> beging accessed via the NCU and being in the L2 unless you disabled
> speculative loads and made sure it can't prefetch accross page
> boundaries maybe ? Or set the G bit all over the BAT mapping (ouch !).
"working fine" == running in a production environment for
weeks/months without crapping out.
> > If that hardware workaround is not implemented, the options are:
> > a) 100% chance of a system hang with coherency on
> > or
> > b) < 0.0..1% chance of a system hang with coherency off (at least in my
> > experience to far).
> >
> > The choice is simple.
>
> I disagree. A solution that is known to have a hole in it is no good
> even if you haven't managed to trigger it so far. Now it's Gerhard's
> choice.
TBH, I haven't really looked at what Gerhard is doing yet so I can't
comment. No matter what, though, its certainly his choice.
Mark
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-27 21:53 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <20060427213134.GA12572@mag.az.mvista.com>
> There are many mv64x60 based platforms working just fine today with
> CONFIG_NOT_COHERENT_CACHE defined. The reason for turning coherency off
> is that there is a bug in the bridge requiring a hardware workaround.
> Unfortunately, not all of the hardware vendors have implemented that
> workaround and I know of one that considers it infeasible and will
> not implement it.
Define "working fine" ... With the current implementation, and according
to the spec, it will randomly crap out or checkstop due to the same page
beging accessed via the NCU and being in the L2 unless you disabled
speculative loads and made sure it can't prefetch accross page
boundaries maybe ? Or set the G bit all over the BAT mapping (ouch !).
> I expect that the pegasos has that hardware workaround implemented so
> the kernel maintainers for that platform have the good fortune of being
> able to run with coherency on.
I suppose so...
> What Ben says is correct, there is that issue. However, AFAIK, I have
> not yet to run into it.
Hrm... well, I wouldn't rely on that tho.
> If that hardware workaround is not implemented, the options are:
> a) 100% chance of a system hang with coherency on
> or
> b) < 0.0..1% chance of a system hang with coherency off (at least in my
> experience to far).
>
> The choice is simple.
I disagree. A solution that is known to have a hole in it is no good
even if you haven't managed to trigger it so far. Now it's Gerhard's
choice.
Ben.
^ permalink raw reply
* Re: [PATCH 06/16] ehca: common include files
From: Heiko J Schick @ 2006-04-27 21:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel, openib-general
In-Reply-To: <200604271319.06844.arnd.bergmann@de.ibm.com>
On 2006-04-27 13:19:06 +0200, Arnd Bergmann <arnd.bergmann@de.ibm.com> said:
> Well, you should also remove this for submission, I guess ;-)
Yeah, I've planed to remove this lines when 2.6.17 official came out.
It is still included because we don't want to introduce unnecessary
dependencies.
I will remove it for the next patchset.
Regards,
Heiko
^ permalink raw reply
* Re: [PATCH 01/16] ehca: integration in Linux kernel build system
From: Heiko J Schick @ 2006-04-27 21:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel, openib-general
In-Reply-To: <200604271307.36987.arnd.bergmann@de.ibm.com>
On 2006-04-27 13:07:36 +0200, Arnd Bergmann <arnd.bergmann@de.ibm.com> said:
> It would be more practical to put this patch last instead of
> first so you don't break the build system with partial applies.
I agree. I Will change set for the next patchset.
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-27 21:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <7BC50BA2-D657-4907-94AA-DB5926F22504@kernel.crashing.org>
In message <7BC50BA2-D657-4907-94AA-DB5926F22504@kernel.crashing.org> you wrote:
>
> > 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?
Yes. We could write "bootm <kernel_addr> NULL <dts_addr>" or "bootm
<kernel_addr> none <dts_addr>" or anythingl ike that as well, but I'm
a lazy typist :-)
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
"...this does not mean that some of us should not want, in a rather
dispassionate sort of way, to put a bullet through csh's head."
- Larry Wall in <1992Aug6.221512.5963@netlabs.com>
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-27 21:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, U-Boot Users
In-Reply-To: <9F5CC364-8FC8-48BA-8D12-E524815B6537@kernel.crashing.org>
In message <9F5CC364-8FC8-48BA-8D12-E524815B6537@kernel.crashing.org> you wrote:
>
> 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
I guess there are VxWorks BSP's for most of the boards we are talking
about, right? Do they use the device tree? I would be *very*
surprised.
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
Microsoft Multimedia:
You have nice graphics, sound and animations when the system crashes.
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Mark A. Greer @ 2006-04-27 21:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1145594285.28014.12.camel@localhost.localdomain>
On Fri, Apr 21, 2006 at 02:38:05PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2006-04-20 at 14:55 -0700, Eugene Surovegin wrote:
> > On Thu, Apr 20, 2006 at 11:10:55PM +0200, Gerhard Pircher wrote:
> > > Well, Freescale's PPC programming environment manual clearly states that
> > > this will not work on G4 CPUs (74xx). Also Benjamin Herrenschmidt told me,
> > > that this implementation will not work for the reasons I mentioned before.
> > > The approach I'm trying to implement was his idea, so I have to trust in
> > > him.
> >
> > Well, you aren't the first person who tries to run G4 with
> > CONFIG_NOT_COHERENT_CACHE. This was done before and I don't remember
> > that those people had to implement anything as complex as you are
> > trying to do.
> >
> > You can try asking on #mklinux. It always better to ask people who
> > actually _did_ this :).
> >
> > In fact, I just grepped 2.6 and found
> > #ifdef(CONFIG_NOT_COHERENT_CACHE) in syslib/mv64x60.c. Guess what
> > systems usually have this type of bridge? Not 4xx/8xx, that's for sure.
>
> I think some folks tried ... and failed.
Who has tried and failed?
There are many mv64x60 based platforms working just fine today with
CONFIG_NOT_COHERENT_CACHE defined. The reason for turning coherency off
is that there is a bug in the bridge requiring a hardware workaround.
Unfortunately, not all of the hardware vendors have implemented that
workaround and I know of one that considers it infeasible and will
not implement it.
I expect that the pegasos has that hardware workaround implemented so
the kernel maintainers for that platform have the good fortune of being
able to run with coherency on.
What Ben says is correct, there is that issue. However, AFAIK, I have
not yet to run into it.
If that hardware workaround is not implemented, the options are:
a) 100% chance of a system hang with coherency on
or
b) < 0.0..1% chance of a system hang with coherency off (at least in my
experience to far).
The choice is simple.
Mark
^ 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
* 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: [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
* 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: 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: 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: 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: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: 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: [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: [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: 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: 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: 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: 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: 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: 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
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