* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Simon Glass @ 2011-10-31 20:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110311644.02847.vapier@gentoo.org>
Hi Mike,
On Mon, Oct 31, 2011 at 1:44 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 31 October 2011 15:11:35 Simon Glass wrote:
>> On Sun, Oct 30, 2011 at 5:54 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> > If we move the local funcs to the top of the file, and use the
>> > __maybe_unused define, we can drop a lot of ugly ifdef logic and
>> > duplicated prototypes.
>> >
>> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
>>
>> This is much cleaner - is the correct style to put attribute tags on
>> the previous line?
>
> when responding to add your own, there isn't any real protocol. ?just normal
> e-mail etiquette (no top posting/etc...). ?patchwork/humans will do the right
> thing when manually updating the changelog.
> -mike
>
Actually I meant the __maybe_unused tag before the function name.
Regards,
Simon
^ permalink raw reply
* [U-Boot] [PATCH 3/4] EHCI: adjust for mx5
From: Jana Rapava @ 2011-10-31 20:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE5830.8050700@compulab.co.il>
2011/10/31 Igor Grinberg <grinberg@compulab.co.il>
> > +struct mxc_ulpi_regs {
> > + u8 vendor_id_low; /* 0x00 - Vendor ID lower byte */
> > + u8 vendor_id_high; /* 0x01 - Vendor ID upper byte */
> > + u8 product_id_low; /* 0x02 - Product ID lower byte */
> > + u8 product_id_high; /* 0x03 - Product ID higher byte */
> > + /* Function Control; 0x04 - 0x06 Read, 0x04 Write */
> > + u8 function_ctrl_write;
> > + u8 function_ctrl_set; /* 0x05 Set */
> > + u8 function_ctrl_clear; /* 0x06 Clear */
> > + /* Interface Control; 0x07 - 0x09 Read, 0x07 Write */
> > + u8 iface_ctrl_write;
> > + u8 iface_ctrl_set; /* 0x08 Set */
> > + u8 iface_ctrl_clear; /* 0x09 Clear */
> > + /* OTG Control; 0x0A - 0x0C Read, 0x0A Write */
> > + u8 otg_ctrl_write;
> > + u8 otg_ctrl_set; /* 0x0B Set */
> > + u8 otg_ctrl_clear; /* 0x0C Clear */
> > + /* USB Interrupt Enable Rising; 0x0D - 0x0F Read, 0x0D Write */
> > + u8 usb_ie_rising_write;
> > + u8 usb_ie_rising_set; /* 0x0E Set */
> > + u8 usb_ie_rising_clear; /* 0x0F Clear */
> > + /* USB Interrupt Enable Falling; 0x10 - 0x12 Read, 0x10 Write */
> > + u8 usb_ie_falling_write;
> > + u8 usb_ie_falling_set; /* 0x11 Set */
> > + u8 usb_ie_falling_clear; /* 0x12 Clear */
> > + u8 usb_int_status; /* 0x13 - USB Interrupt Status */
> > + u8 usb_int_latch; /* 0x14 - USB Interrupt Latch */
> > + u8 debug; /* 0x15 - Debug */
> > + /* Scratch Register; 0x16 - 0x18 Read, 0x16 Write */
> > + u8 scratch_write;
> > + u8 scratch_set; /* 0x17 Set */
> > + u8 scratch_clear; /* 0x18 Clear*/
> > +};
>
>
> These are the generic ULPI specification registers
> and not mxc specific.
> I'd expect to have them in a more generic location.
>
This would be fixed in general ULPI support patch I'm working on. It should
be ready for posting in a few days.
> --
>
Regards,
> Igor.
>
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Mike Frysinger @ 2011-10-31 20:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ1+waUNEtw=xh5UGJApxnL2ovVgVOAt0fTGaypUKVJ+WQ@mail.gmail.com>
On Monday 31 October 2011 15:11:35 Simon Glass wrote:
> On Sun, Oct 30, 2011 at 5:54 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > If we move the local funcs to the top of the file, and use the
> > __maybe_unused define, we can drop a lot of ugly ifdef logic and
> > duplicated prototypes.
> >
> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
>
> This is much cleaner - is the correct style to put attribute tags on
> the previous line?
when responding to add your own, there isn't any real protocol. just normal
e-mail etiquette (no top posting/etc...). patchwork/humans will do the right
thing when manually updating the changelog.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/5fb80343/attachment.pgp
^ permalink raw reply
* [U-Boot] [PATCH v2 5/8] nand: Merge new implementation of 1-bit ECC from Linux nand driver
From: Scott Wood @ 2011-10-31 20:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE9311.8040907@aizo.com>
On 10/31/2011 07:22 AM, Christian Hitz wrote:
> Am 29.10.2011 00:30, schrieb Scott Wood:
>> On 10/12/2011 02:32 AM, Christian Hitz wrote:
>>> [backport from linux commit 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe]
>>>
>>> This patch synchronizes the nand driver with the Linux 3.0 state.
>>>
>>> Signed-off-by: Christian Hitz <christian.hitz@aizo.com>
>>> Cc: Scott Wood <scottwood@freescale.com>
>>> ---
>>>
>>> Adds 1416 bytes to the image size.
>>
>> What does this version of the code do that warrants the code size
>> increase? This could break some SPLs.
>>
>> If it's just a speed issue, we probably want to stick with the current code.
>
> It's the rewrite for performance and support for 512 byte pages, but this is
> on the basis of the rewritten code.
Several SPLs make use of nand_ecc.c, so NACK replacing it with a larger
implementation.
We could have the new ECC implementation available as a build-time
alternative, though.
-Scott
^ permalink raw reply
* [U-Boot] Pull request for u-boot-marvell.git
From: Albert ARIBAUD @ 2011-10-31 19:35 UTC (permalink / raw)
To: u-boot
In-Reply-To: <F766E4F80769BD478052FB6533FA745D1A14DD88BA@SC-VEXCH4.marvell.com>
Hi Prafulla,
Le 31/10/2011 12:58, Prafulla Wadaskar a ?crit :
> Hi Albert
> Please pull
>
> The following changes since commit b3fee4e17f9f2c136b8fcfc1b7e575b6b3ccd66a:
> Anatolij Gustschin (1):
> ARM: dreamplug: fix compilation
>
> are available in the git repository at:
>
> u-boot-marvell.git ..BRANCH.NOT.VERIFIED..
Seems like you did the 'git request-pull' before updating
u-boot-marvell/master. :)
> Ajay Bhargav (1):
> gplugD: Fix for error:MACH_TYPE_SHEEVAD undeclared
>
> Holger Brunck (2):
> arm/km: add variable waitforne to mgcoge3un
> arm/km/mgcoge3un: enhance "waitforne" feature
>
> Michael Walle (1):
> kirkwood: define CONFIG_SYS_CACHELINE_SIZE
>
> Mike Frysinger (1):
> kirkwood: drop empty asm-offsets.s file
>
> arch/arm/include/asm/arch-kirkwood/config.h | 3 ++-
> board/keymile/km_arm/km_arm.c | 11 ++++++++++-
> include/configs/gplugd.h | 12 +++++++++++-
> include/configs/mgcoge3un.h | 2 ++
> 4 files changed, 25 insertions(+), 3 deletions(-)
> delete mode 100644 arch/arm/cpu/arm926ejs/kirkwood/asm-offsets.s
Applied to u-boot-arm/master, thanks!
> Regards...
> Prafulla . . .
Amicalement,
--
Albert.
^ permalink raw reply
* [U-Boot] [PATCH] Powerpc/DIU: Fixed the 800x600 and 1024x768 resolution bug
From: Anatolij Gustschin @ 2011-10-31 19:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320041994-28675-1-git-send-email-Chang-Ming.Huang@freescale.com>
On Mon, 31 Oct 2011 14:19:54 +0800
<Chang-Ming.Huang@freescale.com> wrote:
> From: Jerry Huang <Chang-Ming.Huang@freescale.com>
>
> When the resolution is set to 800x600 and 1024x768,
> but, the driver will use 1280x1024 resolution to set the DIU register
>
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> ---
> drivers/video/fsl_diu_fb.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
Applied to u-boot-video/master, thanks!
Anatolij
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Simon Glass @ 2011-10-31 19:11 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320022463-26410-1-git-send-email-vapier@gentoo.org>
On Sun, Oct 30, 2011 at 5:54 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> If we move the local funcs to the top of the file, and use the
> __maybe_unused define, we can drop a lot of ugly ifdef logic and
> duplicated prototypes.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This is much cleaner - is the correct style to put attribute tags on
the previous line?
Acked-by: Simon Glass <sjg@chromium.org>
> ---
> ?common/cmd_bdinfo.c | ? 89 ++++++++++++++++++--------------------------------
> ?1 files changed, 32 insertions(+), 57 deletions(-)
>
^ permalink raw reply
* [U-Boot] [PATCH] ARM: define CONFIG_MACH_TYPE for all ronetix boards
From: Asen Chavdarov Dimov @ 2011-10-31 18:54 UTC (permalink / raw)
To: u-boot
Signed-off-by: Asen Chavdarov Dimov <dimov@ronetix.at>
---
board/ronetix/pm9261/pm9261.c | 3 ---
board/ronetix/pm9263/pm9263.c | 3 ---
board/ronetix/pm9g45/pm9g45.c | 2 --
include/configs/pm9261.h | 3 +++
include/configs/pm9263.h | 3 +++
include/configs/pm9g45.h | 3 +++
6 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/board/ronetix/pm9261/pm9261.c b/board/ronetix/pm9261/pm9261.c
index 871b94a..b26e33a 100644
--- a/board/ronetix/pm9261/pm9261.c
+++ b/board/ronetix/pm9261/pm9261.c
@@ -248,9 +248,6 @@ int board_init(void)
1 << ATMEL_ID_PIOC,
&pmc->pcer);
- /* arch number of PM9261-Board */
- gd->bd->bi_arch_number = MACH_TYPE_PM9261;
-
/* adress of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
diff --git a/board/ronetix/pm9263/pm9263.c b/board/ronetix/pm9263/pm9263.c
index cfc9847..b0f7ea6 100644
--- a/board/ronetix/pm9263/pm9263.c
+++ b/board/ronetix/pm9263/pm9263.c
@@ -349,9 +349,6 @@ int board_init(void)
(1 << ATMEL_ID_PIOB),
&pmc->pcer);
- /* arch number of AT91SAM9263EK-Board */
- gd->bd->bi_arch_number = MACH_TYPE_PM9263;
-
/* adress of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
diff --git a/board/ronetix/pm9g45/pm9g45.c b/board/ronetix/pm9g45/pm9g45.c
index f3374a4..961d193 100644
--- a/board/ronetix/pm9g45/pm9g45.c
+++ b/board/ronetix/pm9g45/pm9g45.c
@@ -139,8 +139,6 @@ int board_init(void)
(1 << ATMEL_ID_PIOC) |
(1 << ATMEL_ID_PIODE), &pmc->pcer);
- /* arch number of AT91SAM9M10G45EK-Board */
- gd->bd->bi_arch_number = MACH_TYPE_PM9G45;
/* adress of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
diff --git a/include/configs/pm9261.h b/include/configs/pm9261.h
index 89e17b8..55455e7 100644
--- a/include/configs/pm9261.h
+++ b/include/configs/pm9261.h
@@ -52,6 +52,9 @@
#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */
#define CONFIG_SYS_TEXT_BASE 0
+#define MACH_TYPE_PM9261 1187
+#define CONFIG_MACH_TYPE MACH_TYPE_PM9261
+
/* clocks */
/* CKGR_MOR - enable main osc. */
#define CONFIG_SYS_MOR_VAL \
diff --git a/include/configs/pm9263.h b/include/configs/pm9263.h
index 1f7543c..43104a3 100644
--- a/include/configs/pm9263.h
+++ b/include/configs/pm9263.h
@@ -52,6 +52,9 @@
#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */
#define CONFIG_SYS_TEXT_BASE 0
+#define MACH_TYPE_PM9263 1475
+#define CONFIG_MACH_TYPE MACH_TYPE_PM9263
+
/* clocks */
#define CONFIG_SYS_MOR_VAL \
(AT91_PMC_MOR_MOSCEN | \
diff --git a/include/configs/pm9g45.h b/include/configs/pm9g45.h
index acc1204..d3beaf3 100644
--- a/include/configs/pm9g45.h
+++ b/include/configs/pm9g45.h
@@ -41,6 +41,9 @@
#define CONFIG_PM9G45 1 /* It's an Ronetix PM9G45 */
#define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9G45"
+#define MACH_TYPE_PM9G45 2672
+#define CONFIG_MACH_TYPE MACH_TYPE_PM9G45
+
/* ARM asynchronous clock */
#define CONFIG_SYS_AT91_MAIN_CLOCK 12000000 /* from 12 MHz crystal */
#define CONFIG_SYS_AT91_SLOW_CLOCK 32768 /* slow clock xtal */
--
1.7.4.4
^ permalink raw reply related
* [U-Boot] [PATCH V3] Arm: re-introduce the MACH_TYPE_XXXXXX for EB_CPUX9K2 board
From: Jens Scharsig @ 2011-10-31 18:52 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320045966-25187-1-git-send-email-js_at_ng@scharsoft.de>
* re-introduce the MACH_TYPE_XXXXXX for EB_CPUX9K2 board
Signed-off-by: Jens Scharsig <js_at_ng@scharsoft.de>
---
include/configs/eb_cpux9k2.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/configs/eb_cpux9k2.h b/include/configs/eb_cpux9k2.h
index 4324172..b08de4a 100644
--- a/include/configs/eb_cpux9k2.h
+++ b/include/configs/eb_cpux9k2.h
@@ -41,6 +41,8 @@
#define CONFIG_MISC_INIT_R
#define CONFIG_BOARD_EARLY_INIT_F
+#define MACH_TYPE_EB_CPUX9K2 1977
+#define CONFIG_MACH_TYPE MACH_TYPE_EB_CPUX9K2
/*--------------------------------------------------------------------------*/
#define CONFIG_SYS_TEXT_BASE 0x00000000
#define CONFIG_SYS_LOAD_ADDR 0x21000000 /* default load address */
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH] image: Allow images to indicate they're loadable at any address
From: Simon Glass @ 2011-10-31 18:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110311936.20941.marek.vasut@gmail.com>
Hi Marek,
On Mon, Oct 31, 2011 at 11:36 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> The legacy uImage format includes an absolute load and entry-
>> point address. When presented with a uImage in memory that
>> isn't loaded at the address in the image's load address,
>> U-Boot will relocate the image to its address in the header.
>>
>> Some payloads can actually be loaded and used at any arbitrary
>> address. An example is an ARM Linux kernel zImage file. This
>> is useful when sharing a single zImage across multiple boards
>> with different memory layouts, or U-Boot builds with different
>> ${load_addr} since sharing a single absolute load address may
>> not be possible.
>>
>> With this config option enabled, an image header may contain a
>> load address of -1/0xffffffff. This indicates the image can
>> operate at any load address, and U-Boot will avoid automtically
>> copying it anywhere. In this case, the entry-point field is
>> specified relative to the start of the image payload.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>> ---
>> Wolfgang,
>>
>> This is an much simpler and less invasive alternative to my previous
>> IH_TYPE_KERNEL_REL patch. If it's OK, you can ignore that patch.
>>
>> u-boot.bin sizes for Tegra Seaboard without/with this config option on:
>>
>> ? ?text ? ? ? ? ?data ? ? bss ? ? dec ? ? hex filename
>> ?165858 ? ? ? ? ?3565 ?217016 ?386439 ? 5e587 ./u-boot
>>
>> with:
>>
>> ? ?text ? ? ? ? ?data ? ? bss ? ? dec ? ? hex filename
>> ?165950 ? ? ? ? ?3565 ?217012 ?386527 ? 5e5df ./u-boot
>>
>
> [...]
>
> This one doesn't apply on top of current u-boot master
You need to revert Stephen's clean-up patch 1/2 712fbcf to test this.
Regards,
Simon
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply
* [U-Boot] [PATCH v3] arm926ejs: add NXP LPC32x0 cpu series support
From: Vladimir Zapolskiy @ 2011-10-31 18:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAEDE0B.7090201@aribaud.net>
Hi Albert,
On 31.10.2011 19:42, Albert ARIBAUD wrote:
> Hi Vladimir,
>
> Le 24/10/2011 01:04, Vladimir Zapolskiy a ?crit :
>> Hi Albert,
>>
>> On 22.10.2011 02:31, Albert ARIBAUD wrote:
>>> Hi Vladimir,
>>>
>>> Le 18/10/2011 17:55, Vladimir Zapolskiy a ?crit :
>>>> This change adds initial support for NXP LPC32x0 SoC series.
>>>>
>>>> Signed-off-by: Vladimir Zapolskiy<vz@mleia.com>
>>>> ---
>>>> Changes from v2 to v3:
>>>> * checkpatch.pl reports zero errors and warnings
>>>>
>>>> Changes from v1 to v2:
>>>> * BIT(n) and SBF(s, v) macro are not used anymore
>>>> * removed NS16550 and 14-clock UART definitions from uart.h
>>>> * added devices.c file, which contains standard UART preinitialization
>>>> routine
>>>> * added get_serial_clock() function, it returns actual frequency of
>>>> UART clock
>>>> * __udelay() realization is simplified, no need of interrupt handling
>>>
>>> As it stands, this is dead code until some board uses it; I imagine you
>>> have board waiting for this support. Can you submit the SoC and board
>>> code as a patch set? This way, it will be obvious for all that the SoC
>>> code in this patch has actual use.
>>
>> you're right, I have a board to make support for. However I presume that
>> U-boot maintainers won't be happy to include a board with
>> CONFIG_ENV_IS_NOWHERE, and unfortunately flash driver isn't yet ready
>> for publishing.
>
> CONFIG_ENV_IS_NOWHERE is the board( maintainer)'s business.
>
> Ditto for the FLASH driver, if it is not required for use of the board
> (e.g., if U-Boot can fire up and does not need the FLASH to boot an OS,
> then a broken FLASH driver is an inconvenience, not a showstopper).
I've added CFI flash support to the board, however the environment is
supposed to be stored in NAND flash, and that requires some more LPC32XX
specific stuff to be developed for U-boot soon (basically that's NAND
controller and DMA drivers).
>> I'd like to get an advice, if you think that weakly supported but
>> working U-boot on the board has chances to be included to arm-next I can
>> send the patchset right now for review, otherwise I'll spend some time
>> (one week approximately) to finish NAND driver.
>
> IMO, the acceptable state of a board is the board maintainer's affair,
> with a bare minimum that U-Boot must be able to play its role as a
> bootloader.
>
It's done in my understanding. Hopefully some more addons still should
be implemented, and I'd like to concentrate on them being assured that
the SoC and basic board support are pulled in.
> Anyway, since that is for next, not master, and since you think you can
> add the missing support far before the next merge window, I suggest you
> complete board support and add it to V4.
>
The initial board support was done and published a week ago, please
check http://lists.denx.de/pipermail/u-boot/2011-October/106991.html
And that's my expression of willing to become a board maintainer, sorry
it hasn't been included to the board changeset originally -
http://lists.denx.de/pipermail/u-boot/2011-October/107069.html
I'd like to encourage you to check that the board specific compilation
has zero warnings and checkpatch.pl output is clean.
--
With best wishes,
Vladimir
^ permalink raw reply
* [U-Boot] [PATCH] image: Allow images to indicate they're loadable at any address
From: Marek Vasut @ 2011-10-31 18:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319464779-23571-1-git-send-email-swarren@nvidia.com>
> The legacy uImage format includes an absolute load and entry-
> point address. When presented with a uImage in memory that
> isn't loaded at the address in the image's load address,
> U-Boot will relocate the image to its address in the header.
>
> Some payloads can actually be loaded and used at any arbitrary
> address. An example is an ARM Linux kernel zImage file. This
> is useful when sharing a single zImage across multiple boards
> with different memory layouts, or U-Boot builds with different
> ${load_addr} since sharing a single absolute load address may
> not be possible.
>
> With this config option enabled, an image header may contain a
> load address of -1/0xffffffff. This indicates the image can
> operate at any load address, and U-Boot will avoid automtically
> copying it anywhere. In this case, the entry-point field is
> specified relative to the start of the image payload.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> Wolfgang,
>
> This is an much simpler and less invasive alternative to my previous
> IH_TYPE_KERNEL_REL patch. If it's OK, you can ignore that patch.
>
> u-boot.bin sizes for Tegra Seaboard without/with this config option on:
>
> text data bss dec hex filename
> 165858 3565 217016 386439 5e587 ./u-boot
>
> with:
>
> text data bss dec hex filename
> 165950 3565 217012 386527 5e5df ./u-boot
>
[...]
This one doesn't apply on top of current u-boot master
^ permalink raw reply
* [U-Boot] Conflicting definitions of flush_dcache
From: Mike Frysinger @ 2011-10-31 18:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111031075624.GA9871@chokladfabriken.org>
On Monday 31 October 2011 03:56:25 Stefan Kristiansson wrote:
> so my gut feeling is that nios2 and the 2 ethernet drivers should be
> changed to use for example flush_dcache_range(?)
correct
> Perhaps cmd_cache.c should also be fixed to use flush_dcache_all()?
> flush_icache() ofcourse suffer from the same problem.
that sounds reasonable. the prototypes also need to get added to
include/common.h ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/2d6ed692/attachment.pgp
^ permalink raw reply
* [U-Boot] [PATCH 5/5] powerpc/85xx: resize the boot page TLB before relocating CCSR
From: Timur Tabi @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320085845-10547-1-git-send-email-timur@freescale.com>
On some Freescale systems (e.g. those booted from the on-chip ROM), the
TLB that covers the boot page can also cover CCSR, which breaks the CCSR
relocation code. To fix this, we resize the boot page TLB so that it only
covers the 4KB boot page.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/cpu/mpc85xx/start.S | 49 ++++++++++++++++++++++++++++++++++++++
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 6de8765..39f1438 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -330,6 +330,55 @@ l2_disabled:
#endif /* CONFIG_MPC8569 */
/*
+ * Search for the TLB that covers the code we're executing, and shrink it
+ * so that it covers only this 4K page. That will ensure that any other
+ * TLB we create won't interfere with it. We assume that the TLB exists,
+ * which is why we don't check the Valid bit of MAS1.
+ *
+ * This is necessary, for example, when booting from the on-chip ROM,
+ * which (oddly) creates a single 4GB TLB that covers CCSR and DDR.
+ * If we don't shrink this TLB now, then we'll accidentally delete it
+ * in "purge_old_ccsr_tlb" below.
+ */
+ bl nexti /* Find our address */
+nexti: mflr r1 /* R1 = our PC */
+ li r2, 0
+ mtspr MAS6, r2 /* Assume the current PID and AS are 0 */
+ isync
+ msync
+ tlbsx 0, r1 /* This must succeed */
+
+ /* Set the size of the TLB to 4KB */
+ mfspr r3, MAS1
+ li r2, 0xF00
+ andc r3, r3, r2 /* Clear the TSIZE bits */
+ ori r3, r3, MAS1_TSIZE(BOOKE_PAGESZ_4K)@l
+ mtspr MAS1, r3
+
+ /*
+ * Set the base address of the TLB to our PC. We assume that
+ * virtual == physical. We also assume that MAS2_EPN == MAS3_RPN.
+ */
+ lis r3, MAS2_EPN at h
+ ori r3, r3, MAS2_EPN at l /* R3 = MAS2_EPN */
+
+ and r1, r1, r3 /* Our PC, rounded down to the nearest page */
+
+ mfspr r2, MAS2
+ andc r2, r2, r3
+ or r2, r2, r1
+ mtspr MAS2, r2 /* Set the EPN to our PC base address */
+
+ mfspr r2, MAS3
+ andc r2, r2, r3
+ or r2, r2, r1
+ mtspr MAS3, r2 /* Set the RPN to our PC base address */
+
+ isync
+ msync
+ tlbwe
+
+/*
* Relocate CCSR, if necessary. We relocate CCSR if (obviously) the default
* location is not where we want it. This typically happens on a 36-bit
* system, where we want to move CCSR to near the top of 36-bit address space.
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH 4/5] powerpc/85xx: verify the current address of CCSR before relocating it
From: Timur Tabi @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320085845-10547-1-git-send-email-timur@freescale.com>
Verify that CCSR is actually located where it is supposed to be before
we relocate it. This is useful in detecting U-Boot configurations that
are broken (e.g. an incorrect value for CONFIG_SYS_CCSRBAR_DEFAULT).
If the current value is wrong, we enter an infinite loop, which is handy
for debuggers.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/cpu/mpc85xx/start.S | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index ccb331a..6de8765 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -422,6 +422,33 @@ create_ccsr_old_tlb:
msync
tlbwe
+ /*
+ * We have a TLB for what we think is the current (old) CCSR. Let's
+ * verify that, otherwise we won't be able to move it.
+ * CONFIG_SYS_CCSRBAR_DEFAULT is always a 32-bit number, so we only
+ * need to compare the lower 32 bits of CCSRBAR on CoreNet systems.
+ */
+verify_old_ccsr:
+ lis r0, CONFIG_SYS_CCSRBAR_DEFAULT at h
+ ori r0, r0, CONFIG_SYS_CCSRBAR_DEFAULT at l
+#ifdef CONFIG_FSL_CORENET
+ lwz r1, 4(r9) /* CCSRBARL */
+#else
+ lwz r1, 0(r9) /* CCSRBAR, shifted right by 12 */
+ slwi r1, r1, 12
+#endif
+
+ cmpl 0, r0, r1
+
+ /*
+ * If the value we read from CCSRBARL is not what we expect, then
+ * enter an infinite loop. This will at least allow a debugger to
+ * halt execution and examine TLBs, etc. There's no point in going
+ * on.
+ */
+infinite_debug_loop:
+ bne infinite_debug_loop
+
#ifdef CONFIG_FSL_CORENET
#define CCSR_LAWBARH0 (CONFIG_SYS_CCSRBAR + 0x1000)
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH 3/5] powerpc/85xx: add some missing sync instructions in the CCSR relocation code
From: Timur Tabi @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320085845-10547-1-git-send-email-timur@freescale.com>
Calls to tlbwe and tlbsx should be preceded with an isync/msync pair.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/cpu/mpc85xx/start.S | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index b5bf1fa..ccb331a 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -363,6 +363,8 @@ purge_old_ccsr_tlb:
li r1, 0
mtspr MAS6, r1 /* Search the current address space and PID */
+ isync
+ msync
tlbsx 0, r8
mfspr r1, MAS1
andis. r2, r1, MAS1_VALID at h /* Check for the Valid bit */
@@ -370,6 +372,8 @@ purge_old_ccsr_tlb:
rlwinm r1, r1, 0, 1, 31 /* Clear Valid bit */
mtspr MAS1, r1
+ isync
+ msync
tlbwe
1:
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH 2/5] powerpc/85xx: fix some comments in the CCSR relocation code
From: Timur Tabi @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320085845-10547-1-git-send-email-timur@freescale.com>
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/cpu/mpc85xx/start.S | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 528abc9..b5bf1fa 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -398,7 +398,7 @@ create_ccsr_new_tlb:
tlbwe
/*
- * Create a TLB for the old location of CCSR. Register R9 is reserved
+ * Create a TLB for the current location of CCSR. Register R9 is reserved
* for the virtual address of this TLB (CONFIG_SYS_CCSRBAR + 0x1000).
*/
create_ccsr_old_tlb:
@@ -457,7 +457,7 @@ create_temp_law:
*/
read_old_ccsrbar:
lwz r0, 0(r9) /* CCSRBARH */
- lwz r0, 4(r9) /* CCSRBARH */
+ lwz r0, 4(r9) /* CCSRBARL */
isync
/*
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH 1/5] powerpc/85xx: fix definition of MAS register macros
From: Timur Tabi @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
Some of the MAS register macros do not protect the parameter with
parentheses, which could cause wrong values if the parameter includes
operators.
Also fix the definition of TSIZE_TO_BYTES() so that it actually uses
the parameter. This hasn't caused any problems to date because the
parameter was always been 'tsize'.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/include/asm/mmu.h | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index ef5076b..209103e 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -392,17 +392,17 @@ extern void print_bats(void);
*/
#define MAS0_TLBSEL_MSK 0x30000000
-#define MAS0_TLBSEL(x) ((x << 28) & MAS0_TLBSEL_MSK)
+#define MAS0_TLBSEL(x) (((x) << 28) & MAS0_TLBSEL_MSK)
#define MAS0_ESEL_MSK 0x0FFF0000
-#define MAS0_ESEL(x) ((x << 16) & MAS0_ESEL_MSK)
+#define MAS0_ESEL(x) (((x) << 16) & MAS0_ESEL_MSK)
#define MAS0_NV(x) ((x) & 0x00000FFF)
#define MAS1_VALID 0x80000000
#define MAS1_IPROT 0x40000000
-#define MAS1_TID(x) ((x << 16) & 0x3FFF0000)
+#define MAS1_TID(x) (((x) << 16) & 0x3FFF0000)
#define MAS1_TS 0x00001000
-#define MAS1_TSIZE(x) ((x << 8) & 0x00000F00)
-#define TSIZE_TO_BYTES(x) ((phys_addr_t)(1UL << ((tsize * 2) + 10)))
+#define MAS1_TSIZE(x) (((x) << 8) & 0x00000F00)
+#define TSIZE_TO_BYTES(x) (1ULL << (((x) * 2) + 10))
#define MAS2_EPN 0xFFFFF000
#define MAS2_X0 0x00000040
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH] gpio: Adapt PCA9698 to standard GPIO API
From: Mike Frysinger @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320050352-17351-1-git-send-email-eibach@gdsys.de>
nice ...
Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/ff1b8df3/attachment.pgp
^ permalink raw reply
* [U-Boot] [PATCH] ARM: define CONFIG_MACH_TYPE for all keymile boards
From: Mike Frysinger @ 2011-10-31 18:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE7CE6.8080109@compulab.co.il>
On Monday 31 October 2011 06:48:06 Igor Grinberg wrote:
> On 10/31/11 12:07, Valentin Longchamp wrote:
> > --- a/include/configs/km/km_arm.h
> > +++ b/include/configs/km/km_arm.h
> > @@ -48,6 +48,8 @@
> >
> > #define CONFIG_KW88F6281 /* SOC Name */
> > #define CONFIG_MACH_KM_KIRKWOOD /* Machine type */
> >
> > +#define CONFIG_MACH_TYPE MACH_TYPE_KM_KIRKWOOD
> > +
>
> Probably, you also want to remove the gd->bd->bi_arch_number
> assignment from board files using this mach id?
if possible, i'd like to punt bi_arch_number from everyone ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/6bc9bf6c/attachment.pgp
^ permalink raw reply
* [U-Boot] [PATCH] miiphy: Note that miiphy_* API is deprecated
From: Mike Frysinger @ 2011-10-31 18:24 UTC (permalink / raw)
To: u-boot
In-Reply-To: <10B6933F-AEDD-49DA-9361-5868A5F2F327@freescale.com>
On Monday 31 October 2011 11:12:12 Andy Fleming wrote:
> On Oct 31, 2011, at 10:08 AM, Tabi Timur-B04825 wrote:
> > On Mon, Oct 31, 2011 at 9:46 AM, Andy Fleming wrote:
> >> We want to move everything to phylib, and we definitely don't want
> >> new drivers using the miiphy infrastructure.
> >
> > How about using gcc's deprecated function feature? Or is that too
> > aggressive?
>
> I don't think we want every net driver prior to the last release to create
> a warning. We may switch to that after we get some momentum on switching
> drivers over. The first goal is just to provide information that a new
> driver-writer may see so that the old API doesn't expand.
right, this is why i didn't suggest a #warning or __deprecated before. i'm
pretty sure way more code is using the old phy layer than the new phy layer
atm.
i also want to say that the new phy layer doesn't have all the support that
the old one did ... if you look in include/miiphy.h, there are a few defines at
the end there which are not in linux/mii.h.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/296b8b1e/attachment.pgp
^ permalink raw reply
* [U-Boot] [PATCH 1/2] PXA: Add MMC driver using the generic MMC framework
From: Marek Vasut @ 2011-10-31 18:23 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1314568975-19619-1-git-send-email-marek.vasut@gmail.com>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> ---
> arch/arm/include/asm/arch-pxa/regs-mmc.h | 155 +++++++++++
> drivers/mmc/Makefile | 1 +
> drivers/mmc/pxa_mmc_gen.c | 442
> ++++++++++++++++++++++++++++++ 3 files changed, 598 insertions(+), 0
> deletions(-)
> create mode 100644 arch/arm/include/asm/arch-pxa/regs-mmc.h
> create mode 100644 drivers/mmc/pxa_mmc_gen.c
Hey Andy,
maybe you can pick this up now?
Cheers
^ permalink raw reply
* [U-Boot] mx31: NAND_SPL boot question for TT-01
From: Stefano Babic @ 2011-10-31 18:21 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAED472.7080903@hale.at>
On 10/31/2011 06:01 PM, Helmut Raiger wrote:
> Hi (Stefano),
>
> just a short question. I'd like to add NAND boot to the board
> support of our TT-01.
> I checked out the mx31pdk code and also found something in doc/README.SPL
> which does not seem to correspond.
Right. A lot of work was done recently, and now there is a common SPL
framework in u-boot. The README.spl refers to the new stuff.
Before of that, booting from NAND was done in a different manner. This
is what you find under board/freescale/mx31pdk. The mx31pdk is booting
with the old mechanism.
New boards must implement the SPL according to the new framework, using
CONFIG_SPL and setting the SPL configuration in the board configuration
file. I am expecting
Stefano
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* [U-Boot] [PATCH v7 1/4] tegra2: Move MMC clock initialization into MMC driver
From: Simon Glass @ 2011-10-31 18:08 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320079897-29473-1-git-send-email-swarren@nvidia.com>
Hi Stephen,
On Mon, Oct 31, 2011 at 9:51 AM, Stephen Warren <swarren@nvidia.com> wrote:
> This centralizes knowledge of MMC clocking into the MMC driver. This also
> removes clock setup from the board files, which will simplify later changes
> that modify the Harmony board to support the correct set of MMC controllers.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> Cc: Andy Fleming <afleming@gmail.com>
> Acked-by: Simon Glass <sjg@chromium.org>
> Tested-by: Simon Glass <sjg@chromium.org>
I retested this new patch series with the latest master (mmc part,
ext2ls and ext2load) and it is fine.
Regards,
Simon
> ---
> ?board/nvidia/common/board.c | ? 13 +------------
> ?drivers/mmc/tegra2_mmc.c ? ?| ? 12 +++++++++---
> ?2 files changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
> index d13537d..370a259 100644
> --- a/board/nvidia/common/board.c
> +++ b/board/nvidia/common/board.c
> @@ -102,16 +102,6 @@ static void pin_mux_uart(void)
>
> ?#ifdef CONFIG_TEGRA2_MMC
> ?/*
> - * Routine: clock_init_mmc
> - * Description: init the PLL and clocks for the SDMMC controllers
> - */
> -static void clock_init_mmc(void)
> -{
> - ? ? ? clock_start_periph_pll(PERIPH_ID_SDMMC4, CLOCK_ID_PERIPH, 20000000);
> - ? ? ? clock_start_periph_pll(PERIPH_ID_SDMMC3, CLOCK_ID_PERIPH, 20000000);
> -}
> -
> -/*
> ?* Routine: pin_mux_mmc
> ?* Description: setup the pin muxes/tristate values for the SDMMC(s)
> ?*/
> @@ -157,8 +147,7 @@ int board_init(void)
> ?int board_mmc_init(bd_t *bd)
> ?{
> ? ? ? ?debug("board_mmc_init called\n");
> - ? ? ? /* Enable clocks, muxes, etc. for SDMMC controllers */
> - ? ? ? clock_init_mmc();
> + ? ? ? /* Enable muxes, etc. for SDMMC controllers */
> ? ? ? ?pin_mux_mmc();
> ? ? ? ?gpio_config_mmc();
>
> diff --git a/drivers/mmc/tegra2_mmc.c b/drivers/mmc/tegra2_mmc.c
> index 9e741f2..78b1190 100644
> --- a/drivers/mmc/tegra2_mmc.c
> +++ b/drivers/mmc/tegra2_mmc.c
> @@ -435,14 +435,22 @@ static int mmc_core_init(struct mmc *mmc)
>
> ?static int tegra2_mmc_initialize(int dev_index, int bus_width)
> ?{
> + ? ? ? struct mmc_host *host;
> ? ? ? ?struct mmc *mmc;
>
> ? ? ? ?debug(" mmc_initialize called\n");
>
> + ? ? ? host = &mmc_host[dev_index];
> +
> + ? ? ? host->clock = 0;
> + ? ? ? tegra2_get_setup(host, dev_index);
> +
> + ? ? ? clock_start_periph_pll(host->mmc_id, CLOCK_ID_PERIPH, 20000000);
> +
> ? ? ? ?mmc = &mmc_dev[dev_index];
>
> ? ? ? ?sprintf(mmc->name, "Tegra2 SD/MMC");
> - ? ? ? mmc->priv = &mmc_host[dev_index];
> + ? ? ? mmc->priv = host;
> ? ? ? ?mmc->send_cmd = mmc_send_cmd;
> ? ? ? ?mmc->set_ios = mmc_set_ios;
> ? ? ? ?mmc->init = mmc_core_init;
> @@ -465,8 +473,6 @@ static int tegra2_mmc_initialize(int dev_index, int bus_width)
> ? ? ? ?mmc->f_min = 375000;
> ? ? ? ?mmc->f_max = 48000000;
>
> - ? ? ? mmc_host[dev_index].clock = 0;
> - ? ? ? tegra2_get_setup(&mmc_host[dev_index], dev_index);
> ? ? ? ?mmc_register(mmc);
>
> ? ? ? ?return 0;
> --
> 1.7.0.4
>
>
^ permalink raw reply
* [U-Boot] [PATCH 5/6] PXA: Cleanup serial_pxa
From: Marek Vasut @ 2011-10-31 18:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1314495737-29436-5-git-send-email-marek.vasut@gmail.com>
> * Cleanup register definitions by introducing new regs-uart.h, compliant
> with rest of U-Boot.
> * Remove old register definitions from pxa-regs.h
> * Convert serial_pxa to new regs-uart.h
> * Cleanup serial_pxa
>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Hi Albert,
did you pick this one up? Maybe we can pick it up for .12 release?
Cheers
^ 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