On Wed, 2008-10-22 at 08:50 +0200, Jean Delvare wrote:
> On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-10-17 at 11:21 +0200, Jean Delvare wrote:
> > > Hi Anton,
> > >
> > > On Thu, 16 Oct 2008 21:12:53 +0400, Anton Vorontsov wrote:
> > > > If present the info->
Hello Everyone,
I'm looking for some information about the Extended Addressing Mode
(XAEN bit of HID0 register) of PPC32 support in Linux.
I do not see anything in the main kernel tree but there may be some
patches available ?
Any information will be appreciate.
Regards.
--
Régis ODEYE
Kontro
Hi Mark,
On Thu, 16 Oct 2008 13:04:16 +0100 Mark Brown <[EMAIL PROTECTED]> wrote:
>
> On Thu, Oct 16, 2008 at 08:47:54PM +1100, Stephen Rothwell wrote:
> > Today's linux-next build (powerpc allyesconfig) failed like this:
>
> > drivers/mfd/wm8350-core.c:1131: error: __ksymtab_wm8350_create_cache
Hi Mark,
On Wed, 22 Oct 2008 10:37:22 +0100 Mark Brown <[EMAIL PROTECTED]> wrote:
>
> On Wed, Oct 22, 2008 at 08:31:12PM +1100, Stephen Rothwell wrote:
>
> > I thought that this had been applied, but I have had to apply it to my
> > tree today again.
>
> Samuel doesn't seem to have picked it up
On Wed, Oct 22, 2008 at 06:37:55PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2008-10-22 at 08:50 +0200, Jean Delvare wrote:
> > On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2008-10-17 at 11:21 +0200, Jean Delvare wrote:
> > > > Hi Anton,
> > > >
> > > > On T
On Tue, Oct 21, 2008 at 09:22:48PM -0700, David Brownell wrote:
> On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote:
> > The notifier can be registered before the devices, though it's a little
> > bit fishy and fragile.
> >
> > Easier I suppose to just have OF specific hooks in the bus code
On Wed, Oct 22, 2008 at 02:36:41PM +0400, Anton Vorontsov wrote:
> On Tue, Oct 21, 2008 at 09:22:48PM -0700, David Brownell wrote:
> > On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote:
> > > The notifier can be registered before the devices, though it's a little
> > > bit fishy and fragile.
On Wed, 22 Oct 2008 14:08:13 +0400, Anton Vorontsov wrote:
> On Wed, Oct 22, 2008 at 06:37:55PM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2008-10-22 at 08:50 +0200, Jean Delvare wrote:
> > > On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote:
> > > > On Fri, 2008-10-17 at 11:21
On Wed, Oct 22, 2008 at 08:31:12PM +1100, Stephen Rothwell wrote:
> I thought that this had been applied, but I have had to apply it to my
> tree today again.
Samuel doesn't seem to have picked it up (though looking at the CC list
you've not sent it to him). I'm going to push another batch of st
On Oct 22, 2008, at 3:59 AM, Régis Odeyé wrote:
Hello Everyone,
I'm looking for some information about the Extended Addressing Mode
(XAEN bit of HID0 register) of PPC32 support in Linux.
I do not see anything in the main kernel tree but there may be some
patches available ?
Any information
On Wed, Oct 22, 2008 at 01:07:48PM +0200, Jean Delvare wrote:
> On Wed, 22 Oct 2008 14:08:13 +0400, Anton Vorontsov wrote:
> > On Wed, Oct 22, 2008 at 06:37:55PM +1100, Benjamin Herrenschmidt wrote:
> > > On Wed, 2008-10-22 at 08:50 +0200, Jean Delvare wrote:
> > > > On Wed, 22 Oct 2008 11:27:34 +1
Kumar Gala wrote:
On Oct 22, 2008, at 3:59 AM, Régis Odeyé wrote:
Hello Everyone,
I'm looking for some information about the Extended Addressing Mode
(XAEN bit of HID0 register) of PPC32 support in Linux.
I do not see anything in the main kernel tree but there may be some
patches available ?
On Oct 22, 2008, at 7:59 AM, Régis Odeyé wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 3:59 AM, Régis Odeyé wrote:
Hello Everyone,
I'm looking for some information about the Extended Addressing
Mode (XAEN bit of HID0 register) of PPC32 support in Linux.
I do not see anything in the main ke
I'm extremely troubled that it is "not used in the code",
surely device_type is checked as a legacy for Open Firmware
(otherwise a lot of devices may never be detected!), or does
device tree parsing/checking follow a different path for FDT?
(absolutely fine with it being removed from new DTS b
Kumar Gala wrote:
So we have XAEN support in the tree.. however non-contiguous is
something you'll have to work on yourself. Patches are welcome for this
OK. I will let you know about this.
Where can I glance through Becky patches ?
This is the bulk:
http://git.kernel.org/?p=linux/kernel/gi
Kumar Gala wrote:
On Oct 22, 2008, at 7:59 AM, Régis Odeyé wrote:
of ram. So I need 4GB+IOs (~1GB) of physical addressing space.
My plan is to put a part of this ram above of 4GB to keep accesses to
the IOs below the 4GB limit. It means non-contiguous ram addressing
and XAEN features to be
On Wed, Oct 22, 2008 at 08:38:03AM -0500, Matt Sealey wrote:
> I'm extremely troubled that it is "not used in the code", surely
> device_type is checked as a legacy for Open Firmware (otherwise a lot of
> devices may never be detected!),
Checked where? Can you point out a code snippet? (Except f
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 7:59 AM, Régis Odeyé wrote:
of ram. So I need 4GB+IOs (~1GB) of physical addressing space.
My plan is to put a part of this ram above of 4GB to keep accesses
to the IOs below the 4GB limit. It means non-
Matt Sealey wrote:
I'd also be interested in any work done to enable non-contiguous
memory areas. Reading the docs for the MPC8641D though I am not sure
you can set up LAWs for it?
One thing I wanted to try was installing 4GB in a system and
"overlapping" IO (since there is very little of i
Kumar Gala wrote:
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
So to confirm, XAEN support through Becky's patches does support the
MPC8641D/e600 cores?
Yes, its the only part that has XAEN.
Okay I saw a lot of e500/BookE support go past but nothing
specific :)
NOT supported because
Kumar Gala wrote:
Your bigger issue is if you can setup the DDR controller for the hole
you want.
I just remembered;;
~~
The CCSR window always takes precedence over all local access
windows. However, the CCSR window must not overlap an LAW that
maps to the DDR controller. Otherwise, un
Hi Ilya,
I just tried your patch on my 440 board because it would help us in our
environment.
Unfortunately I run into a bug on early boot (mark_bootmem).
A log can be found in this mail, this is the bug when running with 64k
page size.
I tried this with and without your 2/2 265k patch and als
The 'ibm,interrupt-server#-size' properties are not cpu nodes properties,
but rather live under the interrupt source controller nodes (compatible
ibm,ppc-xics).
Therefore, this patch moves the detection of this property outside of
xics_update_irq_servers() and into xics_init_IRQ().
Also th
On Oct 22, 2008, at 9:19 AM, Matt Sealey wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
So to confirm, XAEN support through Becky's patches does support
the MPC8641D/e600 cores?
Yes, its the only part that has XAEN.
Okay I saw a lot of e500/BookE support go pas
On Oct 22, 2008, at 9:22 AM, Matt Sealey wrote:
Kumar Gala wrote:
Your bigger issue is if you can setup the DDR controller for the
hole you want.
I just remembered;;
~~
The CCSR window always takes precedence over all local access
windows. However, the CCSR window must not overlap an L
On Tue, Oct 21, 2008 at 10:58 PM, Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Stephen Rothwell writes:
>
> > On Tue, 21 Oct 2008 16:33:10 +1100 Paul Mackerras <[EMAIL PROTECTED]>
> wrote:
> > >
> > > It's a bug in older versions of ld (including 2.16.1) that's fixed in
> > > the current version (2
A new field has been added to the VPA as a method for
the client OS to communicate to firmware the number of
page ins it is performing when running collaborative
memory overcommit. The hypervisor will use this information
to better determine if a partition is experiencing memory
pressure and needs
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Speed up generic mutex implementations.
>
> - atomic operations which both modify the variable and return something imply
> full smp memory barriers before and after the memory operations involved
> (failing atomic_cmpxchg, atomic_add_unless, etc do
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Speed up generic mutex implementations.
>
> - atomic operations which both modify the variable and return something imply
> full smp memory barriers before and after the memory operations involved
> (failing atomic_cmpxchg, atomic_add_unless, etc don't
I just tried booting a post 2.6.27 -git on a Motorola ATCA6101 (very similar
to a Maple board). The first time I booted I got the first log below. I
rebooted and got as far as a login prompt. I was able to log in via the
serial console, but then got an almost identical oops again, as shown
Paul Mackerras wrote:
Chris, could you try just the following change (my previous patch
without the arch/powerpc/boot/wrapper change) and let me know if it
fixes things with the ld you use?
The build completes with no errors. Haven't actually booted it though.
Gets my vote...
Chris
Ilya, here the snippet you asked for with CONFIG_DEBUG_BUGVERBOSE
enabled and bootmem_debug set.
## Booting kernel from Legacy Image at 0400 ...
Image Name: Linux-2.6.27-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:1521505 Bytes = 1.5 MB
Load Addr
Kumar Gala wrote:
On Oct 22, 2008, at 9:19 AM, Matt Sealey wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
So to confirm, XAEN support through Becky's patches does support the
MPC8641D/e600 cores?
Yes, its the only part that has XAEN.
Okay I saw a lot of e500/
Hollis Blanchard wrote:
binutils 2.16.1 is the most recent binutils that will build with
crosstool, so IMHO it's worth supporting. :)
I was wondering about thatwasted a bunch of time trying to build something
more recent.
Chris
___
Linuxppc-de
Kumar Gala wrote:
On Oct 22, 2008, at 9:22 AM, Matt Sealey wrote:
~~
The CCSR window always takes precedence over all local access windows.
However, the CCSR window must not overlap an LAW that maps to the DDR
controller. Otherwise, undefined behavior occurs.
~~
So, it's not really possi
On Wed, Oct 22, 2008 at 02:46:06PM +0400, Anton Vorontsov wrote:
> On Wed, Oct 22, 2008 at 02:36:41PM +0400, Anton Vorontsov wrote:
> > On Tue, Oct 21, 2008 at 09:22:48PM -0700, David Brownell wrote:
> > > On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote:
> > > > The notifier can be registe
Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 08:38:03AM -0500, Matt Sealey wrote:
I'm extremely troubled that it is "not used in the code", surely
device_type is checked as a legacy for Open Firmware (otherwise a lot of
devices may never be detected!),
Checked where?
of_find_device_by_
On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote:
>
>
> Anton Vorontsov wrote:
>> On Wed, Oct 22, 2008 at 08:38:03AM -0500, Matt Sealey wrote:
>>> I'm extremely troubled that it is "not used in the code", surely
>>> device_type is checked as a legacy for Open Firmware (otherwise a lot
Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote:
I think I got it. ;-) You think that I'm not aware of that we _can_
use the device_type for matching the nodes. Well, I'm aware of it,
sure we can. ;-)
I'm sure you are aware, I am just a little jumpy regardi
On Wed, Oct 22, 2008 at 02:09:01PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote:
>>
>> I think I got it. ;-) You think that I'm not aware of that we _can_
>> use the device_type for matching the nodes. Well, I'm aware of it,
>> su
On Oct 22, 2008, at 1:11 PM, Matt Sealey wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 9:19 AM, Matt Sealey wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
So to confirm, XAEN support through Becky's patches does support
the MPC8641D/e600 cores?
Yes, its the on
On Oct 22, 2008, at 9:36 AM, Sebastien Dugue wrote:
The 'ibm,interrupt-server#-size' properties are not cpu nodes
properties,
but rather live under the interrupt source controller nodes (compatible
ibm,ppc-xics).
Therefore, this patch moves the detection of this property outside of
xics
Matt Sealey wrote:
> Anton Vorontsov wrote:
>> We don't want to encourage the device_type usage. It isn't used in the
>> code, so we can simply remove it from the dts files.
>
> I'm extremely troubled that it is "not used in the code",
> surely device_type is checked as a legacy for Open Firmwar
as of 4792adbac9eb41cea77a45ab76258ea10d411173
CONFIG_SPU_FS=n
CONFIG_PPC_CELL=y
CONFIG_PPC_CELL_NATIVE=y
CONFIG_PPC_IBM_CELL_BLADE=y
CONFIG_CBE_RAS=y
CONFIG_PPC_IBM_CELL_RESETBUTTON=y
CONFIG_CBE_THERM=y
rest mostly pseries_defconfig.
MODPOST vmlinux.o
WARNING: modpost: Found 8 section mismat
The updates kexec-tools to match the kernel after the patches
"kexec exit should not use magic numbers" and
"better flag for running relocatable" are applied.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Still proposed change
Index: kexec-tools/purgatory/arch/ppc64/v2wrap.S
Every time add_segment is called, the segments are sorted. If the first
hole in memory is not big enough for the kernel then something besides
the kernel may be at
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Found during custom environment testing with several reserved blocks of
memory,
The __kdump_flag ABI is overly constraining for future development.
As of 2.6.27, the kernel entry point has 4 constraints: Offset 0 is
the starting point for the master (boot) cpu (entered with r3 pointing
to the device tree structure), offset 0x60 is code for the slave cpus
(entered with r3 s
The relocatable kernel kdump patch (54622f10a6aabb8bb2bdacf3dd070046f03dc246)
added a magic flag value in a register to tell purgatory that it should
be a panic kernel. This part is wrong and is reverted by this patch.
The kernel gets a list of memory blocks and a entry point from user space.
Its
On Oct 22, 2008, at 3:39 PM, Milton Miller wrote:
Every time add_segment is called, the segments are sorted. If the
first
hole in memory is not big enough for the kernel then something besides
the kernel may be at
info->segment[0].
---
Found during custom environment testing with several
On Wednesday 22 October 2008, Anton Vorontsov wrote:
>
> > > The board info has another problem though. We can't remove it, thus
> > > we can't implement module_exit() for the 'OF glue'.
That's not a problem. Why would you want to remove it?
> > And try to solve this problem... maybe then thin
On Wed, Oct 22, 2008 at 02:04:52PM -0700, David Brownell wrote:
> On Wednesday 22 October 2008, Anton Vorontsov wrote:
> >
> > > > The board info has another problem though. We can't remove it, thus
> > > > we can't implement module_exit() for the 'OF glue'.
>
> That's not a problem. Why would y
On Wednesday 22 October 2008, Anton Vorontsov wrote:
> >
> > > So if we register the board infos after
> > > the controller registered, then nobody will probe the board infos.
> >
> > See above. If you're doing it right, there's no problem.
> > That is, scan the OF tables early. Just like PNP
On Wed, 2008-10-22 at 08:08 -0500, Kumar Gala wrote:
> > We are developing a board based on Freescale 8641D which can get
> 4GB
> > of ram. So I need 4GB+IOs (~1GB) of physical addressing space.
> > My plan is to put a part of this ram above of 4GB to keep accesses
> > to the IOs below the 4GB
Becky Bruce wrote:
On Oct 22, 2008, at 1:11 PM, Matt Sealey wrote:
Yeah so I saw BookE and e500 stuff go past but nothing specific for
e600/XAEN. I mailed Becky and got no response. I'm glad to know it's
in there though, somewhere.
Huh? I have one mail from you, on Sep 1, to which I resp
Benjamin Herrenschmidt wrote:
On Wed, 2008-10-22 at 08:08 -0500, Kumar Gala wrote:
We are developing a board based on Freescale 8641D which can get
4GB
of ram. So I need 4GB+IOs (~1GB) of physical addressing space.
My plan is to put a part of this ram above of 4GB to keep accesses
to the
On Wed, Oct 22, 2008 at 02:52:46PM -0700, David Brownell wrote:
> On Wednesday 22 October 2008, Anton Vorontsov wrote:
> > >
> > > > So if we register the board infos after
> > > > the controller registered, then nobody will probe the board infos.
> > >
> > > See above. If you're doing it right
On Wed, 2008-10-22 at 17:21 -0500, Matt Sealey wrote:
>
> Because we're Genesi! And we have a firmware solution that
> kind of has to keep 32-bit pointers in the unlikely event that
> someone actually uses the client interface (besides yaboot!).
>
> Having I/O in the 36-bit range could cause al
(Oops, resending in plain text...)
On Tue, Oct 21, 2008 at 10:58 PM, Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> Stephen Rothwell writes:
>
> > On Tue, 21 Oct 2008 16:33:10 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote:
> > >
> > > It's a bug in older versions of ld (including 2.16.1) that's fi
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied with a slightly expanded changelog.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[ Added Mohan Kumar to CC list ]
On Wed, Oct 22, 2008 at 03:39:18PM -0500, Milton Miller wrote:
> The relocatable kernel kdump patch (54622f10a6aabb8bb2bdacf3dd070046f03dc246)
> added a magic flag value in a register to tell purgatory that it should
> be a panic kernel. This part is wrong and is
Hi all,
Things are getting better. Here are the messages from a ppc64_defconfig
build this morning (Linus' tree plus a merge of DaveM's pending network
tree):
kernel/trace/ring_buffer.c: In function 'rb_add_time_stamp':
kernel/trace/ring_buffer.c:969: warning: format '%llu' expects type 'long lo
On Wed, Oct 22, 2008 at 11:50:25AM -0600, Chris Friesen wrote:
> Hollis Blanchard wrote:
>
>> binutils 2.16.1 is the most recent binutils that will build with
>> crosstool, so IMHO it's worth supporting. :)
>
> I was wondering about thatwasted a bunch of time trying to build
> something more
On Tue, Oct 21, 2008 at 03:50:30PM -0700, Satya wrote:
> On Tue, Oct 21, 2008 at 3:46 PM, Satya <[EMAIL PROTECTED]> wrote:
>
> > Ben,
> > Look here: http://www-unix.mcs.anl.gov/zeptoos/hugepages/
> >
> > thanks,
> > ./satya
> >
> >
> > On Tue, Oct 21, 2008 at 1:47 PM, Benjamin Herrenschmidt <
> >
In message <[EMAIL PROTECTED]> you wrote:
> The __kdump_flag ABI is overly constraining for future development.
>
> As of 2.6.27, the kernel entry point has 4 constraints: Offset 0 is
> the starting point for the master (boot) cpu (entered with r3 pointing
> to the device tree structure), offse
Milton Miller writes:
> Move the flag to 0x5c, 1 word before the secondary cpu entry point at
> 0x60. Use the copy at address 0 not the one in the base kernel image to
> make it easier on kexec-tools.
Why is it easier on kexec-tools? Doesn't kexec-tools know where it
put the kernel?
I'd much r
Print physical start address for the relocatable kernel.
Also fixes this warning:
arch/powerpc/kernel/setup_64.c:447:5: warning: "kernstart_addr" is not defined
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/setup_64.c |6 +++---
1 file changed, 3 insertions(+)
Paul Mackerras writes:
> Milton Miller writes:
>
> > Move the flag to 0x5c, 1 word before the secondary cpu entry point at
> > 0x60. Use the copy at address 0 not the one in the base kernel image to
> > make it easier on kexec-tools.
>
> Why is it easier on kexec-tools? Doesn't kexec-tools know
Commit 549e8152de8039506f69c677a4546e5427aa6ae7 ("powerpc: Make the
64-bit kernel as a position-independent executable") added lines to
vmlinux.lds.S to add the extra sections needed to implement a
relocatable kernel. However, those lines seem to trigger a bug in
older versions of GNU ld (such as
On Wed, 2008-10-22 at 17:59 +0200, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Speed up generic mutex implementations.
> >
> > - atomic operations which both modify the variable and return something
> > imply
> > full smp memory barriers before and after the memory oper
On Wed, 2008-10-22 at 14:04 -0700, David Brownell wrote:
> > So if we register the board infos after
> > the controller registered, then nobody will probe the board infos.
>
> See above. If you're doing it right, there's no problem.
> That is, scan the OF tables early. Just like PNP tables
> ge
Hi Rusty,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
arch/powerpc/platforms/cell/spu_base.c: In function 'mm_needs_global_tlbie':
arch/powerpc/platforms/cell/spu_base.c:117: error: implicit declaration of
function '__cpus_setall'
Caused by commit 20ec1a8465bd6d2e7e68fa
On Wednesday 22 October 2008, Anton Vorontsov wrote:
> >
> > So have it live in the __init text section...
>
> Won't work, unfortunately. I2C devices are created by the
> i2c controllers, via drivers/of_i2c.c of_register_i2c_devices().
And I'm pointing out a way to have the normal I2C core code
Print physical start address for the relocatable kernel.
Also fixes this warning:
arch/powerpc/kernel/setup_64.c:447:5: warning: "kernstart_addr" is not defin
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/setup_64.c |6 +++---
1 file changed, 3 insertions(+),
On Wednesday 22 October 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-10-22 at 14:04 -0700, David Brownell wrote:
> > > So if we register the board infos after
> > > the controller registered, then nobody will probe the board infos.
> >
> > See above. If you're doing it right, there's no pr
On Wednesday 22 October 2008, Anton Vorontsov wrote:
> --- a/drivers/gpio/pcf857x.c
> +++ b/drivers/gpio/pcf857x.c
> @@ -187,7 +187,7 @@ static int pcf857x_probe(struct i2c_client *client,
> struct pcf857x *gpio;
> int status;
>
> -
Hi Alan,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
drivers/char/hvc_console.c: In function 'hvc_set_winsz':
drivers/char/hvc_console.c:532: warning: passing argument 2 of 'tty_do_resize'
from incompatible pointer type
drivers/char/hvc_console.c:532: error: too many arg
77 matches
Mail list logo
