Re: [U-Boot-Users] [PATCH] 8xxx-fdt: set ns16550 clock from CFG_NS16550_CLK, not bi_busfreq
On Aug 15, 2008, at 9:23 AM, Zach Sadecki wrote: Andy Fleming wrote: On Wed, Jul 9, 2008 at 4:53 PM, Kim Phillips [EMAIL PROTECTED] wrote: On Wed, 9 Jul 2008 14:43:46 -0400 Paul Gortmaker [EMAIL PROTECTED] wrote: Some boards that have external 16550 UARTs don't have a direct tie between bi_busfreq and the clock used for the UARTs. Boards that do have such a tie should set CFG_NS16550_CLK to be get_bus_freq(0) -- which most of them do already. Signed-off-by: Paul Gortmaker [EMAIL PROTECTED] Acked-by: Kim Phillips [EMAIL PROTECTED] Applied, thanks Andy What about the situation were both exist? The current scheme doesn't really allow for that, as it treats all ns16550 devices the same. We have a board that uses both SOC UARTs on the 8548 and a DUART controller on the local bus. It used to work fine with the old u-boot fdt scheme, as the fixup was specific to the SOC UARTs. We made a local modification to our device tree and u-boot to work around this, but I don't know if it's a good solution to push a patch for. We simply added fsl,soc-uart to the compatibility list in the fdt for the SOC UARTs, and now have the u-boot uart clock-frequency fixup search for that rather than ns16550. Does this seem like a reasonable solution to push a patch for? I'm not sure as it requires changes to all the device trees as well as u-boot. If it's not, then what would be a better solution? How do you have CFG_NS16550_CLK defined on you board? is the the freq for the SOC UARTs? if so you can just update your lbc clocks in your own board code after you call ft_cpu_setup() - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 85xx: Not enough room for program headers
On Aug 7, 2008, at 5:47 AM, Rafal Jaworowski wrote: Kumar Gala wrote: Can you try the following patch and see if works for you (make sure the resulting image actually boots the board). If so I'll fixup all the .lds I changed to match. Hi Kumar, Thanks, the code works, although during compilation the following warning appears: ./MAKEALL MPC8555CDS Configuring for MPC8555CDS board... ppc_85xx-ld: u-boot: warning: allocated section `.bss' not in segment textdata bss dec hex filename 194515 16028 26488 237031 39de7 ./u-boot Yeah it was the best I could do.. older binutils have some issue and figured a warning was better than it not functioning at all. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] CUSTODIANS: Final boarding call for flight 1.3.4 ...
On Aug 7, 2008, at 3:56 AM, Wolfgang Denk wrote: Hi custodians, there are a couple of recent patches which include some bug fixes that look urgent enough to be included with the upcoming 1.3.4 release (the last one with the old version number system). Did we come to resolution on what the new numbering system will be? Can you please process these patcehs and send your pull requests not later than Friday night? Andy's out so can you pick up the 85xx linker script patch I'm about to send to address Rafal's issues. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH][for 1.3.4] mpc85xx: workaround old binutils bug
The recent change to move the .bss outside of the image gives older
binutils (ld from eldk4.1/binutils-2.16) some headache:
ppc_85xx-ld: u-boot: Not enough room for program headers (allocated 3, need 4)
ppc_85xx-ld: final link failed: Bad value
We workaround it by being explicit about the program headers and not
assigning the .bss to a program header.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Wolfgang, can you pick this up for 1.3.4 as Andy's on vacation.
- k
board/freescale/mpc8540ads/u-boot.lds | 15 ++-
board/freescale/mpc8541cds/u-boot.lds | 15 ++-
board/freescale/mpc8544ds/u-boot.lds | 15 ++-
board/freescale/mpc8548cds/u-boot.lds | 15 ++-
board/freescale/mpc8555cds/u-boot.lds | 15 ++-
board/freescale/mpc8560ads/u-boot.lds | 15 ++-
board/freescale/mpc8568mds/u-boot.lds | 15 ++-
7 files changed, 70 insertions(+), 35 deletions(-)
diff --git a/board/freescale/mpc8540ads/u-boot.lds
b/board/freescale/mpc8540ads/u-boot.lds
index 0e4f5a2..999a44f 100644
--- a/board/freescale/mpc8540ads/u-boot.lds
+++ b/board/freescale/mpc8540ads/u-boot.lds
@@ -26,6 +26,11 @@
OUTPUT_ARCH(powerpc)
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD;
+}
+
SECTIONS
{
/* Read-only sections, merged into text segment: */
@@ -57,7 +62,7 @@ SECTIONS
*(.text)
*(.fixup)
*(.got1)
- }
+ } :text
_etext = .;
PROVIDE (etext = .);
.rodata:
@@ -66,7 +71,7 @@ SECTIONS
*(.rodata1)
*(.rodata.str1.4)
*(.eh_frame)
- }
+ } :text
.fini : { *(.fini)} =0
.ctors : { *(.ctors) }
.dtors : { *(.dtors) }
@@ -118,12 +123,12 @@ SECTIONS
.bootpg ADDR(.text) + 0x7f000 :
{
cpu/mpc85xx/start.o(.bootpg)
- } = 0x
+ } :text = 0x
.resetvec ADDR(.text) + 0x7fffc :
{
*(.resetvec)
- } = 0x
+ } :text = 0x
. = ADDR(.text) + 0x8;
@@ -134,7 +139,7 @@ SECTIONS
*(.dynbss)
*(.bss)
*(COMMON)
- }
+ } :NONE
. = ALIGN(4);
_end = . ;
diff --git a/board/freescale/mpc8541cds/u-boot.lds
b/board/freescale/mpc8541cds/u-boot.lds
index 1c583de..acb9c1c 100644
--- a/board/freescale/mpc8541cds/u-boot.lds
+++ b/board/freescale/mpc8541cds/u-boot.lds
@@ -23,6 +23,11 @@
OUTPUT_ARCH(powerpc)
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD;
+}
+
SECTIONS
{
/* Read-only sections, merged into text segment: */
@@ -54,7 +59,7 @@ SECTIONS
*(.text)
*(.fixup)
*(.got1)
- }
+ } :text
_etext = .;
PROVIDE (etext = .);
.rodata:
@@ -63,7 +68,7 @@ SECTIONS
*(.rodata1)
*(.rodata.str1.4)
*(.eh_frame)
- }
+ } :text
.fini : { *(.fini)} =0
.ctors : { *(.ctors) }
.dtors : { *(.dtors) }
@@ -115,12 +120,12 @@ SECTIONS
.bootpg ADDR(.text) + 0x7f000 :
{
cpu/mpc85xx/start.o(.bootpg)
- } = 0x
+ } :text = 0x
.resetvec ADDR(.text) + 0x7fffc :
{
*(.resetvec)
- } = 0x
+ } :text = 0x
. = ADDR(.text) + 0x8;
@@ -131,7 +136,7 @@ SECTIONS
*(.dynbss)
*(.bss)
*(COMMON)
- }
+ } :NONE
. = ALIGN(4);
_end = . ;
diff --git a/board/freescale/mpc8544ds/u-boot.lds
b/board/freescale/mpc8544ds/u-boot.lds
index 500e647..05010ca 100644
--- a/board/freescale/mpc8544ds/u-boot.lds
+++ b/board/freescale/mpc8544ds/u-boot.lds
@@ -23,6 +23,11 @@
OUTPUT_ARCH(powerpc)
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD;
+}
+
SECTIONS
{
/* Read-only sections, merged into text segment: */
@@ -54,7 +59,7 @@ SECTIONS
*(.text)
*(.fixup)
*(.got1)
- }
+ } :text
_etext = .;
PROVIDE (etext = .);
.rodata:
@@ -63,7 +68,7 @@ SECTIONS
*(.rodata1)
*(.rodata.str1.4)
*(.eh_frame)
- }
+ } :text
.fini : { *(.fini)} =0
.ctors : { *(.ctors) }
.dtors : { *(.dtors) }
@@ -115,12 +120,12 @@ SECTIONS
.bootpg ADDR(.text) + 0x7f000 :
{
cpu/mpc85xx/start.o(.bootpg)
- } = 0x
+ } :text = 0x
.resetvec ADDR(.text) + 0x7fffc :
{
*(.resetvec)
- } = 0x
+ } :text = 0x
. = ADDR(.text) + 0x8;
@@ -131,7 +136,7 @@ SECTIONS
*(.dynbss)
*(.bss)
*(COMMON)
- }
+ } :NONE
. = ALIGN(4);
_end = . ;
diff --git a/board/freescale/mpc8548cds/u-boot.lds
b/board/freescale/mpc8548cds/u-boot.lds
index 6b93395..f4e6e15 100644
--- a/board/freescale/mpc8548cds/u-boot.lds
+++ b/board/freescale/mpc8548cds/u-boot.lds
@@ -23,6 +23,11 @@
OUTPUT_ARCH(powerpc)
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD;
+}
+
SECTIONS
{
/* Read-only sections, merged into text segment: */
@@ -54,7 +59,7 @@ SECTIONS
*(.text)
*(.fixup)
*(.got1)
- }
+ } :text
_etext = .;
PROVIDE (etext = .);
.rodata:
@@ -63,7 +68,7
[U-Boot-Users] [PATCH v2][for 1.3.4] mpc85xx: workaround old binutils bug
The recent change to move the .bss outside of the image gives older
binutils (ld from eldk4.1/binutils-2.16) some headache:
ppc_85xx-ld: u-boot: Not enough room for program headers (allocated 3, need 4)
ppc_85xx-ld: final link failed: Bad value
We workaround it by being explicit about the program headers and not
assigning the .bss to a program header.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Fixes warning with older binutils
board/freescale/mpc8540ads/u-boot.lds | 16 +++-
board/freescale/mpc8541cds/u-boot.lds | 16 +++-
board/freescale/mpc8544ds/u-boot.lds | 16 +++-
board/freescale/mpc8548cds/u-boot.lds | 16 +++-
board/freescale/mpc8555cds/u-boot.lds | 16 +++-
board/freescale/mpc8560ads/u-boot.lds | 16 +++-
board/freescale/mpc8568mds/u-boot.lds | 16 +++-
7 files changed, 77 insertions(+), 35 deletions(-)
diff --git a/board/freescale/mpc8540ads/u-boot.lds
b/board/freescale/mpc8540ads/u-boot.lds
index 0e4f5a2..515d320 100644
--- a/board/freescale/mpc8540ads/u-boot.lds
+++ b/board/freescale/mpc8540ads/u-boot.lds
@@ -26,6 +26,12 @@
OUTPUT_ARCH(powerpc)
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD;
+ bss PT_LOAD;
+}
+
SECTIONS
{
/* Read-only sections, merged into text segment: */
@@ -57,7 +63,7 @@ SECTIONS
*(.text)
*(.fixup)
*(.got1)
- }
+ } :text
_etext = .;
PROVIDE (etext = .);
.rodata:
@@ -66,7 +72,7 @@ SECTIONS
*(.rodata1)
*(.rodata.str1.4)
*(.eh_frame)
- }
+ } :text
.fini : { *(.fini)} =0
.ctors : { *(.ctors) }
.dtors : { *(.dtors) }
@@ -118,12 +124,12 @@ SECTIONS
.bootpg ADDR(.text) + 0x7f000 :
{
cpu/mpc85xx/start.o(.bootpg)
- } = 0x
+ } :text = 0x
.resetvec ADDR(.text) + 0x7fffc :
{
*(.resetvec)
- } = 0x
+ } :text = 0x
. = ADDR(.text) + 0x8;
@@ -134,7 +140,7 @@ SECTIONS
*(.dynbss)
*(.bss)
*(COMMON)
- }
+ } :bss
. = ALIGN(4);
_end = . ;
diff --git a/board/freescale/mpc8541cds/u-boot.lds
b/board/freescale/mpc8541cds/u-boot.lds
index 1c583de..d728d8b 100644
--- a/board/freescale/mpc8541cds/u-boot.lds
+++ b/board/freescale/mpc8541cds/u-boot.lds
@@ -23,6 +23,12 @@
OUTPUT_ARCH(powerpc)
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD;
+ bss PT_LOAD;
+}
+
SECTIONS
{
/* Read-only sections, merged into text segment: */
@@ -54,7 +60,7 @@ SECTIONS
*(.text)
*(.fixup)
*(.got1)
- }
+ } :text
_etext = .;
PROVIDE (etext = .);
.rodata:
@@ -63,7 +69,7 @@ SECTIONS
*(.rodata1)
*(.rodata.str1.4)
*(.eh_frame)
- }
+ } :text
.fini : { *(.fini)} =0
.ctors : { *(.ctors) }
.dtors : { *(.dtors) }
@@ -115,12 +121,12 @@ SECTIONS
.bootpg ADDR(.text) + 0x7f000 :
{
cpu/mpc85xx/start.o(.bootpg)
- } = 0x
+ } :text = 0x
.resetvec ADDR(.text) + 0x7fffc :
{
*(.resetvec)
- } = 0x
+ } :text = 0x
. = ADDR(.text) + 0x8;
@@ -131,7 +137,7 @@ SECTIONS
*(.dynbss)
*(.bss)
*(COMMON)
- }
+ } :bss
. = ALIGN(4);
_end = . ;
diff --git a/board/freescale/mpc8544ds/u-boot.lds
b/board/freescale/mpc8544ds/u-boot.lds
index 500e647..a05ece5 100644
--- a/board/freescale/mpc8544ds/u-boot.lds
+++ b/board/freescale/mpc8544ds/u-boot.lds
@@ -23,6 +23,12 @@
OUTPUT_ARCH(powerpc)
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD;
+ bss PT_LOAD;
+}
+
SECTIONS
{
/* Read-only sections, merged into text segment: */
@@ -54,7 +60,7 @@ SECTIONS
*(.text)
*(.fixup)
*(.got1)
- }
+ } :text
_etext = .;
PROVIDE (etext = .);
.rodata:
@@ -63,7 +69,7 @@ SECTIONS
*(.rodata1)
*(.rodata.str1.4)
*(.eh_frame)
- }
+ } :text
.fini : { *(.fini)} =0
.ctors : { *(.ctors) }
.dtors : { *(.dtors) }
@@ -115,12 +121,12 @@ SECTIONS
.bootpg ADDR(.text) + 0x7f000 :
{
cpu/mpc85xx/start.o(.bootpg)
- } = 0x
+ } :text = 0x
.resetvec ADDR(.text) + 0x7fffc :
{
*(.resetvec)
- } = 0x
+ } :text = 0x
. = ADDR(.text) + 0x8;
@@ -131,7 +137,7 @@ SECTIONS
*(.dynbss)
*(.bss)
*(COMMON)
- }
+ } :bss
. = ALIGN(4);
_end = . ;
diff --git a/board/freescale/mpc8548cds/u-boot.lds
b/board/freescale/mpc8548cds/u-boot.lds
index 6b93395..d4a2f72 100644
--- a/board/freescale/mpc8548cds/u-boot.lds
+++ b/board/freescale/mpc8548cds/u-boot.lds
@@ -23,6 +23,12 @@
OUTPUT_ARCH(powerpc)
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD;
+ bss PT_LOAD;
+}
+
SECTIONS
{
/* Read-only sections, merged into text segment: */
@@ -54,7 +60,7 @@ SECTIONS
*(.text)
*(.fixup)
*(.got1)
- }
+ } :text
_etext = .;
PROVIDE (etext
[U-Boot-Users] bootm support for netbsd question
Anyone know why we pass the image_header_t * to the netbsd loader? /* * Booting a (NetBSD) kernel image * * This process is pretty similar to a standalone application: * The (first part of an multi-) image must be a stage-2 loader, * which in turn is responsible for loading invoking the actual * kernel. The only differences are the parameters being passed: * besides the board info strucure, the loader expects a command * line, the name of the console device, and (optionally) the * address of the original image header. */ ... /* * NetBSD Stage-2 Loader Parameters: * r3: ptr to board info data * r4: image address * r5: console device * r6: boot args string */ (*loader) (gd-bd, os_hdr, consdev, cmdline); this is some pretty tight coupling with u-boot. Is the stage-2 loader part of u-boot? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] bootm as a script -- requires HUSH?
if I understand Wolfgang and Jerry they'd like to recode the control flow of the bootm command in the scripting env u-boot provides. This seems to imply that we'd require HUSH as the simple parser doesn't seem to provide any control statements like (if..then..else). is this correct? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] bootm as a script -- requires HUSH?
On Aug 7, 2008, at 12:21 PM, Jerry Van Baren wrote: Kumar Gala wrote: if I understand Wolfgang and Jerry they'd like to recode the control flow of the bootm command in the scripting env u-boot provides. This seems to imply that we'd require HUSH as the simple parser doesn't seem to provide any control statements like (if..then..else). is this correct? - k Yes. Than I think the ideas you guys have aren't beneficial to anyone. What benefit to we gain by doing this? Its going to be slower and larger. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] bootm as a script -- requires HUSH?
On Aug 7, 2008, at 2:34 PM, Wolfgang Denk wrote: In any case, I expoect the total numbers of lines of code in U-Boot to go down by quite an amount - for example, if we manage to get rid of all the code duplication we have now across architectures. I doubt this is really going to happen because the majority of code is specific to the mechanism used to boot a kernel that is arch specific. (ie, the ePAPR style interface on PPC, the TAGs support on ARM, etc.) I dont see how we reduce code in that area (since it seems fundamentally arch specific). - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] bootm as a script -- requires HUSH?
On Aug 7, 2008, at 2:29 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: if I understand Wolfgang and Jerry they'd like to recode the control flow of the bootm command in the scripting env u-boot provides. This seems to imply that we'd require HUSH as the simple parser doesn't seem to provide any control statements like (if..then..else). is this correct? I woul like to avoid that, if possible. Which implies to me the sequence has to be a simple ordered sequence w/ o any if/than/else aspects to it. Am I missing something? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] bootm as a script -- requires HUSH?
On Aug 7, 2008, at 3:47 PM, Wolfgang Denk wrote: In message 45CA6EEB-4A74-46FC-A544- [EMAIL PROTECTED] you wrote: On Aug 7, 2008, at 2:34 PM, Wolfgang Denk wrote: In any case, I expoect the total numbers of lines of code in U- Boot to go down by quite an amount - for example, if we manage to get rid of all the code duplication we have now across architectures. I doubt this is really going to happen because the majority of code is specific to the mechanism used to boot a kernel that is arch specific. (ie, the ePAPR style interface on PPC, the TAGs support on ARM, etc.) I dont see how we reduce code in that area (since it seems fundamentally arch specific). There is a lot of common code - verify and uncompress the Linux kernel image; check for existence of, then verify and load the ramdisk, etc. I agree that there is probably a far amount of code in lib_ppc/bootm.c that can be made common above it. The ARCH specific bits seem to be the jump and the specific mechanism to pass boot information to the kernel (bd_t, fdt, ARM tags, etc). - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH][FOR 1.3.4] 85xx: Don't move interrupt vector to low memory
Moving the interrupt vectors to low memory can cause issues if the code gets overwritten via some image loading command (tftp, boot*, etc.) and interrupts (like the decrementer are enabled). On 85xx there is no reason to copy the interrupt vectors to low memory since we can run them in high memory since we are a Book-E core. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- This is a fix for 1.3.4. - k cpu/mpc85xx/start.S | 19 +-- 1 files changed, 5 insertions(+), 14 deletions(-) diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S index 10fe936..9c8b2a1 100644 --- a/cpu/mpc85xx/start.S +++ b/cpu/mpc85xx/start.S @@ -936,13 +936,6 @@ trap_init: bgelr /* return if r7=r8 - just in case */ mflrr4 /* save link register */ -1: - lwz r0,0(r7) - stw r0,0(r9) - addir7,r7,4 - addir9,r9,4 - cmplw 0,r7,r8 - bne 1b /* * relocate `hdlr' and `int_return' entries @@ -973,9 +966,6 @@ trap_init: cmplw 0,r7,r8 blt 2b - lis r7,0x0 - mtspr IVPR,r7 - mtlrr4 /* restore link register*/ blr @@ -983,13 +973,14 @@ trap_init: * Function: relocate entries for one exception vector */ trap_reloc: - lwz r0,0(r7)/* hdlr ... */ + lwzxr0,r3,r7/* hdlr ... */ add r0,r0,r3/* ... += dest_addr*/ - stw r0,0(r7) + stwxr0,r3,r7 - lwz r0,4(r7)/* int_return ... */ + addir7,r7,4 + lwzxr0,r3,r7/* int_return ... */ add r0,r0,r3/* ... += dest_addr*/ - stw r0,4(r7) + stwxr0,r3,r7 blr -- 1.5.5.1 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 3/3] add ability to disable ft_board_setup as part of bootm
if the environment variable 'disable_fdt_boardsetup' is set we skip doing the ft_board_setup(). Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- lib_ppc/bootm.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c index 1182c50..a5b3a45 100644 --- a/lib_ppc/bootm.c +++ b/lib_ppc/bootm.c @@ -192,7 +192,8 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[], } #ifdef CONFIG_OF_BOARD_SETUP /* Call the board-specific fixup routine */ - ft_board_setup(of_flat_tree, gd-bd); + if (!getenv(disable_fdt_boardsetup)) + ft_board_setup(of_flat_tree, gd-bd); #endif } -- 1.5.5.1 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH][FOR 1.3.4] 85xx: Don't move interrupt vector to low memory
On Aug 6, 2008, at 1:50 AM, Wolfgang Denk wrote: In message Pine.LNX. [EMAIL PROTECTED] you wrote: Moving the interrupt vectors to low memory can cause issues if the code gets overwritten via some image loading command (tftp, boot*, etc.) and interrupts (like the decrementer are enabled). Oops? This is expected and normal behaviour. Did anybody complain about this? Real, any reason why? I understand on classic PPC this might be the case but I see no reason for it to be so on book-e parts. On 85xx there is no reason to copy the interrupt vectors to low memory since we can run them in high memory since we are a Book-E core. High memory means leave them in flash? No I leave them at the relocated location in DDR. Then you will probably see nice crashes as soon as you erase U-Boot for example to install a new version. All references to flash memory must be relocated to RAM, including the exception vectors, of course. Any they are. I'm just removing a second relocation that is a hold over from how 6xx PPC exception vectors work. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- This is a fix for 1.3.4. I don't think so. Seems to introduce a bug. I disagree with that. It resolved a bug when I did. 'setenv autostart no; bootm' - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 2/3] Add ePAPR boot command
On Aug 6, 2008, at 3:21 AM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Add a boot command that supports the ePAPR client interface on powerpc. What is the intended use of such a command? How does it intergrate with with image formats supported by U-Boot? To me it seems that it's mostly intended to be called by other code and not interactively, since I cannot see any interfacing with the existing image types? I've been using as follows: setenv autostart no bootm fdt fixups bootepapr 0 $bootm_fdtaddr Additionally these seems like the low level functionality needed if we want to move to the scriptable bootm were we decouple image loading from the actual boot mechanism. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/3] ppc: Report back the location we put the device tree if we dont boot
On Aug 6, 2008, at 3:33 AM, Wolfgang Denk wrote: Dear Bartek, in message [EMAIL PROTECTED] you wrote: The test you're referring to was introduced by commit 75fa002c47171b73fb4c1f2c2fe4d6391c136276 [new uImage] Respect autostart setting in linux bootm by Kumar -- he should be better able to explain the details. Thanks - and sorry for blaming you, I should have checked this myself first. It looks like that the autostart field has been added to the bootm_headers structure so that the arch-specific code can make decisions about booting without the need to call getenv(autostart). Instead, the autostart field is set based on the env. variable once, and passed to boot-related functions via a parameter (e.g., images in do_bootm_linux()). Again, this field has beed introduced by Kumar (f5614e7926863bf0225ec860d9b319741a9c4004, [new uImage] Add autostart flag to bootm_headers structure), who should be able to comment more. Indeed - but as mentioned before, this all makes no sense to me, because with the intended and documented use of the autostart variable the bootm command will not be called at all. Kumar, if I were to back out commit f5614e79 - what exactly would it break in your opinion? There is intent and what the old code did. My feeling is that 'autostart = no' means to load the images but not actually jump to the new image. The old code would load the kernel image and set 'filesize' and return (only if the image was of type IH_TYPE_STANDALONE). I think when sent 'f5614e7926863bf0225ec860d9b319741a9c4004' I didn't notice the IH_TYPE_STANDALONE aspect. We can revert the commit but it puts be back to square one w/o a solution to my problem. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] u-boot-1.1.4 MPC8548PC source plss ...
On Aug 6, 2008, at 8:52 AM, pugazh mahalingam wrote: Hi, I'm using MPC8548PC Type N card. where can I get the U-Boot code for this board. ? i cannot run the other configuration in this board. so can you please give the source code to MPC8548PC board. you should talk to the vendor of that board as nothing by that name is supported in the open source u-boot tree. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 2/2] add ability to disable ft_board_setup as part of bootm
if the environment variable 'no_ft_board_setup' is set we skip doing the ft_board_setup(). Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- lib_ppc/bootm.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c index d141fae..1fce037 100644 --- a/lib_ppc/bootm.c +++ b/lib_ppc/bootm.c @@ -193,7 +193,8 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[], } #ifdef CONFIG_OF_BOARD_SETUP /* Call the board-specific fixup routine */ - ft_board_setup(of_flat_tree, gd-bd); + if (!getenv(no_ft_board_setup)) + ft_board_setup(of_flat_tree, gd-bd); #endif } -- 1.5.5.1 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/2] Update linux bootm to support ePAPR client interface
the ePAPR spec has some subtle differences from the current device tree
based boot interface to the powerpc linux kernel. The powerpc linux kernel
currently ignores the differences that ePAPR specifies.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
lib_ppc/bootm.c | 33 +++--
1 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index 81803dd..d141fae 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -80,7 +80,8 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
ulong cmd_start, cmd_end, bootmap_base;
bd_t*kbd;
ulong ep = 0;
- void(*kernel)(bd_t *, ulong, ulong, ulong, ulong);
+ void(*kernel)(bd_t *, ulong r4, ulong r5, ulong r6,
+ ulong r7, ulong r8, ulong r9);
int ret;
ulong of_size = 0;
struct lmb *lmb = images-lmb;
@@ -166,8 +167,8 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
puts (Could not find kernel entry point!\n);
goto error;
}
- kernel = (void (*)(bd_t *, ulong, ulong, ulong, ulong))ep;
-
+ kernel = (void (*)(bd_t *, ulong, ulong, ulong,
+ ulong, ulong, ulong))ep;
/* find ramdisk */
ret = boot_get_ramdisk (argc, argv, images, IH_ARCH_PPC,
rd_data_start, rd_data_end);
@@ -284,14 +285,23 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
if (of_flat_tree) { /* device tree; boot new style */
/*
* Linux Kernel Parameters (passing device tree):
-* r3: pointer to the fdt, followed by the board info data
-* r4: physical pointer to the kernel itself
-* r5: NULL
-* r6: NULL
-* r7: NULL
+* r3: pointer to the fdt
+* r4: 0
+* r5: 0
+* r6: epapr magic
+* r7: size of IMA in bytes
+* r8: 0
+* r9: 0
*/
+#if defined(CONFIG_85xx) || defined(CONFIG_440)
+ #define EPAPR_MAGIC (0x45504150)
+#else
+ #define EPAPR_MAGIC (0x65504150)
+#endif
+
debug ( Booting using OF flat tree...\n);
- (*kernel) ((bd_t *)of_flat_tree, (ulong)kernel, 0, 0, 0);
+ (*kernel) ((bd_t *)of_flat_tree, 0, 0, EPAPR_MAGIC,
+ CFG_BOOTMAPSZ, 0, 0);
/* does not return */
} else
#endif
@@ -303,9 +313,12 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
* r5: initrd_end - unused if r4 is 0
* r6: Start of command line string
* r7: End of command line string
+* r8: 0
+* r9: 0
*/
debug ( Booting using board info...\n);
- (*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end);
+ (*kernel) (kbd, initrd_start, initrd_end,
+ cmd_start, cmd_end, 0, 0);
/* does not return */
}
return ;
--
1.5.5.1
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
here's a rough start at an outline for the bootm script based on
the code (I've only outlined the Linux/PPC boot case its seems the
most complicated). One of the first things we clearly need is a
imload command. Thoughts on the various disable_{interrupts, usb,
caches} ?
- k
Another rough start on an outline (only cmd_bootm.c, need to add
image.c information):
http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm
Goal is to identify the major pieces of the sequence, identify what
commands we have and what we need to make a scripted equivalent
sequence for (ultimately) each path through the sequence.
I added a few bullets about functionality I'd like to see the new
sequence to be capable of it.
one idea is having stages of bootm handled as sub commands:
bootm start args
bootm prep(disable interrupts, stop usb, disable caches)
bootm load_os (decompress OS image)
bootm load_fdt(relocates fdt to proper place, setup bootargs, initrd
prep, board setup?? [or do via fdt boardsetup command])
bootm load_initrd
bootm jump
bootm restore (undo anything prep did, reset state tracking)
And we keep state around so the next stage can run w/o a lot of
arguments and you have to execute these in order, and only once. But
you can intermix other commands between the stages.
We could also have some bootm query foo to expose the internal
state if that's useful. We could completely get rid of the various
env vars that impact bootm and just make them state variables
(verify, autostart, bootm_size, bootm_low, ...)
Also, bootm would be the sequence of:
bootm start args
bootm prep
bootm load_os
bootm load_fdt
bootm load_initrd
bootm jump
comments?
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] decrementer interrupt MPC4349E
On Aug 6, 2008, at 1:16 PM, Gerry Emon wrote: Can anyone out there help me. I am doing some new development using a MPC8349E (Hardware rev 3.1) and using an older version of u-boot (1.1.3). I require hooks to the get_timer() API to allow me to place timeout restrictions on areas of my code. I have worked my way through the code on to determine that the underlying timer is based off of the decrementer interrupt. I do not seem to be getting any interrupts and believe that I have everything configured correctly. I have time base counter is enabled and have enabled external interrupts bit-16 (EE) in the MSR. Is there something else I am missing? Did you set DEC? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH][FOR 1.3.4] 85xx: Don't move interrupt vector to low memory
On Aug 6, 2008, at 2:46 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: It's hit me before when I foolishly try to load something at address zero -- why do we put u-boot at the end of RAM, and put up with the relocation weirdness, if not to allow loading things at zero? We want to free as much memory as possible. But low RAM cannot be made available on all systems. Well, one reason might be to have identical code for all PPC systems ? It's already 85xx-specific code. Good point. Why don't we factor this out and make it common code for all PPC? Because the relocation is specific to the various interrupt types. Book-E will need different code for handing IVPR/IVORs than classic. Not only 6xx. Actually all PPC. No, not all PPC. Book-E exceptions are different. Maybe. But then, these can use exception vectors at low mem, too, right? They can, but it has to be setup. For me the chance to have common code (and identical behaviour) for all PowerPC processors is much more important that being able to use 16 kB additional memory on one specific family of processors. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
On Aug 6, 2008, at 2:41 PM, Wolfgang Denk wrote: In message 5E53E387-237D-480E- [EMAIL PROTECTED] you wrote: one idea is having stages of bootm handled as sub commands: bootm start args bootm prep(disable interrupts, stop usb, disable caches) --- Point of no return here --- bootm load_os (decompress OS image) bootm load_fdt(relocates fdt to proper place, setup bootargs, initrd prep, board setup?? [or do via fdt boardsetup command]) bootm load_initrd bootm jump bootm restore (undo anything prep did, reset state tracking) Note that you cannot recover / restore after starting to uncompress the image, because usually you will overwrite the exception vectors. Normally that is true.. however there are some situations that its feasible. For example if you are booting a kernel at a non-zero address. We do this on 85xx HW. Or if you are trying to boot a kernel on the second core of a dual core setup (at a non-zero address). Both of these cases we can 'bootm restore' out of. And we keep state around so the next stage can run w/o a lot of arguments and you have to execute these in order, and only once. But you can intermix other commands between the stages. Sounds like Fortran to me - let's have a big COMMON section ;-) I'm not sure if this leads to good design. I'm trying to reduce have A LOT of control logic in the script. There is a fair amount of state needed between the various stages. We could also have some bootm query foo to expose the internal state if that's useful. We could completely get rid of the various env vars that impact bootm and just make them state variables (verify, autostart, bootm_size, bootm_low, ...) I have to admit that I have no idea why bootm_size or bootm_low are needed. If we can drop these, all the better. We use them for booting at non-zero locations. verify and autostart must be kept as environment variables, because that's the way how the user can influence the boot behaviour. Even if you find a better way to implement this, they will be needed for backward compatibility. Ok. What did we decide 'autostart' means with regards to bootm? Also, bootm would be the sequence of: bootm start args bootm prep bootm load_os bootm load_fdt bootm load_initrd bootm jump I'm asking myself if that order is technically necessary. IMHO it should be possible as well to move the load_fdt step before load_os and eventually before prep, too. If you know the layout of memory than its not fully needed. The issue is knowing how big the uncompress kernel is. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
On Aug 6, 2008, at 2:55 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
here's a rough start at an outline for the bootm script based on
the code (I've only outlined the Linux/PPC boot case its seems
the most complicated). One of the first things we clearly need
is a imload command. Thoughts on the various
disable_{interrupts, usb, caches} ?
- k
Another rough start on an outline (only cmd_bootm.c, need to add
image.c information):
http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm
Goal is to identify the major pieces of the sequence, identify
what commands we have and what we need to make a scripted
equivalent sequence for (ultimately) each path through the
sequence.
I added a few bullets about functionality I'd like to see the new
sequence to be capable of it.
Thanks for updating the page.
one idea is having stages of bootm handled as sub commands:
bootm start args
bootm prep(disable interrupts, stop usb, disable caches)
bootm load_os (decompress OS image)
bootm load_fdt(relocates fdt to proper place, setup bootargs,
initrd prep, board setup?? [or do via fdt boardsetup command])
fdt boardsetup - absolutely!
bootm load_initrd
bootm jump
bootm restore (undo anything prep did, reset state tracking)
Ooo, that sounds hard. If we are only re-enabling interrupts/usb/
caches it probably is manageable, but my hackles.
This is a buyer-beware kinda of situation. Think about a case that we
are booting a kernel at a location of memory that NO hw (usb,
interrupts, etc) would be touching. In that case you an reasonable
'bootm restore'
And we keep state around so the next stage can run w/o a lot of
arguments and you have to execute these in order, and only once.
But you can intermix other commands between the stages.
We could also have some bootm query foo to expose the internal
state if that's useful. We could completely get rid of the
various env vars that impact bootm and just make them state
variables (verify, autostart, bootm_size, bootm_low, ...)
State is bad.
Aside: verify should be an image verify command, not a env variable
flag (see below). This is probably true of most of the current env
variables: the reason we need them is because we kept throwing stuff
into bootm and then controlling it with env variables rather than
having a sequence and controlling it with what commands are in the
sequence. (Part of my simplification argument...)
Also, bootm would be the sequence of:
bootm start args
bootm prep
bootm load_os
bootm load_fdt
bootm load_initrd
bootm jump
comments?
- k
I also was thinking we should invent a new major/minor command as
you outlined, but it didn't occur to me that bootm would be a good
major command. This is a good idea: a bare bootm addr (addr|-)
addr could be used for backward compatibility and bootm
subcmd for New Improved[tm] functionality.
Having said that, I was thinking and would advocate pushing
functionality out of bootm and into other commands, as appropriate.
As an example, bootm doesn't need to do *any* fdt stuff, the fdt
built-in has all the capability we need (or should).
except for locating the fdt at the right location and dealing w/initrd
(but that could possibly be fixed).
The same may be also true about load_os and load_initrd - they are
copy-with-(optional)-
decompression operations (we may need additional commands for these).
Philosophy: bootm should do only bootm stuff. It (probably) should
not do any image stuff (find/copy/decompress/verify). It (probably)
should not do any fdt stuff (board fixup, other?). Etc...
This DOES NOT WORK... sorry I'm trying to make progress on this and
I'm not getting suggestions on a solutions just gripes about what I'm
suggesting.
The problem with breaking things up is that you HAVE to disable
interrupts and USB before you can reasonable load the OS image. Are
we could to add a command for each prereq. How does a user know if
they need to disable_caches on their board or not?
Also there is logic in the bootm that knows how to layout the images
based on the constraints of memory. Let use an example (assume OS
image will be loaded at 0):
bootm 100 - fff0
we load to 0, the resulting size is 1234151 bytes. So we set
filesize to 0x12D4E7. Since the fdt is in flash we have to copy it
to memory.
So what address do we copy it to? 0x12D4E7? No because we have to be
8-byte aligned. So 0x12D4F0? No because we have to ensure space for
the kernel .bss. So we have to encode all that logic in the script?
That's just asking for pain.
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications
Re: [U-Boot-Users] [PATCH][FOR 1.3.4] 85xx: Don't move interrupt vector to low memory
On Aug 6, 2008, at 3:17 PM, Wolfgang Denk wrote: In message 9D199630-11FA-4028-8EE6- [EMAIL PROTECTED] you wrote: Good point. Why don't we factor this out and make it common code for all PPC? Because the relocation is specific to the various interrupt types. Book-E will need different code for handing IVPR/IVORs than classic. Umm... the exception code itself may be different, but does this imply that the code used to copy / relocate the exception handlers to low mem must be different, too? the copying bit should be do-able in generic code. 74xx_7xx/mpc512x/mpc5xx/mpc8xx/mpc8220/mpc824x/mpc83xx/mpc86xx: copy from [_start, _end_of_vectors] to 0x100 4xx/85xx: copy from [_start_of_vectors, _end_of_vectors] to 0x100 Maybe. But then, these can use exception vectors at low mem, too, right? They can, but it has to be setup. What is Linux doing? don't follow the question.. what is linux doing with what? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
On Aug 6, 2008, at 3:36 PM, Wolfgang Denk wrote: In message 6130E31C-5845-4DCF- [EMAIL PROTECTED] you wrote: Ooo, that sounds hard. If we are only re-enabling interrupts/usb/ caches it probably is manageable, but my hackles. This is a buyer-beware kinda of situation. Think about a case that we are booting a kernel at a location of memory that NO hw (usb, interrupts, etc) would be touching. In that case you an reasonable 'bootm restore' Our exerience is that a consisten user interface and behaviour is much more important that to actually offer all options that are technically possible. For the sake of mind of a clean user interface I vote not to spend efforts on implementing such a special behaviour (which is of limited value anyway - what is the big difference between a recovery and a reset?) Its not about recovery/reset... Philosophy: bootm should do only bootm stuff. It (probably) should not do any image stuff (find/copy/decompress/verify). It (probably) should not do any fdt stuff (board fixup, other?). Etc... This DOES NOT WORK... sorry I'm trying to make progress on this and I'm not getting suggestions on a solutions just gripes about what I'm suggesting. The problem with breaking things up is that you HAVE to disable interrupts and USB before you can reasonable load the OS image. Are we could to add a command for each prereq. How does a user know if they need to disable_caches on their board or not? I think the average user does not need to now this. He can just run the systemn-provided bootm command without caring if this is a monolithic pile of unreeadable code, or a wrapper function that sequentially calls out for a list of simple helper functions, or some sort of script (or list of commands stored in an environment variable) that get executed. But the developer gets the freedom to implement exactly the behaviour he wants by being able to redefine the steps he rund and their order. I understand.. but moving ALL the control logic that exists in bootm into a script language just seem like a bad idea to me. This means boots will be that much slower as we have to parse all this control logic in the shell. UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn Also there is logic in the bootm that knows how to layout the images based on the constraints of memory. Let use an example (assume OS image will be loaded at 0): bootm 100 - fff0 we load to 0, the resulting size is 1234151 bytes. So we set filesize to 0x12D4E7. Since the fdt is in flash we have to copy it to memory. Stop, this is not correct. filesize gets set when loading the (compressed) image. It contains the _file_ size, i. e. the sum of all included images plus headers etc. bootm does not touch filesize. in the method you guys seem to be arguing for we have to return the address the image was loaded at and the size. W/o this info I dont see how the next step can decide where to boot the .dtb or initrd. I was just 'filesize' just as part of my example. So what address do we copy it to? 0x12D4E7? No because we have to be 8-byte aligned. So 0x12D4F0? No because we have to ensure space for the kernel .bss. So we have to encode all that logic in the script? That's just asking for pain. Why cannot U-Boot just malloc() space for the fdt? Because the memory malloc() gives me isn't guaranteed to meet the set of constraints we have. (the memory can't be part of the OS image, has to be properly aligned, has to be within the BOOTMAP_SZ). - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH][FOR 1.3.4] 85xx: Don't move interrupt vector to low memory
On Aug 6, 2008, at 3:41 PM, Wolfgang Denk wrote: In message D5CA3AB9-3AE3-439C-A169- [EMAIL PROTECTED] you wrote: Book-E will need different code for handing IVPR/IVORs than classic. Umm... the exception code itself may be different, but does this imply that the code used to copy / relocate the exception handlers to low mem must be different, too? the copying bit should be do-able in generic code. 74xx_7xx/mpc512x/mpc5xx/mpc8xx/mpc8220/mpc824x/mpc83xx/mpc86xx: copy from [_start, _end_of_vectors] to 0x100 4xx/85xx: copy from [_start_of_vectors, _end_of_vectors] to 0x100 OK, that's what I exoected. So we should plan to factor out this part of code one day. Maybe. But then, these can use exception vectors at low mem, too, right? They can, but it has to be setup. What is Linux doing? don't follow the question.. what is linux doing with what? Where is Linux setting up exception vectors on these systems? they are at 0 for 6xx/8xx/40x systems. They can be anywhere on 85xx/ 44x (and we take advantage of this). - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
Stop, this is not correct. filesize gets set when loading the (compressed) image. It contains the _file_ size, i. e. the sum of all included images plus headers etc. bootm does not touch filesize. in the method you guys seem to be arguing for we have to return the address the image was loaded at and the size. W/o this info I dont No, we pass the load address as argument to the loader / uncompressor. Just like we are doing it now. see how the next step can decide where to boot the .dtb or initrd. I was just 'filesize' just as part of my example. Well, at the moment we don't do any such clever stuff eihter. We load the kernel low and the ramdisk high. That's all. Do we need more? Yes. bd_t for old style boot... no idea on non-ppc. Have you looked at the fdt handling code in lib_ppc/bootm.c: look at boot_get_fdt(), boot_relocate_fdt() and think about recoding that in a script. eeck! Why cannot U-Boot just malloc() space for the fdt? Because the memory malloc() gives me isn't guaranteed to meet the set of constraints we have. (the memory can't be part of the OS image, has to be properly aligned, has to be within the BOOTMAP_SZ). So load it high within the limits of BOOTMAP_SZ. Please read the README again - it explains the whole philosophy as it used to be implemented 8 years ago - plain simple and reliable: load the kernel low (because that's what the kernel needed), and the ramdisk high (within the limits of RAM size and, if defined, initrd_high). If you want to stick in the DTB here, then load it before the ramdisk, and the ramdisk below it. The DTB size is easy to get, me thinks. dtb size is NOT easy to get. It can change significantly between the raw dtb and after fdt boardsetup. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] simplify bootm command
On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: My current best thought is to create a new boot simple (boots? bootsm?) command that contains only the essence of bootm. I would then change the command bootm to do a hush script run of the env variable bootm (i.e. the command bootm would really just be run bootm). The env variable bootm would then have to be created with the complex (board/config appropriate) sequence that is currently hardcoded in the command bootm, with the last command being boots, of course. This would be selected by a new CONFIG_ configuration so that old boards would go on as is until or unless the maintainer chose to move forward. Hm... if we go to such efforts, we might even go one step farther and solve the problem in a more general way. One idea that has been spinning in my mind for some time is to make the run command to execute the content of an environment variable optional. Instead, we could try and handle environment variable names similar to command names, i. e. instead of typing run foo; run bar you could just write foo; bar (I woull probably still keep the run command around to allow for the implicit error handling as used in run foo bar without forcing the user to use the hush shell to get the equivalent foo bar). Then it's just a matter of defining the search order: if the variable name space gets searched before the command names, we could redefine all builtin commands. [Probbaly the search order (variables before or after builtin commands) can be even mad selectable using an environment variable :-) ]. A new builtin command would allow to stillr efer to the original builtin commands. With such an implementation, we could move the FDT handling into a command sequence stored in a bootm environment variable, and the last part of this variable would be builtin bootm to run the real (simplified) command. What do you think? While this is a cleaner implementation of what I've implemented w/ ft_env_setup() it still doesn't completely solve my problem. We'd need to have a command to deal with image loading separate from bootm since the 'fdt' processing that does occur today is in the middle of the bootm flow. bootm: 1. verify and uncompress kernel image 2. relocate fdt (if needed) 3. ft_board_setup() 4. verify and uncompress ramdisk 5. update initrd info in device tree 6. jump to kernel I don't see how we can accomplish the same steps w/o breaking bootm down into a set of builtin commands to handle the various steps and providing enough information between the steps to accomplish the next step. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] simplify bootm command
On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote: [snip] One idea that has been spinning in my mind for some time is to make the run command to execute the content of an environment variable optional. Instead, we could try and handle environment variable names similar to command names, i. e. instead of typing run foo; run bar you could just write foo; bar (I woull probably still keep the run command around to allow for the implicit error handling as used in run foo bar without forcing the user to use the hush shell to get the equivalent foo bar). [snip] With such an implementation, we could move the FDT handling into a command sequence stored in a bootm environment variable, and the last part of this variable would be builtin bootm to run the real (simplified) command. What do you think? While this is a cleaner implementation of what I've implemented w/ ft_env_setup() it still doesn't completely solve my problem. We'd need to have a command to deal with image loading separate from bootm since the 'fdt' processing that does occur today is in the middle of the bootm flow. bootm: 1. verify and uncompress kernel image 2. relocate fdt (if needed) 3. ft_board_setup() 4. verify and uncompress ramdisk 5. update initrd info in device tree 6. jump to kernel I don't see how we can accomplish the same steps w/o breaking bootm down into a set of builtin commands to handle the various steps and providing enough information between the steps to accomplish the next step. Yes, that is Wolfgang's (and my) proposal: rationalize the built-in bootm to do just #6. Steps 1-5 already exist as built-in commands or commands could be created almost trivially to invoke the existing code. The current bootm behavior would then be emulated by a bootm script chaining them together. All the different bootm behaviors would then be in the script (customizable by the user) rather than being hard-compiled into the actual bootm built-in command. Rather than using the C preprocessor (and deductions based on parameters) to select the appropriate bootm behavior, an appropriate script would be used (there would be quite a few possible scripts, depending on _which_ bootm behavior is needed for a specific board/config). (Despite just having dissed cpp bootm behavior generation, I'm thinking that we would want to use the cpp to generate a default script that would emulate the current bootm behavior.) If this is what Wolfgang was aiming I'm all for it. is it? I think we should start with a detailed 'script' to mimic existing bootm behavior to know what commands we need to add beyond the builtin change. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] simplify bootm command -- deprecated or removing functionality?
Can we drop any functionality from the current bootm? For example does powerpc still need to support bd_t based booting? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] outline of bootm script
here's a rough start at an outline for the bootm script based on the
code (I've only outlined the Linux/PPC boot case its seems the most
complicated). One of the first things we clearly need is a imload
command. Thoughts on the various disable_{interrupts, usb, caches} ?
- k
bootm script:
disable_interrupts /* sets an env with the state of
interrupts
before disabling */
#ifdef CONFIG_CMD_USB
disable_usb
#endif
#ifdef CONFIG_AMIGAONEG3SE
disable_caches
#endif
imload kernel_image
switch(on OS type from imload)
LINUX:
if (fdt)
fdt relocate to after kernel_image + padding
fdt fixups (board setup, etc)
if (ramdisk)
imload ramdisk
if (fdt)
fixup initrd info in fdt
bootm_linux
...
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] simplify bootm command -- deprecated or removing functionality?
On Aug 5, 2008, at 9:45 AM, Wolfgang Denk wrote:
In message
[EMAIL PROTECTED] you wrote:
Can we drop any functionality from the current bootm?
Any? You mean:
int bootm (...)
{
return 0;
}
:-)
if it were only so easy :)
For example does powerpc still need to support bd_t based booting?
Yes, of course we need this. There is lots of systems out there that
use pre-DT kernels and still want recent versions of U-Boot for
various reasons.
ok.
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] simplify bootm command
On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote: [snip] One idea that has been spinning in my mind for some time is to make the run command to execute the content of an environment variable optional. Instead, we could try and handle environment variable names similar to command names, i. e. instead of typing run foo; run bar you could just write foo; bar (I woull probably still keep the run command around to allow for the implicit error handling as used in run foo bar without forcing the user to use the hush shell to get the equivalent foo bar). [snip] With such an implementation, we could move the FDT handling into a command sequence stored in a bootm environment variable, and the last part of this variable would be builtin bootm to run the real (simplified) command. What do you think? While this is a cleaner implementation of what I've implemented w/ ft_env_setup() it still doesn't completely solve my problem. We'd need to have a command to deal with image loading separate from bootm since the 'fdt' processing that does occur today is in the middle of the bootm flow. bootm: 1. verify and uncompress kernel image 2. relocate fdt (if needed) 3. ft_board_setup() 4. verify and uncompress ramdisk 5. update initrd info in device tree 6. jump to kernel I don't see how we can accomplish the same steps w/o breaking bootm down into a set of builtin commands to handle the various steps and providing enough information between the steps to accomplish the next step. Yes, that is Wolfgang's (and my) proposal: rationalize the built-in bootm to do just #6. Steps 1-5 already exist as built-in commands or commands could be created almost trivially to invoke the existing code. The current bootm behavior would then be emulated by a bootm script chaining them together. All the different bootm behaviors would then be in the script (customizable by the user) rather than being hard-compiled into the actual bootm built-in command. As I look at this more and more I think trying to re-encode the control flow of the bootm command in a script is just insane. There are too many special cases we have to deal with that we'd just being moving from C code into the script. Unless there is some believed simplification I'm missing I don't think going through all this effort produces anything that is significantly better. My needs are meet with the simple ft_env_setup() call out. Beyond that trying to rework bootm for legacy images, CONFIG_FIT, booting w/ dts, boot w/o dts, linux, *bsd, vxworks, etc just seems like a lot of work w/o any real benefit. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] simplify bootm command
[snip] As I look at this more and more I think trying to re-encode the control flow of the bootm command in a script is just insane. There are too many special cases we have to deal with that we'd just being moving from C code into the script. My assumption is that a given board/config/user will likely be using exactly one of the n!/k!(n-k)! possibilities implemented in the current bootm (I don't know what n and k are, but n is pretty large and k is hard to determine :-O). I figure, in the worst case, a given user may want two or three possibilities. that might be true in a custom board port but for reference boards like we produce at FSL its difficult to know what a customer might want so we effective have the kitchen sink. By selecting from a (smallish) set of simple bootX scripts, I'm speculating that each script will not need conditional logic other than to bail out if an error occurs. I'm also suspicious that replacing bootm with a simplified bootm with a (single) bootm script isn't going to be workable (as you contend - script complexity)... the solution I would propose if that happens is to maintain bootm as is as a backwards compatible CONFIG_ option and create a new bootsimple (or some such) command that is what bootm would have been if we had hush scripting (and prescience[1]) a few years ago. which means I'll have to keep the old method around. Unless there is some believed simplification I'm missing I don't think going through all this effort produces anything that is significantly better. To make an omelet, you have to break some eggs. :-) I see Wolfgang illustrated the current complexity with a list of bootm hack^H^H^H^H customizations in a separate message. but I doubt we will be able to remove those as they should be dealing with the ARCH specific boot methods. My needs are meet with the simple ft_env_setup() call out. Beyond that trying to rework bootm for legacy images, CONFIG_FIT, booting w/dts, boot w/o dts, linux, *bsd, vxworks, etc just seems like a lot of work w/o any real benefit. That is the practical approach for now, but that is also how we got to here - incrementally adding complexity to bootm. Fair point but I have yet to see how the new approach is going to get rid of the old one. What's the point in adding code if we can't get rid of the old code? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH v2] fdt: add fdtcmd env var to allow post processing of device tree before boot
Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree after
ft_board_setup() and before the tree is handled to the kernel.
The idea is that users may want to add or manipulate nodes w/changing the
u-boot binary. The current point in the code we do this we have yet to
determine the final size and have yet to do the final fixup of the initrd
information.
If its desirable for the 'fdtcmd' support to have the proper initrd
information a bit of code reorder will be in order.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Moved 'fdt boardsetup' into the 'fdtcmd' environment by default thus removing
the
explicit ft_board_setup call and moving slightly towards the direction of having
things be a bit more script driven.
- k
common/env_common.c |3 +++
common/environment.c |3 +++
common/fdt_support.c | 21 +
include/fdt_support.h |1 +
lib_ppc/bootm.c |5 +
5 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/common/env_common.c b/common/env_common.c
index d51c211..7544cca 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -127,6 +127,9 @@ uchar default_environment[] = {
#if defined(CONFIG_PCI_BOOTDELAY) (CONFIG_PCI_BOOTDELAY 0)
pcidelay= MK_STR(CONFIG_PCI_BOOTDELAY)\0
#endif
+#ifdef CONFIG_OF_BOARD_SETUP
+ fdtcmd= fdt boardsetup \0
+#endif
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
diff --git a/common/environment.c b/common/environment.c
index 3b9914f..39ed545 100644
--- a/common/environment.c
+++ b/common/environment.c
@@ -174,6 +174,9 @@ env_t environment __PPCENV__ = {
#if defined(CONFIG_PCI_BOOTDELAY) (CONFIG_PCI_BOOTDELAY 0)
pcidelay= MK_STR(CONFIG_PCI_BOOTDELAY)\0
#endif
+#ifdef CONFIG_OF_BOARD_SETUP
+ fdtcmd= fdt boardsetup \0
+#endif
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 93b144e..25c42e4 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -30,6 +30,10 @@
#include fdt_support.h
#include exports.h
+#ifdef CFG_HUSH_PARSER
+#include hush.h
+#endif
+
/*
* Global data (for the gd-bd)
*/
@@ -529,3 +533,20 @@ void fdt_fixup_crypto_node(void *blob, int sec_rev)
fdt_strerror(err));
}
#endif /* defined(CONFIG_MPC83XX) || defined(CONFIG_MPC85xx) */
+
+int ft_env_setup(void *blob)
+{
+ int rcode = 0;
+
+ working_fdt = blob;
+
+#ifndef CFG_HUSH_PARSER
+ if (run_command (getenv (fdtcmd), 0) 0)
+ rcode = 1;
+#else
+ if (parse_string_outer (getenv (fdtcmd),
+ FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP) != 0)
+ rcode = 1;
+#endif
+ return rcode;
+}
diff --git a/include/fdt_support.h b/include/fdt_support.h
index a7c6326..f9ed5a4 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -67,6 +67,7 @@ void ft_board_setup(void *blob, bd_t *bd);
void ft_cpu_setup(void *blob, bd_t *bd);
void ft_pci_setup(void *blob, bd_t *bd);
#endif
+int ft_env_setup(void *blob);
#endif /* ifdef CONFIG_OF_LIBFDT */
#endif /* ifndef __FDT_SUPPORT_H */
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index a872d31..186e9b9 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -190,10 +190,7 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
fdt_error (/chosen node create failed);
goto error;
}
-#ifdef CONFIG_OF_BOARD_SETUP
- /* Call the board-specific fixup routine */
- ft_board_setup(of_flat_tree, gd-bd);
-#endif
+ ft_env_setup(of_flat_tree);
}
/* Fixup the fdt memreserve now that we know how big it is */
--
1.5.5.1
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 5, 2008, at 11:50 AM, Kumar Gala wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. The idea is that users may want to add or manipulate nodes w/ changing the u-boot binary. The current point in the code we do this we have yet to determine the final size and have yet to do the final fixup of the initrd information. If its desirable for the 'fdtcmd' support to have the proper initrd information a bit of code reorder will be in order. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Moved 'fdt boardsetup' into the 'fdtcmd' environment by default thus removing the explicit ft_board_setup call and moving slightly towards the direction of having things be a bit more script driven. One of my intents was that this would be a stop gap until we have the new script method worked out. Also the idea is that would be compatible with the usage we are talking about and we'd just expand the default settings of 'fdtcmd' as part of the new script bootm method. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [RFC][WIP] ePAPR boot and provide a mechanism to disable ft board setup
Is this something we'd be willing to put into mainline?
- k
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index a872d31..3ebddd3 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -192,7 +192,8 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
}
#ifdef CONFIG_OF_BOARD_SETUP
/* Call the board-specific fixup routine */
- ft_board_setup(of_flat_tree, gd-bd);
+ if (!getenv_yesno(disable_fdt_boardsetup))
+ ft_board_setup(of_flat_tree, gd-bd);
#endif
}
@@ -821,3 +822,67 @@ error:
return 1;
}
#endif
+
+/***/
+/* boote - boot ePAPR */
+/***/
+#if defined(CONFIG_CMD_BOOT_EPAPR)
+int do_boot_epapr (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ void (*kernel)(ulong r3, ulong r4, ulong r5, ulong r6,
+ ulong r7, ulong r8, ulong r9);
+ ulong kern, of_flat_tree, epapr_magic;
+
+ if (argc != 3) {
+printf (Usage:\n%s\n, cmdtp-usage);
+return 1;
+}
+
+ kern = simple_strtoul (argv[1], NULL, 16);
+ of_flat_tree = simple_strtoul (argv[2], NULL, 16);
+
+ if (kern 0x3) {
+printf (kernel address 0x%lx is not 4-byte aligned\n, kern);
+return 1;
+ }
+
+ if (of_flat_tree 0x7) {
+printf (Flat device tree address 0x%lx is not 8-byte
aligned\n, of_flat_tree);
+return 1;
+ }
+
+ if (!getenv_yesno (autostart))
+ return 0;
+
+ kernel = (void (*)(ulong, ulong, ulong, ulong,
+ ulong, ulong, ulong))kern;
+
+ /*
+* Linux Kernel Parameters (passing device tree):
+* r3: pointer to the fdt
+* r4: 0
+* r5: 0
+* r6: epapr magic
+* r7: 0
+* r8: 0
+* r9: 0
+*/
+#if defined(CONFIG_85xx) || defined(CONFIG_440)
+ epapr_magic = 0x45504150;
+#else
+ epapr_magic = 0x65504150;
+#endif
+
+ debug ( Booting using OF flat tree...\n);
+ (*kernel) (of_flat_tree, 0, 0, epapr_magic, 0, 0, 0);
+ /* does not return */
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ bootepapr, 3, 1, do_boot_epapr,
+ bootepapr - boot according to ePAPR client interface\n,
+ entry point device tree address\n
+);
+#endif
--
1.5.5.1
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree after ft_board_setup()
and before the tree is handled to the kernel.
The idea is that users may want to add or manipulate nodes w/changing the u-boot
binary. The current point in the code we do this we have yet to determine the
final size and have yet to do the final fixup of the initrd information.
If its desirable for the 'fdtcmd' support to have the proper initrd information
a bit of code reorder will be in order.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
common/fdt_support.c | 21 +
include/fdt_support.h |1 +
lib_ppc/bootm.c |1 +
3 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 93b144e..b1aa7df 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -30,6 +30,10 @@
#include fdt_support.h
#include exports.h
+#ifdef CFG_HUSH_PARSER
+#include hush.h
+#endif
+
/*
* Global data (for the gd-bd)
*/
@@ -529,3 +533,20 @@ void fdt_fixup_crypto_node(void *blob, int sec_rev)
fdt_strerror(err));
}
#endif /* defined(CONFIG_MPC83XX) || defined(CONFIG_MPC85xx) */
+
+int ft_env_setup(void *blob, bd_t *bd)
+{
+ int rcode = 0;
+
+ working_fdt = blob;
+
+#ifndef CFG_HUSH_PARSER
+ if (run_command (getenv (fdtcmd), 0) 0)
+ rcode = 1;
+#else
+ if (parse_string_outer (getenv (fdtcmd),
+ FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP) != 0)
+ rcode = 1;
+#endif
+ return rcode;
+}
diff --git a/include/fdt_support.h b/include/fdt_support.h
index a7c6326..a60b5f0 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -67,6 +67,7 @@ void ft_board_setup(void *blob, bd_t *bd);
void ft_cpu_setup(void *blob, bd_t *bd);
void ft_pci_setup(void *blob, bd_t *bd);
#endif
+int ft_env_setup(void *blob, bd_t *bd);
#endif /* ifdef CONFIG_OF_LIBFDT */
#endif /* ifndef __FDT_SUPPORT_H */
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index a872d31..d7a1236 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -194,6 +194,7 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
/* Call the board-specific fixup routine */
ft_board_setup(of_flat_tree, gd-bd);
#endif
+ ft_env_setup(of_flat_tree, gd-bd);
}
/* Fixup the fdt memreserve now that we know how big it is */
--
1.5.5.1
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? The situation is if we are fixing up or adding properties or nodes via the ft_board_setup() how do I go about modifying that before the device tree is handed to the kernel. An example would be if we start adding the i2c node via code in u-boot and after we have done that we want to add a frequency property at runtime w/o changing the u-boot code. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 85xx: Not enough room for program headers
Rafal,
Can you try the following patch and see if works for you (make sure the
resulting image actually boots the board). If so I'll fixup all the .lds
I changed to match.
diff --git a/board/freescale/mpc8555cds/u-boot.lds
b/board/freescale/mpc8555cds/u-boot.lds
index a18b3a7..e7fbe5d 100644
--- a/board/freescale/mpc8555cds/u-boot.lds
+++ b/board/freescale/mpc8555cds/u-boot.lds
@@ -23,6 +23,11 @@
OUTPUT_ARCH(powerpc)
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD ;
+}
+
SECTIONS
{
/* Read-only sections, merged into text segment: */
@@ -54,7 +59,7 @@ SECTIONS
*(.text)
*(.fixup)
*(.got1)
- }
+ } :text
_etext = .;
PROVIDE (etext = .);
.rodata:
@@ -63,7 +68,7 @@ SECTIONS
*(.rodata1)
*(.rodata.str1.4)
*(.eh_frame)
- }
+ } :text
.fini : { *(.fini)} =0
.ctors : { *(.ctors) }
.dtors : { *(.dtors) }
@@ -115,12 +120,12 @@ SECTIONS
.bootpg ADDR(.text) + 0x7f000 :
{
cpu/mpc85xx/start.o(.bootpg)
- } = 0x
+ } :text = 0x
.resetvec ADDR(.text) + 0x7fffc :
{
*(.resetvec)
- } = 0x
+ } :text = 0x
. = ADDR(.text) + 0x8;
@@ -131,7 +136,7 @@ SECTIONS
*(.dynbss)
*(.bss)
*(COMMON)
- }
+ } :NONE
. = ALIGN(4);
_end = . ;
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message Pine.LNX. [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? The situation is if we are fixing up or adding properties or nodes via the ft_board_setup() how do I go about modifying that before the device tree is handed to the kernel. An example would be if we start adding the i2c node via code in u- boot and after we have done that we want to add a frequency property at runtime w/o changing the u-boot code. - k My original way long ago initial cut didn't do the board and /chosen fixups as part of the bootm execution. My original intent was that we would run fdt chosen and fdt bd and whatever else was necessary before running bootm, including addressing Kumar's need. Unfortunately, it would have also broken backwards compatibility and so the concept was sacrificed for backwards compatibility. :-/ Is there a better way of doing this... perhaps have a flag that says if fdt chosen and/or fdt bd is run, don't re-run it as part of bootm? Maybe have an env variable that suppressed the calling of fdt chosen and fdt bd in bootm (nofdtfixup?)? Still ugly, but it would maintain backwards compatibility but also allow us finer grained control of when fdt chosen and fdt bd (add fdt cpu?) is run and allow our users to wedge additional fdt stuff in the boot sequence. Is that really any better than having the ability to execute an environment variable that has 'fdt' commands in it as part of bootm? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? The situation is if we are fixing up or adding properties or nodes via the ft_board_setup() how do I go about modifying that before the device tree is handed to the kernel. An example would be if we start adding the i2c node via code in u- boot and after we have done that we want to add a frequency property at runtime w/o changing the u-boot code. So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) This assumes I know the best location for the device tree before bootm which I'd argue isn't really true. Especially if my dtb is in flash. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:44 PM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? The situation is if we are fixing up or adding properties or nodes via the ft_board_setup() how do I go about modifying that before the device tree is handed to the kernel. An example would be if we start adding the i2c node via code in u- boot and after we have done that we want to add a frequency property at runtime w/o changing the u-boot code. - k My original way long ago initial cut didn't do the board and / chosen fixups as part of the bootm execution. My original intent was that we would run fdt chosen and fdt bd and whatever else was necessary before running bootm, including addressing Kumar's need. Unfortunately, it would have also broken backwards compatibility and so the concept was sacrificed for backwards compatibility. :-/ Is there a better way of doing this... perhaps have a flag that says if fdt chosen and/or fdt bd is run, don't re-run it as part of bootm? Maybe have an env variable that suppressed the calling of fdt chosen and fdt bd in bootm (nofdtfixup?)? Still ugly, but it would maintain backwards compatibility but also allow us finer grained control of when fdt chosen and fdt bd (add fdt cpu?) is run and allow our users to wedge additional fdt stuff in the boot sequence. Is that really any better than having the ability to execute an environment variable that has 'fdt' commands in it as part of bootm? - k I don't like it that bootm is calling out to all sorts of functions that could better be scripted. It complicates the bootm code (badly!), it prevents users from doing clever things (because it hard codes the calls and sequences of the calls to loosely related functions), and it violates the unix principle of doing only one thing and doing it well (bootm code is one big ugly awkward swissarmyknife[tm] tool). Best regards, gvb P.S. This battle was probably lost many years ago, but it still makes me feel better to pound the desk and shout. Oh-oh, people are looking... I think this was lost long ago. If we went with simple it would have just done the register setup and transfer and thats it. leaving it to other commands to do decompression of images, etc. Also we already have a number env vars that impact how bootm works. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:55 PM, Scott Wood wrote: Kumar Gala wrote: On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote: So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) This assumes I know the best location for the device tree before bootm which I'd argue isn't really true. Especially if my dtb is in flash. Why not? Wouldn't it be just another environment variable, like the load address for the kernel? Right now the fdt is placed at the first 4k page after the kernel is decompressed. I don't now where that address is. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 4:07 PM, Wolfgang Denk wrote: In message F388F9D5-B685-4DD8- [EMAIL PROTECTED] you wrote: So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) And exactly this has to be considered a bug in the current bootm implementation. Throwing out this design error would make more sense to me than adding another quirk. Ok. What do we think 'bootm' at its lowest level should do? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] simplify bootm command
If we really want to simplify what bootm does than I think we should remove ft_board_setup() from lib_ppc/bootm.c and expect any actually modification of the device tree to have already occurred. Is this something we'd really be willing to do? - k diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c index 81803dd..8a86d52 100644 --- a/lib_ppc/bootm.c +++ b/lib_ppc/bootm.c @@ -190,10 +190,6 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[], fdt_error (/chosen node create failed); goto error; } -#ifdef CONFIG_OF_BOARD_SETUP - /* Call the board-specific fixup routine */ - ft_board_setup(of_flat_tree, gd-bd); -#endif } /* Fixup the fdt memreserve now that we know how big it is */ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Report back the location we put the device tree if we dont boot
Its useful to know where the device tree is if we have set 'autostart'
to 'no. We come back to the prompt after a boot command and we can
than post process the device tree but we need to know where it was put
report this back via the env variable 'bootm_fdtaddr'.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
lib_ppc/bootm.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index 81803dd..a872d31 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -277,8 +277,17 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
#if defined(CFG_INIT_RAM_LOCK) !defined(CONFIG_E500)
unlock_ram_in_cache();
#endif
- if (!images-autostart)
+ if (!images-autostart) {
+#if defined(CONFIG_OF_LIBFDT)
+ if (of_flat_tree) {
+ char buf[32];
+
+ sprintf (buf, %llx, (u64)(u32)of_flat_tree);
+ setenv(bootm_fdtaddr, buf);
+ }
+#endif
return ;
+ }
#if defined(CONFIG_OF_LIBFDT)
if (of_flat_tree) { /* device tree; boot new style */
--
1.5.5.1
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: mailing list transfer
On Aug 1, 2008, at 10:17 AM, Wolfgang Denk wrote: Hello, I would like to get your general opinion about moving the u-boot-users mailing list away from SourceForge and host it on lists.denx.de instead. Yes! - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [UPDATED][PATCH v2] Fix compile warnings in dlmalloc
The origional code was using on odd reference to get to the first real element in av_[]. The first two elements of the array are not used for actual bins, but for house keeping. If we are more explicit about how use the first few elements we can get rid of the warnings: dlmalloc.c: In function 'malloc_extend_top': dlmalloc.c:1971: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:1999: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2029: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2031: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2042: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'malloc': dlmalloc.c:2245: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2245: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2253: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2258: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2263: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2318: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2327: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2329: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2344: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2356: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2360: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2362: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2363: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'free': dlmalloc.c:2431: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2444: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'realloc': dlmalloc.c:2594: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2599: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2604: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2605: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2637: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2646: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2647: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'calloc': dlmalloc.c:2896: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2897: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'malloc_trim': dlmalloc.c:2987: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2997: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3008: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3012: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3021: warning: dereferencing type-punned pointer will break strict-aliasing rules The logic of how this code came to be is: bin_at(0) = (char*)(av_[2]) - 2*SIZE_SZ SIZE_SZ is the size of pointer, and av_ is arry of pointers so: bin_at(0) = (av_[0]) Going from there to bin_at(0)-fd or bin_at(0)-size should be straight forward. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Updated against lastest head, added a bit more commit info about the logic of the change. common/dlmalloc.c | 21 +++-- 1 files changed, 11 insertions(+), 10 deletions(-) diff --git a/common/dlmalloc.c b/common/dlmalloc.c index c51351e..4a18562 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -1457,7 +1457,7 @@ typedef struct malloc_chunk* mbinptr; indexing, maintain locality, and avoid some initialization tests. */ -#define top(bin_at(0)-fd) /* The topmost chunk */ +#define top(av_[2]) /* The topmost chunk */ #define last_remainder (bin_at(1)) /* remainder from last split */ @@ -1552,13 +1552,14 @@ void malloc_bin_reloc (void) #define BINBLOCKWIDTH 4 /* bins per block */ -#define binblocks (bin_at(0
[U-Boot-Users] [PATCH] mpc85xx: Update linker scripts for Freescale boards
* Move to using absolute addressing always. Makes the scripts a bit more
portable and common
* Moved .bss after the end of the image. These allows us to have more
room in the resulting binary image for code and data.
* Removed .text object files that aren't really needed
* Added drivers/bios_emulator/atibios.o so the files are common since we
do run ATI video cards on some boards
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
board/freescale/mpc8540ads/u-boot.lds | 35
board/freescale/mpc8541cds/u-boot.lds | 36 +++--
board/freescale/mpc8544ds/u-boot.lds | 33 ++
board/freescale/mpc8548cds/u-boot.lds | 35 +++-
board/freescale/mpc8555cds/u-boot.lds | 36 +++--
board/freescale/mpc8560ads/u-boot.lds | 40 +---
board/freescale/mpc8568mds/u-boot.lds | 38 +++---
7 files changed, 100 insertions(+), 153 deletions(-)
diff --git a/board/freescale/mpc8540ads/u-boot.lds
b/board/freescale/mpc8540ads/u-boot.lds
index f200810..dd7ec5d 100644
--- a/board/freescale/mpc8540ads/u-boot.lds
+++ b/board/freescale/mpc8540ads/u-boot.lds
@@ -2,6 +2,8 @@
* (C) Copyright 2002,2003, Motorola,Inc.
* Xianghua Xiao, [EMAIL PROTECTED]
*
+ * Copyright 2008 Freescale Semiconductor, Inc.
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -26,16 +28,6 @@ OUTPUT_ARCH(powerpc)
__DYNAMIC = 0;*/
SECTIONS
{
- .resetvec 0xFFFC :
- {
-*(.resetvec)
- } = 0x
-
- .bootpg 0xF000 :
- {
-cpu/mpc85xx/start.o(.bootpg)
- } = 0x
-
/* Read-only sections, merged into text segment: */
. = + SIZEOF_HEADERS;
.interp : { *(.interp) }
@@ -63,16 +55,7 @@ SECTIONS
.text :
{
cpu/mpc85xx/start.o(.text)
-cpu/mpc85xx/traps.o (.text)
-cpu/mpc85xx/interrupts.o (.text)
-cpu/mpc85xx/cpu_init.o (.text)
-cpu/mpc85xx/cpu.o (.text)
-cpu/mpc85xx/speed.o (.text)
-cpu/mpc85xx/pci.o (.text)
-common/dlmalloc.o (.text)
-lib_generic/crc32.o (.text)
-lib_ppc/extable.o (.text)
-lib_generic/zlib.o (.text)
+drivers/bios_emulator/atibios.o (.text)
*(.text)
*(.fixup)
*(.got1)
@@ -134,6 +117,18 @@ SECTIONS
. = ALIGN(256);
__init_end = .;
+ .bootpg ADDR(.text) + 0x7f000 :
+ {
+cpu/mpc85xx/start.o(.bootpg)
+ } = 0x
+
+ .resetvec ADDR(.text) + 0x7fffc :
+ {
+*(.resetvec)
+ } = 0x
+
+ . = ADDR(.text) + 0x8;
+
__bss_start = .;
.bss (NOLOAD) :
{
diff --git a/board/freescale/mpc8541cds/u-boot.lds
b/board/freescale/mpc8541cds/u-boot.lds
index 5f4dcf0..9fe1a28 100644
--- a/board/freescale/mpc8541cds/u-boot.lds
+++ b/board/freescale/mpc8541cds/u-boot.lds
@@ -1,5 +1,5 @@
/*
- * Copyright 2004 Freescale Semiconductor.
+ * Copyright 2004, 2008 Freescale Semiconductor.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -25,16 +25,6 @@ OUTPUT_ARCH(powerpc)
__DYNAMIC = 0;*/
SECTIONS
{
- .resetvec 0xFFFC :
- {
-*(.resetvec)
- } = 0x
-
- .bootpg 0xF000 :
- {
-cpu/mpc85xx/start.o(.bootpg)
- } = 0x
-
/* Read-only sections, merged into text segment: */
. = + SIZEOF_HEADERS;
.interp : { *(.interp) }
@@ -62,17 +52,7 @@ SECTIONS
.text :
{
cpu/mpc85xx/start.o(.text)
-cpu/mpc85xx/traps.o (.text)
-cpu/mpc85xx/interrupts.o (.text)
-cpu/mpc85xx/cpu_init.o (.text)
-cpu/mpc85xx/cpu.o (.text)
-drivers/net/tsec.o (.text)
-cpu/mpc85xx/speed.o (.text)
-cpu/mpc85xx/pci.o (.text)
-common/dlmalloc.o (.text)
-lib_generic/crc32.o (.text)
-lib_ppc/extable.o (.text)
-lib_generic/zlib.o (.text)
+drivers/bios_emulator/atibios.o (.text)
*(.text)
*(.fixup)
*(.got1)
@@ -134,6 +114,18 @@ SECTIONS
. = ALIGN(256);
__init_end = .;
+ .bootpg ADDR(.text) + 0x7f000 :
+ {
+cpu/mpc85xx/start.o(.bootpg)
+ } = 0x
+
+ .resetvec ADDR(.text) + 0x7fffc :
+ {
+*(.resetvec)
+ } = 0x
+
+ . = ADDR(.text) + 0x8;
+
__bss_start = .;
.bss (NOLOAD) :
{
diff --git a/board/freescale/mpc8544ds/u-boot.lds
b/board/freescale/mpc8544ds/u-boot.lds
index c66c69f..fec8ea3 100644
--- a/board/freescale/mpc8544ds/u-boot.lds
+++ b/board/freescale/mpc8544ds/u-boot.lds
@@ -1,5 +1,5 @@
/*
- * Copyright 2007 Freescale Semiconductor, Inc.
+ * Copyright 2007-2008 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -25,16 +25,6 @@ OUTPUT_ARCH(powerpc)
__DYNAMIC = 0;*/
SECTIONS
{
- .resetvec 0xFFFC :
- {
-*(.resetvec)
- } = 0x
-
- .bootpg 0xF000 :
- {
-cpu/mpc85xx/start.o(.bootpg)
- } = 0x
-
/* Read-only sections, merged into text segment: */
. = + SIZEOF_HEADERS;
.interp : { *(.interp
Re: [U-Boot-Users] [PATCH] mpc85xx: Update linker scripts for Freescale boards
On Jul 30, 2008, at 11:07 AM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED]
you wrote:
.text :
{
cpu/mpc85xx/start.o (.text)
-cpu/mpc85xx/traps.o (.text)
-cpu/mpc85xx/interrupts.o (.text)
-cpu/mpc85xx/cpu_init.o (.text)
-cpu/mpc85xx/cpu.o (.text)
-cpu/mpc85xx/speed.o (.text)
-cpu/mpc85xx/pci.o (.text)
-common/dlmalloc.o (.text)
-lib_generic/crc32.o (.text)
-lib_ppc/extable.o (.text)
-lib_generic/zlib.o (.text)
+drivers/bios_emulator/atibios.o (.text)
*(.text)
When you exclude all the other objects here, then why do you have to
include atibios.o ?
I haven't figured that out yet. I know my boot fails if I dont.
Guess I should go figure that out... I was hoping to blissfully ignore
this ;)
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH v2] mpc85xx: Update linker scripts for Freescale boards
* Move to using absolute addressing always. Makes the scripts a bit more
portable and common
* Moved .bss after the end of the image. These allows us to have more
room in the resulting binary image for code and data.
* Removed .text object files that aren't really needed
* Make sure _end is 4-byte aligned as the .bss init code expects this.
(Its possible that the end of .bss isn't 4-byte aligned)
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
* fixed the issue with the ATI emu code by ensuring _end is 4-byte aligned.
- k
board/freescale/mpc8540ads/u-boot.lds | 37
board/freescale/mpc8541cds/u-boot.lds | 38 +++--
board/freescale/mpc8544ds/u-boot.lds | 37 +++-
board/freescale/mpc8548cds/u-boot.lds | 37 +++-
board/freescale/mpc8555cds/u-boot.lds | 38 +++--
board/freescale/mpc8560ads/u-boot.lds | 42 +---
board/freescale/mpc8568mds/u-boot.lds | 40 +++---
7 files changed, 108 insertions(+), 161 deletions(-)
diff --git a/board/freescale/mpc8540ads/u-boot.lds
b/board/freescale/mpc8540ads/u-boot.lds
index f200810..0e4f5a2 100644
--- a/board/freescale/mpc8540ads/u-boot.lds
+++ b/board/freescale/mpc8540ads/u-boot.lds
@@ -2,6 +2,8 @@
* (C) Copyright 2002,2003, Motorola,Inc.
* Xianghua Xiao, [EMAIL PROTECTED]
*
+ * Copyright 2008 Freescale Semiconductor, Inc.
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -26,16 +28,6 @@ OUTPUT_ARCH(powerpc)
__DYNAMIC = 0;*/
SECTIONS
{
- .resetvec 0xFFFC :
- {
-*(.resetvec)
- } = 0x
-
- .bootpg 0xF000 :
- {
-cpu/mpc85xx/start.o(.bootpg)
- } = 0x
-
/* Read-only sections, merged into text segment: */
. = + SIZEOF_HEADERS;
.interp : { *(.interp) }
@@ -62,17 +54,6 @@ SECTIONS
.plt : { *(.plt) }
.text :
{
-cpu/mpc85xx/start.o(.text)
-cpu/mpc85xx/traps.o (.text)
-cpu/mpc85xx/interrupts.o (.text)
-cpu/mpc85xx/cpu_init.o (.text)
-cpu/mpc85xx/cpu.o (.text)
-cpu/mpc85xx/speed.o (.text)
-cpu/mpc85xx/pci.o (.text)
-common/dlmalloc.o (.text)
-lib_generic/crc32.o (.text)
-lib_ppc/extable.o (.text)
-lib_generic/zlib.o (.text)
*(.text)
*(.fixup)
*(.got1)
@@ -134,6 +115,18 @@ SECTIONS
. = ALIGN(256);
__init_end = .;
+ .bootpg ADDR(.text) + 0x7f000 :
+ {
+cpu/mpc85xx/start.o(.bootpg)
+ } = 0x
+
+ .resetvec ADDR(.text) + 0x7fffc :
+ {
+*(.resetvec)
+ } = 0x
+
+ . = ADDR(.text) + 0x8;
+
__bss_start = .;
.bss (NOLOAD) :
{
@@ -142,6 +135,8 @@ SECTIONS
*(.bss)
*(COMMON)
}
+
+ . = ALIGN(4);
_end = . ;
PROVIDE (end = .);
}
diff --git a/board/freescale/mpc8541cds/u-boot.lds
b/board/freescale/mpc8541cds/u-boot.lds
index 5f4dcf0..1c583de 100644
--- a/board/freescale/mpc8541cds/u-boot.lds
+++ b/board/freescale/mpc8541cds/u-boot.lds
@@ -1,5 +1,5 @@
/*
- * Copyright 2004 Freescale Semiconductor.
+ * Copyright 2004, 2008 Freescale Semiconductor.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -25,16 +25,6 @@ OUTPUT_ARCH(powerpc)
__DYNAMIC = 0;*/
SECTIONS
{
- .resetvec 0xFFFC :
- {
-*(.resetvec)
- } = 0x
-
- .bootpg 0xF000 :
- {
-cpu/mpc85xx/start.o(.bootpg)
- } = 0x
-
/* Read-only sections, merged into text segment: */
. = + SIZEOF_HEADERS;
.interp : { *(.interp) }
@@ -61,18 +51,6 @@ SECTIONS
.plt : { *(.plt) }
.text :
{
-cpu/mpc85xx/start.o(.text)
-cpu/mpc85xx/traps.o (.text)
-cpu/mpc85xx/interrupts.o (.text)
-cpu/mpc85xx/cpu_init.o (.text)
-cpu/mpc85xx/cpu.o (.text)
-drivers/net/tsec.o (.text)
-cpu/mpc85xx/speed.o (.text)
-cpu/mpc85xx/pci.o (.text)
-common/dlmalloc.o (.text)
-lib_generic/crc32.o (.text)
-lib_ppc/extable.o (.text)
-lib_generic/zlib.o (.text)
*(.text)
*(.fixup)
*(.got1)
@@ -134,6 +112,18 @@ SECTIONS
. = ALIGN(256);
__init_end = .;
+ .bootpg ADDR(.text) + 0x7f000 :
+ {
+cpu/mpc85xx/start.o(.bootpg)
+ } = 0x
+
+ .resetvec ADDR(.text) + 0x7fffc :
+ {
+*(.resetvec)
+ } = 0x
+
+ . = ADDR(.text) + 0x8;
+
__bss_start = .;
.bss (NOLOAD) :
{
@@ -142,6 +132,8 @@ SECTIONS
*(.bss)
*(COMMON)
}
+
+ . = ALIGN(4);
_end = . ;
PROVIDE (end = .);
}
diff --git a/board/freescale/mpc8544ds/u-boot.lds
b/board/freescale/mpc8544ds/u-boot.lds
index c66c69f..500e647 100644
--- a/board/freescale/mpc8544ds/u-boot.lds
+++ b/board/freescale/mpc8544ds/u-boot.lds
@@ -1,5 +1,5 @@
/*
- * Copyright 2007 Freescale Semiconductor, Inc.
+ * Copyright 2007-2008 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -25,16 +25,6 @@ OUTPUT_ARCH(powerpc
Re: [U-Boot-Users] [PATCH] mpc85xx: Update linker scripts for Freescale boards
On Jul 30, 2008, at 11:07 AM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED]
you wrote:
.text :
{
cpu/mpc85xx/start.o (.text)
-cpu/mpc85xx/traps.o (.text)
-cpu/mpc85xx/interrupts.o (.text)
-cpu/mpc85xx/cpu_init.o (.text)
-cpu/mpc85xx/cpu.o (.text)
-cpu/mpc85xx/speed.o (.text)
-cpu/mpc85xx/pci.o (.text)
-common/dlmalloc.o (.text)
-lib_generic/crc32.o (.text)
-lib_ppc/extable.o (.text)
-lib_generic/zlib.o (.text)
+drivers/bios_emulator/atibios.o (.text)
*(.text)
When you exclude all the other objects here, then why do you have to
include atibios.o ?
Ok, the issue is that the atibios/x86 emu was causing _end not to be 4-
byte aligned and by putting in earlier it would get aligned for us.
I've posted a new patch that adds a proper ALIGN for _end and dropped
the explicit listing of atibios.o and start.o since they aren't needed.
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] moving bss outside of the image?
Is there any concern with moving .bss outside of the image? On 85xx
the images have historically been a fixed size (512k) and the .bss has
always lived inside of that region. We are now getting to a point
that .text + .data + .bss exceeds 512k. Its easy enough to move .bss
right pass the 512k boundary and wanted to see if anyone can think of
a reason not to do this.
Also, any cute ways of doing this in the linker script?
Right now if the TEXT_BASE is 0xeff8 I'm doing:
. = ADDR(.text) + 0x8;
__bss_start = .;
.bss (NOLOAD) :
{
*(.sbss) *(.scommon)
*(.dynbss)
*(.bss)
*(COMMON)
}
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] get_timer on ppc and bugs related to calling it (fsl_i2c)
In debugging moving the bss outside of the image on 85xx I run into in issue with the SPD code using fsl_i2c before we are running in ram and setup the BSS. It looks like i2c_wait4bus() [in fsl_i2c.c] calls get_timer(). get_timer implemented in lib_ppc/interrupts.c and uses a global timestamp that exists in the BSS. This seems pretty bad in that we have been just getting a bogus value for timestamp out of flash. Luckily we don't write timestamp until interrupts are enabled and at that point we've relocated to memory. However it seems like fsl_i2c.c should NOT be using get_timer(). Is there another global interface to get relative time that we can just use time base for? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] get_timer on ppc and bugs related to calling it (fsl_i2c)
On Jul 29, 2008, at 9:48 AM, Kumar Gala wrote: In debugging moving the bss outside of the image on 85xx I run into in issue with the SPD code using fsl_i2c before we are running in ram and setup the BSS. It looks like i2c_wait4bus() [in fsl_i2c.c] calls get_timer(). get_timer implemented in lib_ppc/interrupts.c and uses a global timestamp that exists in the BSS. This seems pretty bad in that we have been just getting a bogus value for timestamp out of flash. Luckily we don't write timestamp until interrupts are enabled and at that point we've relocated to memory. However it seems like fsl_i2c.c should NOT be using get_timer(). Is there another global interface to get relative time that we can just use time base for? - k Ok, I've got a patch that fixes fsl_i2c.c to use get_ticks and usec2ticks. I'll be posting it shortly. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH][FOR 1.3.4] fsl_i2c: Use timebase timer functions instead of get_timer()
The current implementation of get_timer() is only really useful after we
have relocated u-boot to memory. The i2c code is used before that as part
of the SPD DDR setup.
We actually have a bug when using the get_timer() code before relocation
because the .bss hasn't been setup and thus we could be reading/writing
a random location (probably in flash).
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
This is a fix for 1.3.4.
- k
drivers/i2c/fsl_i2c.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 9f2c1ec..c3e99c7 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -168,12 +168,11 @@ i2c_init(int speed, int slaveadd)
static __inline__ int
i2c_wait4bus(void)
{
- ulong timeval = get_timer(0);
+ unsigned long long timeval = get_ticks();
while (readb(i2c_dev[i2c_bus_num]-sr) I2C_SR_MBB) {
- if (get_timer(timeval) I2C_TIMEOUT) {
+ if ((get_ticks() - timeval) usec2ticks(I2C_TIMEOUT))
return -1;
- }
}
return 0;
@@ -183,7 +182,7 @@ static __inline__ int
i2c_wait(int write)
{
u32 csr;
- ulong timeval = get_timer(0);
+ unsigned long long timeval = get_ticks();
do {
csr = readb(i2c_dev[i2c_bus_num]-sr);
@@ -208,7 +207,7 @@ i2c_wait(int write)
}
return 0;
- } while (get_timer (timeval) I2C_TIMEOUT);
+ } while ((get_ticks() - timeval) usec2ticks(I2C_TIMEOUT));
debug(i2c_wait: timed out\n);
return -1;
--
1.5.5.1
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH][FOR 1.3.4] Fix compile warnings in dlmalloc
The origional code was using on odd reference to get to the first real element in av_[]. The first two elements of the array are not used for actual bins, but for house keeping. If we are more explicit about how use the first few elements we can get rid of the warnings: dlmalloc.c: In function 'malloc_extend_top': dlmalloc.c:1971: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:1999: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2029: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2031: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2042: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'malloc': dlmalloc.c:2245: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2245: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2253: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2258: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2263: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2318: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2327: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2329: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2344: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2356: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2360: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2362: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2363: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'free': dlmalloc.c:2431: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2444: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'realloc': dlmalloc.c:2594: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2599: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2604: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2605: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2637: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2646: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2647: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'calloc': dlmalloc.c:2896: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2897: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'malloc_trim': dlmalloc.c:2987: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2997: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3008: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3012: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3021: warning: dereferencing type-punned pointer will break strict-aliasing rules Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- common/dlmalloc.c | 21 +++-- 1 files changed, 11 insertions(+), 10 deletions(-) diff --git a/common/dlmalloc.c b/common/dlmalloc.c index c51351e..4a18562 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -1457,7 +1457,7 @@ typedef struct malloc_chunk* mbinptr; indexing, maintain locality, and avoid some initialization tests. */ -#define top(bin_at(0)-fd) /* The topmost chunk */ +#define top(av_[2]) /* The topmost chunk */ #define last_remainder (bin_at(1)) /* remainder from last split */ @@ -1552,13 +1552,14 @@ void malloc_bin_reloc (void) #define BINBLOCKWIDTH 4 /* bins per block */ -#define binblocks (bin_at(0)-size) /* bitvector of nonempty blocks */ +#define binblocks_r ((INTERNAL_SIZE_T)av_[1]) /* bitvector of nonempty blocks */ +#define binblocks_w (av_[1]) /* bin-block macros */ #define idx2binblock(ix)((unsigned)1 (ix / BINBLOCKWIDTH)) -#define mark_binblock(ii) (binblocks |= idx2binblock(ii)) -#define clear_binblock(ii) (binblocks
Re: [U-Boot-Users] moving bss outside of the image?
On Jul 29, 2008, at 4:25 PM, Wolfgang Denk wrote: In message 2A2FDF2A-7B9D-496C-960C- [EMAIL PROTECTED] you wrote: Is there any concern with moving .bss outside of the image? On 85xx the images have historically been a fixed size (512k) and the .bss has always lived inside of that region. We are now getting to a point that .text + .data + .bss exceeds 512k. Its easy enough to move .bss right pass the 512k boundary and wanted to see if anyone can think of a reason not to do this. You have to make sure that the memory map is still OK in the relocated system, taking into account for config options like pRAM, shared log buffer, frame buffer, ... Ok. I think that all works out ok because _end is after .bss. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] using a flat device tree to drive u-boot config
One topic that come up during OLS in discussions and u-boot BOF was the idea of driving u-boot configuration from a device tree instead of from config.h. I was wondering if anyone has actually looked at doing this. One question I have is how does (or should) u-boot identify where to find the device tree. I think the idea would be that this area could be easily reflashed with a new blob to get a new configuration. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Jul 28, 2008, at 12:40 PM, Grant Likely wrote: On Mon, Jul 28, 2008 at 10:07:49AM -0500, Kumar Gala wrote: One topic that come up during OLS in discussions and u-boot BOF was the idea of driving u-boot configuration from a device tree instead of from config.h. I was wondering if anyone has actually looked at doing this. One question I have is how does (or should) u-boot identify where to find the device tree. I think the idea would be that this area could be easily reflashed with a new blob to get a new configuration. In principle I like the idea of having configuration retrieved from the device tree blob, but the idea of reflashing the blob in the context of u-boot scares me. In particular, if u-boot depends too much on the presence of the blob, then it becomes a method of bricking a board if users are able/expected to reflash the blob. I dont see reflashing the blob as any different than reflashing u-boot itself w/respect to bricking a board. But I agree, in general I would hope u-boot would be able to still boot w/o the device tree information (might be crippled, but you could recover). - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Jul 28, 2008, at 1:13 PM, Wolfgang Grandegger wrote: Kumar Gala wrote: One topic that come up during OLS in discussions and u-boot BOF was the idea of driving u-boot configuration from a device tree instead of from config.h. I was wondering if anyone has actually looked at doing this. Last year I brought up the topic twice: http://sourceforge.net/mailarchive/message.php?msg_name=46F384E6.5030603%40grandegger.com One question I have is how does (or should) u-boot identify where to find the device tree. I think the idea would be that this area could be easily reflashed with a new blob to get a new configuration. Yep, it's even feasible to flash more than one blob and select one somehow in the early boot phase. Our main interest in using FDT for U-Boot is to make it dynamically configurable having just one image for various variants of the hardware. Replacing config.h completely seems overkill to me (and will not even be possible). Agreed. I'm not suggesting replacing config.h, but removing bits and pieces of it. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] HELP, trying to remove complier warnings
On Jul 10, 2008, at 1:43 PM, Scott Wood wrote: Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Try adding -fno-strict-aliasing No, we don't want to hush up compiler warnings, we want to fix the problems instead. It's not silencing a warning (if it were, it'd be a -W flag); it's disabling an incompatible optimization. Did we come to any resolution on this? I'm with Scott in that trying to re-write the code isn't worth the pain and its reasonable to disable the optimization until someone is willing to update to a newer dlmalloc which might not have the issue. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Fix some more printf() format problems.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
common/cmd_mp.c |2 +-
cpu/mpc85xx/mp.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/cmd_mp.c b/common/cmd_mp.c
index 26a57c5..59d0d15 100644
--- a/common/cmd_mp.c
+++ b/common/cmd_mp.c
@@ -35,7 +35,7 @@ cpu_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
cpuid = simple_strtoul(argv[1], NULL, 10);
if (cpuid = CONFIG_NR_CPUS) {
- printf (Core num: %d is out of range[0..%d]\n,
+ printf (Core num: %ld is out of range[0..%d]\n,
cpuid, CONFIG_NR_CPUS - 1);
return 1;
}
diff --git a/cpu/mpc85xx/mp.c b/cpu/mpc85xx/mp.c
index a527cf3..75ceba9 100644
--- a/cpu/mpc85xx/mp.c
+++ b/cpu/mpc85xx/mp.c
@@ -50,12 +50,12 @@ int cpu_status(int nr)
if (nr == id) {
table = (u32 *)get_spin_addr();
- printf(table base @ 0x%08x\n, table);
+ printf(table base @ 0x%08x\n, (u32)table);
} else {
table = (u32 *)get_spin_addr() + nr * NUM_BOOT_ENTRY;
printf(Running on cpu %d\n, id);
printf(\n);
- printf(table @ 0x%08x:\n, table);
+ printf(table @ 0x%08x:\n, (u32)table);
printf( addr - 0x%08x\n, table[BOOT_ENTRY_ADDR_LOWER]);
printf( pir - 0x%08x\n, table[BOOT_ENTRY_PIR]);
printf( r3 - 0x%08x\n, table[BOOT_ENTRY_R3_LOWER]);
--
1.5.5.1
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Fix some more printf() format problems.
On Jul 14, 2008, at 10:09 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 09:42 Mon 14 Jul , Kumar Gala wrote:
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
common/cmd_mp.c |2 +-
cpu/mpc85xx/mp.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/cmd_mp.c b/common/cmd_mp.c
index 26a57c5..59d0d15 100644
--- a/common/cmd_mp.c
+++ b/common/cmd_mp.c
@@ -35,7 +35,7 @@ cpu_cmd(cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
cpuid = simple_strtoul(argv[1], NULL, 10);
if (cpuid = CONFIG_NR_CPUS) {
-printf (Core num: %d is out of range[0..%d]\n,
+printf (Core num: %ld is out of range[0..%d]\n,
is it not %lu? cpuid is a unsigned long.
probably.
cpuid, CONFIG_NR_CPUS - 1);
return 1;
}
diff --git a/cpu/mpc85xx/mp.c b/cpu/mpc85xx/mp.c
index a527cf3..75ceba9 100644
--- a/cpu/mpc85xx/mp.c
+++ b/cpu/mpc85xx/mp.c
@@ -50,12 +50,12 @@ int cpu_status(int nr)
if (nr == id) {
table = (u32 *)get_spin_addr();
-printf(table base @ 0x%08x\n, table);
+printf(table base @ 0x%08x\n, (u32)table);
why not use %p? it's a pointer.
do we support %p in u-boot?
- k
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH v2] Fix some more printf() format problems.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
updated based on comments from Jean.
- k
common/cmd_mp.c |2 +-
cpu/mpc85xx/mp.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/cmd_mp.c b/common/cmd_mp.c
index 26a57c5..b2a397c 100644
--- a/common/cmd_mp.c
+++ b/common/cmd_mp.c
@@ -35,7 +35,7 @@ cpu_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
cpuid = simple_strtoul(argv[1], NULL, 10);
if (cpuid = CONFIG_NR_CPUS) {
- printf (Core num: %d is out of range[0..%d]\n,
+ printf (Core num: %lu is out of range[0..%d]\n,
cpuid, CONFIG_NR_CPUS - 1);
return 1;
}
diff --git a/cpu/mpc85xx/mp.c b/cpu/mpc85xx/mp.c
index a527cf3..554830f 100644
--- a/cpu/mpc85xx/mp.c
+++ b/cpu/mpc85xx/mp.c
@@ -50,12 +50,12 @@ int cpu_status(int nr)
if (nr == id) {
table = (u32 *)get_spin_addr();
- printf(table base @ 0x%08x\n, table);
+ printf(table base @ 0x%p\n, table);
} else {
table = (u32 *)get_spin_addr() + nr * NUM_BOOT_ENTRY;
printf(Running on cpu %d\n, id);
printf(\n);
- printf(table @ 0x%08x:\n, table);
+ printf(table @ 0x%p\n, table);
printf( addr - 0x%08x\n, table[BOOT_ENTRY_ADDR_LOWER]);
printf( pir - 0x%08x\n, table[BOOT_ENTRY_PIR]);
printf( r3 - 0x%08x\n, table[BOOT_ENTRY_R3_LOWER]);
--
1.5.5.1
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [REPOST][PATCH 1/4] 85xx: Cleanup L2 cache size detection
The L2 size detection code was a bit confusing and we kept having to add
code to it to handle new processors. Change the sense of detection so we
look for the older processors that aren't changing.
Also added support for 1M cache size on 8572.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
cpu/mpc85xx/cpu_init.c | 47 ++-
1 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/cpu/mpc85xx/cpu_init.c b/cpu/mpc85xx/cpu_init.c
index 736aef1..4feb751 100644
--- a/cpu/mpc85xx/cpu_init.c
+++ b/cpu/mpc85xx/cpu_init.c
@@ -261,37 +261,50 @@ int cpu_init_r(void)
volatile uint cache_ctl;
uint svr, ver;
uint l2srbar;
+ u32 l2siz_field;
svr = get_svr();
ver = SVR_SOC_VER(svr);
asm(msync;isync);
cache_ctl = l2cache-l2ctl;
+ l2siz_field = (cache_ctl 28) 0x3;
- switch (cache_ctl 0x3000) {
- case 0x2000:
- if (ver == SVR_8548 || ver == SVR_8548_E ||
- ver == SVR_8544 || ver == SVR_8568_E) {
- puts (512 KB );
- /* set L2E=1, L2I=1, L2SRAM=0 */
- cache_ctl = 0xc000;
+ switch (l2siz_field) {
+ case 0x0:
+ printf( unknown size (0x%08x)\n, cache_ctl);
+ return -1;
+ break;
+ case 0x1:
+ if (ver == SVR_8540 || ver == SVR_8560 ||
+ ver == SVR_8541 || ver == SVR_8541_E ||
+ ver == SVR_8555 || ver == SVR_8555_E) {
+ puts(128 KB );
+ /* set L2E=1, L2I=1, L2BLKSZ=1 (128 Kbyte) */
+ cache_ctl = 0xc400;
} else {
puts(256 KB );
+ cache_ctl = 0xc000; /* set L2E=1, L2I=1, L2SRAM=0
*/
+ }
+ break;
+ case 0x2:
+ if (ver == SVR_8540 || ver == SVR_8560 ||
+ ver == SVR_8541 || ver == SVR_8541_E ||
+ ver == SVR_8555 || ver == SVR_8555_E) {
+ puts(256 KB );
/* set L2E=1, L2I=1, L2BLKSZ=2 (256 Kbyte) */
cache_ctl = 0xc800;
+ } else {
+ puts (512 KB );
+ /* set L2E=1, L2I=1, L2SRAM=0 */
+ cache_ctl = 0xc000;
}
break;
- case 0x1000:
- puts(256 KB );
- if (ver == SVR_8544 || ver == SVR_8544_E) {
- cache_ctl = 0xc000; /* set L2E=1, L2I=1, L2SRAM=0
*/
- }
+ case 0x3:
+ puts(1024 KB );
+ /* set L2E=1, L2I=1, L2SRAM=0 */
+ cache_ctl = 0xc000;
break;
- case 0x3000:
- case 0x:
- default:
- printf( unknown size (0x%08x)\n, cache_ctl);
- return -1;
}
if (l2cache-l2ctl 0x8000) {
--
1.5.5.1
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [REPOST][PATCH 2/4] MPC8544DS: Report board id, board version and fpga version.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
board/freescale/mpc8544ds/mpc8544ds.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mpc8544ds/mpc8544ds.c
b/board/freescale/mpc8544ds/mpc8544ds.c
index 8c4b040..c39ce11 100644
--- a/board/freescale/mpc8544ds/mpc8544ds.c
+++ b/board/freescale/mpc8544ds/mpc8544ds.c
@@ -49,7 +49,10 @@ int checkboard (void)
if ((uint)gur-porpllsr != 0xe00e) {
printf(immap size error %lx\n,(ulong)gur-porpllsr);
}
- printf (Board: MPC8544DS\n);
+ printf (Board: MPC8544DS, System ID: 0x%02x,
+ System Version: 0x%02x, FPGA Version: 0x%02x\n,
+ in8(PIXIS_BASE + PIXIS_ID), in8(PIXIS_BASE + PIXIS_VER),
+ in8(PIXIS_BASE + PIXIS_PVER));
lbc-ltesr = 0x;/* Clear LBC error interrupts */
lbc-lteir = 0x;/* Enable LBC error interrupts */
--
1.5.5.1
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [REPOST][PATCH 4/4] MPC8544DS: Add ATI Video card support
Add support for using a PCIe ATI Video card on PCIe2. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- board/freescale/mpc8544ds/u-boot.lds |1 + include/configs/MPC8544DS.h | 24 ++-- 2 files changed, 23 insertions(+), 2 deletions(-) diff --git a/board/freescale/mpc8544ds/u-boot.lds b/board/freescale/mpc8544ds/u-boot.lds index 785a006..c66c69f 100644 --- a/board/freescale/mpc8544ds/u-boot.lds +++ b/board/freescale/mpc8544ds/u-boot.lds @@ -71,6 +71,7 @@ SECTIONS lib_generic/crc32.o (.text) lib_ppc/extable.o (.text) lib_generic/zlib.o (.text) +drivers/bios_emulator/atibios.o (.text) *(.text) *(.fixup) *(.got1) diff --git a/include/configs/MPC8544DS.h b/include/configs/MPC8544DS.h index 669f4d7..a0e4df8 100644 --- a/include/configs/MPC8544DS.h +++ b/include/configs/MPC8544DS.h @@ -226,7 +226,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CFG_INIT_SP_OFFSET CFG_GBL_DATA_OFFSET #define CFG_MONITOR_LEN(256 * 1024) /* Reserve 256 kB for Mon */ -#define CFG_MALLOC_LEN (128 * 1024)/* Reserved for malloc */ +#define CFG_MALLOC_LEN (1024 * 1024) /* Reserved for malloc */ /* Serial Port - controlled on board with jumper J8 * open - index 2 @@ -314,6 +314,26 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #if defined(CONFIG_PCI) +/*PCIE video card used*/ +#define VIDEO_IO_OFFSETCFG_PCIE2_IO_PHYS + +/*PCI video card used*/ +/*#define VIDEO_IO_OFFSET CFG_PCI1_IO_PHYS*/ + +/* video */ +#define CONFIG_VIDEO + +#if defined(CONFIG_VIDEO) +#define CONFIG_BIOSEMU +#define CONFIG_CFB_CONSOLE +#define CONFIG_VIDEO_SW_CURSOR +#define CONFIG_VGA_AS_SINGLE_DEVICE +#define CONFIG_ATI_RADEON_FB +#define CONFIG_VIDEO_LOGO +/*#define CONFIG_CONSOLE_CURSOR*/ +#define CFG_ISA_IO_BASE_ADDRESS VIDEO_IO_OFFSET +#endif + #define CONFIG_NET_MULTI #define CONFIG_PCI_PNP /* do pci plug-and-play */ @@ -382,7 +402,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #if CFG_MONITOR_BASE 0xfff8 #define CFG_ENV_ADDR 0xfff8 #else -#define CFG_ENV_ADDR (CFG_MONITOR_BASE + 0x4) +#define CFG_ENV_ADDR (CFG_MONITOR_BASE + 0x7) #endif #define CFG_ENV_SIZE 0x2000 #define CFG_ENV_SECT_SIZE 0x1 /* 64K (one sector) */ -- 1.5.5.1 - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] cpu/mpc85xx/fdt.c forcing incorrect UART clock into fdt.
On Jul 8, 2008, at 4:42 PM, Paul Gortmaker wrote: I was updating a sbc8560 from u-boot v1.2.0 to git-current, and found that I'd loose the kernel serial console when the 8250 driver took over from udbg0 when using u-boot 1.3.x (booting via tftp'ing the dtb and the uImage separately) I eventually tracked it down to mpc85xx/fdt.c stomping on the contents of the UART clockrate in the dtb. Since the sbc8560 is sort of different -- in that it has external UARTs (instead of SOC/CPM), I'm guessing few other boards see this problem, because bi_busfreq is really their correct UART clk. I fixed it with this simple patch, but I was wondering whether it would be better to alternatively just check if the dtb value is zero, and then only insert a value; otherwise leave it alone... I think that should be left up to a board to decide, but in general it seems like doing the setting unconditionally is ok, we just didn't handle the case you had and the patch address it. - k - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command
If the path we are trying to print doesn't exist see if it matches an
aliases. We don't do anything fancy at this point, but just strip the
leading '/' if it exists and see if we have an exact match to an alias.
In the future we could try and prefix matching so the alias could be used
as a shorter path reference.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
common/cmd_fdt.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index 97b9dd7..65c5cdf 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -678,9 +678,23 @@ static int fdt_print(const char *pathp, char *prop, int
depth)
/*
* Not found or something else bad happened.
*/
- printf (libfdt fdt_path_offset() returned %s\n,
- fdt_strerror(nodeoffset));
- return 1;
+
+ /* see if we match an alias */
+ int aliasoffset = fdt_path_offset(working_fdt, /aliases);
+ if (aliasoffset = 0) {
+ const char *aliasp = pathp;
+ if (pathp[0] == '/')
+ aliasp++;
+ aliasp = fdt_getprop(working_fdt,
+ aliasoffset, aliasp, NULL);
+ nodeoffset = fdt_path_offset(working_fdt, aliasp);
+ }
+
+ if (nodeoffset 0) {
+ printf(libfdt fdt_path_offset() returned %s\n,
+ fdt_strerror(nodeoffset));
+ return 1;
+ }
}
/*
* The user passed in a property as well as node path.
--
1.5.5.1
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [RFC][FSL DDR 0/8] Freescale DDR rewrit
On Jul 8, 2008, at 2:32 AM, David Saada wrote: Does this RFC also include support for identifying and initializing more than one DDR module? I'm not sure I follow exactly what you are asking? Do you mean using different DDR modules on different chip selects of the same controller? or something else? - k Kumar - the current SPD DDR code assumes a single DIMM with a single fixed I2C address. Does your RFC add support for more than one DIMM on the same controller? Yes it should. The 8641 HPCN has 2-dimm slots per controller and both dimm slots are supported. - k - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [RFC][FSL DDR 0/8] Freescale DDR rewrite
On Jul 7, 2008, at 10:48 AM, Jon Loeliger wrote:
On Sun, 2008-07-06 at 00:32 +0200, Wolfgang Denk wrote:
Dear Kumar,
in message [EMAIL PROTECTED]
you wrote:
This is a series of patches that are a work-in-progress towards a
new
DDR initialization for the Freescale 8{3,5,6}xxx devices that have a
common DDR controller.
Just to avoid misunderstandings: I understand these patches as RFC
only (as the subject says), i. e. this is not an attempt yet to get
this included in the upcoming release. Please confirm.
That is correct. In the meantime, there has been some
further development on this code base as well.
Agreed, the hope is to get something in shape for the 1.3.5 window.
- k
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] 85xx: extended cpu identification
On Jul 5, 2008, at 5:32 PM, Wolfgang Denk wrote: In message Pine.LNX. [EMAIL PROTECTED] you wrote: The current cpu identification code is used just to return the name of the processor at boot. There are some other locations that the name is useful (device tree setup). Also, we add a feature field to convey useful attributes of the processor. (for 85xx we have a single feature to tell if the processor has a crypto engine or not). Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- cpu/mpc85xx/cpu.c | 77 + + include/asm-ppc/processor.h | 13 +++ 2 files changed, 53 insertions(+), 37 deletions(-) There was some discussion about this patch, but I don't see an updated version posted, nor was it picked up (and fixed) by the custodian. So what's the state of this patch? this was reworked and accepted by Andy and in both mainline and his 85xx tree. - k - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [RFC][FSL DDR 0/8] Freescale DDR rewrit
On Jul 6, 2008, at 3:04 AM, David Saada wrote:
Kumar Gala-3 wrote:
This is a series of patches that are a work-in-progress towards a
new
DDR initialization for the Freescale 8{3,5,6}xxx devices that have a
common DDR controller.
(Sorry for the previous no subject message - hit the send too
soon...)
Kumar,
Does this RFC also include support for identifying and initializing
more than one DDR module?
I'm not sure I follow exactly what you are asking? Do you mean using
different DDR modules on different chip selects of the same
controller? or something else?
- k
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] cpu/mpc85xx/start.S: correct temporary TLB
On Jul 2, 2008, at 9:11 AM, Andrew Klossner wrote: From 03e28f90637703aaef9356dc398adedcdf06cb94 Mon Sep 17 00:00:00 2001 From: Andrew Klossner [EMAIL PROTECTED] Date: Wed, 2 Jul 2008 07:03:53 -0700 Subject: [PATCH] Change the temp map to ROM to align addresses to page size. With a page size of BOOKE_PAGESZ_16M, both the real and effective addresses must be multiples of 16MB. The hardware silently truncates them so the code happens to work. This patch clarifies the situation by establishing addresses that the hardware doesn't need to truncate. --- cpu/mpc85xx/start.S |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S index 2b5d90e..e2554d7 100644 --- a/cpu/mpc85xx/start.S +++ b/cpu/mpc85xx/start.S @@ -188,11 +188,11 @@ _start_e500: lis r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_16M)@h ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_16M)@l - lis r8,FSL_BOOKE_MAS2(TEXT_BASE, (MAS2_I|MAS2_G))@h - ori r8,r8,FSL_BOOKE_MAS2(TEXT_BASE, (MAS2_I|MAS2_G))@l + lis r8,FSL_BOOKE_MAS2(0xff00, (MAS2_I|MAS2_G))@h + ori r8,r8,FSL_BOOKE_MAS2(0xff00, (MAS2_I|MAS2_G))@l This needs to be TEXT_BASE 0xFF00 - lis r9,FSL_BOOKE_MAS3(0xff80, 0, (MAS3_SX|MAS3_SW| MAS3_SR))@h - ori r9,r9,FSL_BOOKE_MAS3(0xff80, 0, (MAS3_SX|MAS3_SW| MAS3_SR))@l + lis r9,FSL_BOOKE_MAS3(0xff00, 0, (MAS3_SX|MAS3_SW| MAS3_SR))@h + ori r9,r9,FSL_BOOKE_MAS3(0xff00, 0, (MAS3_SX|MAS3_SW| MAS3_SR))@l mtspr MAS0,r6 mtspr MAS1,r7 - k - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] MPC85xx: correct the procedure to change CCSRBAR.
On Jul 2, 2008, at 9:25 AM, Andrew Klossner wrote: The MPC8555E and MPC8548E reference manuals are quite specific about the formula required to change the value of CCSRBAR. This patch implements that formula. Those manuals are not correct in their description of updating CCSRBAR. The current code meets all the requirements excepting doing a load from some other address location. So you really want: temp = in_be32((volatile u32 *)CFG_CCSRBAR_DEFAULT); out_be32((volatile u32 *)CFG_CCSRBAR_DEFAULT, CFG_CCSRBAR_PHYS 12); /* do a dummy load from somewhere else */ temp = in_be32((volatile u32 *)TEXT_BASE); temp = in_be32((volatile u32 *)CFG_CCSRBAR); The in_be32/out_be32 cover the sync requirements that are needed. - k - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fs: make the static array to dynamic allocation
On Jun 26, 2008, at 9:50 AM, Dave Liu wrote:
Current fat.c have three 64KB static array, it makes
the BSS section larger.
Change the static to dynamic allocation.
Signed-off-by: Dave Liu [EMAIL PROTECTED]
---
fs/fat/fat.c | 38 +++---
1 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 49c78ed..8e054a6 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -28,6 +28,7 @@
#include common.h
#include config.h
#include fat.h
+#include malloc.h
#include asm/byteorder.h
#include part.h
@@ -65,6 +66,37 @@ int disk_read (__u32 startblock, __u32 getsize,
__u8 * bufptr)
return -1;
}
+__u8 *get_vfatname_block;
+__u8 *get_dentfromdir_block;
+__u8 *do_fat_read_block;
+static int fat_mem_done = 0;
+static int fat_memory_alloc(void)
+{
+ if (fat_mem_done)
+ return 0;
+
+ get_vfatname_block = (__u8 *)malloc(MAX_CLUSTSIZE);
do you really need the cast?
+ if (!get_vfatname_block) {
+ printf(alloc get_vfatname_block failed\n\r);
+ return -1;
+ }
+
+ get_dentfromdir_block = (__u8 *)malloc(MAX_CLUSTSIZE);
ditto.
+ if (!get_dentfromdir_block) {
+ printf(alloc get_dentfromdir_block failed\n\r);
+ return -1;
+ }
+
+ do_fat_read_block = (__u8 *)malloc(MAX_CLUSTSIZE);
ditto
+ if (!do_fat_read_block) {
+ printf(alloc do_fat_read_block failed\n\r);
+ return -1;
+ }
+
+ fat_mem_done = 1;
+
+ return 0;
+}
- k
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] MPC8610HPCD: Report board id, board version and fpga version.
Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- board/freescale/mpc8610hpcd/mpc8610hpcd.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd.c b/board/freescale/mpc8610hpcd/mpc8610hpcd.c index c85f373..0bf21d5 100644 --- a/board/freescale/mpc8610hpcd/mpc8610hpcd.c +++ b/board/freescale/mpc8610hpcd/mpc8610hpcd.c @@ -99,7 +99,10 @@ int checkboard(void) volatile immap_t *immap = (immap_t *)CFG_IMMR; volatile ccsr_local_mcm_t *mcm = immap-im_local_mcm; - puts(Board: MPC8610HPCD\n); + printf (Board: MPC8610HPCD, System ID: 0x%02lx, + System Version: 0x%02lx, FPGA Version: 0x%02lx\n, + in8(PIXIS_BASE + PIXIS_ID), in8(PIXIS_BASE + PIXIS_VER), + in8(PIXIS_BASE + PIXIS_PVER)); mcm-abcr |= 0x0001; /* 0 */ mcm-hpmr3 = 0x8008; /* 4c */ -- 1.5.5.1 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] MPC8641HPCN: Report board id, board version and fpga version.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
board/freescale/mpc8641hpcn/mpc8641hpcn.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
index cf540fc..b30c6b1 100644
--- a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
+++ b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
@@ -47,8 +47,10 @@ int board_early_init_f(void)
int checkboard(void)
{
- puts(Board: MPC8641HPCN\n);
-
+ printf (Board: MPC8641HPCN, System ID: 0x%02lx,
+ System Version: 0x%02lx, FPGA Version: 0x%02lx\n,
+ in8(PIXIS_BASE + PIXIS_ID), in8(PIXIS_BASE + PIXIS_VER),
+ in8(PIXIS_BASE + PIXIS_PVER));
return 0;
}
--
1.5.5.1
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] 85xx: Cleanup L2 cache size detection
The L2 size detection code was a bit confusing and we kept having to add
code to it to handle new processors. Change the sense of detection so we
look for the older processors that aren't changing.
Also added support for 1M cache size on 8572.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
cpu/mpc85xx/cpu_init.c | 47 ++-
1 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/cpu/mpc85xx/cpu_init.c b/cpu/mpc85xx/cpu_init.c
index 736aef1..4feb751 100644
--- a/cpu/mpc85xx/cpu_init.c
+++ b/cpu/mpc85xx/cpu_init.c
@@ -261,37 +261,50 @@ int cpu_init_r(void)
volatile uint cache_ctl;
uint svr, ver;
uint l2srbar;
+ u32 l2siz_field;
svr = get_svr();
ver = SVR_SOC_VER(svr);
asm(msync;isync);
cache_ctl = l2cache-l2ctl;
+ l2siz_field = (cache_ctl 28) 0x3;
- switch (cache_ctl 0x3000) {
- case 0x2000:
- if (ver == SVR_8548 || ver == SVR_8548_E ||
- ver == SVR_8544 || ver == SVR_8568_E) {
- puts (512 KB );
- /* set L2E=1, L2I=1, L2SRAM=0 */
- cache_ctl = 0xc000;
+ switch (l2siz_field) {
+ case 0x0:
+ printf( unknown size (0x%08x)\n, cache_ctl);
+ return -1;
+ break;
+ case 0x1:
+ if (ver == SVR_8540 || ver == SVR_8560 ||
+ ver == SVR_8541 || ver == SVR_8541_E ||
+ ver == SVR_8555 || ver == SVR_8555_E) {
+ puts(128 KB );
+ /* set L2E=1, L2I=1, L2BLKSZ=1 (128 Kbyte) */
+ cache_ctl = 0xc400;
} else {
puts(256 KB );
+ cache_ctl = 0xc000; /* set L2E=1, L2I=1, L2SRAM=0
*/
+ }
+ break;
+ case 0x2:
+ if (ver == SVR_8540 || ver == SVR_8560 ||
+ ver == SVR_8541 || ver == SVR_8541_E ||
+ ver == SVR_8555 || ver == SVR_8555_E) {
+ puts(256 KB );
/* set L2E=1, L2I=1, L2BLKSZ=2 (256 Kbyte) */
cache_ctl = 0xc800;
+ } else {
+ puts (512 KB );
+ /* set L2E=1, L2I=1, L2SRAM=0 */
+ cache_ctl = 0xc000;
}
break;
- case 0x1000:
- puts(256 KB );
- if (ver == SVR_8544 || ver == SVR_8544_E) {
- cache_ctl = 0xc000; /* set L2E=1, L2I=1, L2SRAM=0
*/
- }
+ case 0x3:
+ puts(1024 KB );
+ /* set L2E=1, L2I=1, L2SRAM=0 */
+ cache_ctl = 0xc000;
break;
- case 0x3000:
- case 0x:
- default:
- printf( unknown size (0x%08x)\n, cache_ctl);
- return -1;
}
if (l2cache-l2ctl 0x8000) {
--
1.5.5.1
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] MPC8544DS: Report board id, board version and fpga version.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
board/freescale/mpc8544ds/mpc8544ds.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mpc8544ds/mpc8544ds.c
b/board/freescale/mpc8544ds/mpc8544ds.c
index f615b23..1994e77 100644
--- a/board/freescale/mpc8544ds/mpc8544ds.c
+++ b/board/freescale/mpc8544ds/mpc8544ds.c
@@ -49,7 +49,10 @@ int checkboard (void)
if ((uint)gur-porpllsr != 0xe00e) {
printf(immap size error %x\n,gur-porpllsr);
}
- printf (Board: MPC8544DS\n);
+ printf (Board: MPC8544DS, System ID: 0x%02lx,
+ System Version: 0x%02lx, FPGA Version: 0x%02lx\n,
+ in8(PIXIS_BASE + PIXIS_ID), in8(PIXIS_BASE + PIXIS_VER),
+ in8(PIXIS_BASE + PIXIS_PVER));
lbc-ltesr = 0x;/* Clear LBC error interrupts */
lbc-lteir = 0x;/* Enable LBC error interrupts */
--
1.5.5.1
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Fix 4xx build issue
On Jun 12, 2008, at 6:51 AM, Stefan Roese wrote: On Thursday 12 June 2008, Anatolij Gustschin wrote: Building for 4xx doesn't work since commit 4dbdb768: In file included from 4xx_pcie.c:28: include/asm/processor.h:971: error: expected ')' before 'ver' make[1]: *** [4xx_pcie.o] Error 1 This patch fixes the problem. Signed-off-by: Anatolij Gustschin [EMAIL PROTECTED] Acked-by: Stefan Roese [EMAIL PROTECTED] Acked-by: Kumar Gala [EMAIL PROTECTED] - k - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] ppc: Add u64 versions of fls64 and __ilog bitops
On Jun 10, 2008, at 6:51 PM, Wolfgang Denk wrote:
Dear Kumar,
in message 3F2661BD-8C86-410F-984D-
[EMAIL PROTECTED] you wrote:
Comments and code do not match; you'r actually adding much more
code.
I was just needing the u64 versions and the other stuff came along to
make it work :)
Please make the comment match the code.
will do.
Also: is fls() vs. __fls() a good way to differentiate between int
and
ulong?
I took this from the kernel source tree and didn't really pay much
attention to it.
Maybe we can do better?
going to drop __fls()
+ * fls64(value) returns 0 if value is 0 or the position of the
last
+ * set bit if value is nonzero. The last (most significant) bit is
Sorry, I can't parse this.
again taken from kernel land.
No reason not to fix it.
I'm not clear on what the confusion is.
+#elif BITS_PER_LONG == 64
+static inline int fls64(__u64 x)
+{
+ if (x == 0)
+ return 0;
+ return __fls(x) + 1;
Do I have to understand where the +1 is coming from?
It has to do w/how __fls(x) is implemented. It might be clear in v2.
Nope, you can just accept it. I can drop this for now since I don't
believe we support any ppc64 machines.
I guess we might see support for the PA6T soon. SO please leave it
here.
And I'd appreciate if somebody could explain the code to me...
+static inline int ffs64(u64 x)
+{
+ return __ilog2_u64(x -x) + 1ull;
Isn't there an easier way to do this?
Not aware of one.
So, I've stolen this from the kernel and am not sure what you'd like
for me to change at this point.
Please clean it up and fix at least the obvious issues.
Best regards,
take a look at v2 and see what issues you have with it :)
- k
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] ppc: Added fls, fls64, __ilog2_u64, and ffs64 to bitops
fls64, __ilog2_u64, ffs64 are variants that work on an u64 and fls
is used to implement them.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Dropped __fls and cleaned up things a bit based on feedback (commit message is
more explicit).
- k
include/asm-ppc/bitops.h | 49 ++
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/include/asm-ppc/bitops.h b/include/asm-ppc/bitops.h
index 4e9c608..957b3d4 100644
--- a/include/asm-ppc/bitops.h
+++ b/include/asm-ppc/bitops.h
@@ -167,6 +167,55 @@ extern __inline__ int ffz(unsigned int x)
return __ilog2(x -x);
}
+/*
+ * fls: find last (most-significant) bit set.
+ * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
+ */
+static __inline__ int fls(unsigned int x)
+{
+ return __ilog2(x) + 1;
+}
+
+/**
+ * fls64 - find last set bit in a 64-bit word
+ * @x: the word to search
+ *
+ * This is defined in a similar way as the libc and compiler builtin
+ * ffsll, but returns the position of the most significant set bit.
+ *
+ * fls64(value) returns 0 if value is 0 or the position of the last
+ * set bit if value is nonzero. The last (most significant) bit is
+ * at position 64.
+ */
+#if BITS_PER_LONG == 32
+static inline int fls64(__u64 x)
+{
+ __u32 h = x 32;
+ if (h)
+ return fls(h) + 32;
+ return fls(x);
+}
+#elif BITS_PER_LONG == 64
+static inline int fls64(__u64 x)
+{
+ if (x == 0)
+ return 0;
+ return __ilog2(x) + 1;
+}
+#else
+#error BITS_PER_LONG not 32 or 64
+#endif
+
+static inline int __ilog2_u64(u64 n)
+{
+ return fls64(n) - 1;
+}
+
+static inline int ffs64(u64 x)
+{
+ return __ilog2_u64(x -x) + 1ull;
+}
+
#ifdef __KERNEL__
/*
--
1.5.5.1
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] ppc: Added fls, fls64, __ilog2_u64, and ffs64 to bitops
On Jun 11, 2008, at 5:54 AM, Haavard Skinnemoen wrote:
Kumar Gala [EMAIL PROTECTED] wrote:
+/*
+ * fls: find last (most-significant) bit set.
+ * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
+ */
+static __inline__ int fls(unsigned int x)
+{
+return __ilog2(x) + 1;
+}
__ilog2(0) returns -1?
it does.
- k
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] ppc: Added fls, fls64, __ilog2_u64, and ffs64 to bitops
On Jun 11, 2008, at 9:03 AM, Haavard Skinnemoen wrote:
Kumar Gala [EMAIL PROTECTED] wrote:
On Jun 11, 2008, at 5:54 AM, Haavard Skinnemoen wrote:
Kumar Gala [EMAIL PROTECTED] wrote:
+/*
+ * fls: find last (most-significant) bit set.
+ * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
+ */
+static __inline__ int fls(unsigned int x)
+{
+ return __ilog2(x) + 1;
+}
__ilog2(0) returns -1?
it does.
In general, or just on powerpc? If it's the latter, could you add a
comment so that people won't blindly copy it into their architecture's
bitops.h?
I'm guessing on PPC (thus the __ilog2 rather than ilog2()).
From the kernel headers:
/*
* non-constant log of base 2 calculators
* - the arch may override these in asm/bitops.h if they can be
implemented
* more efficiently than using fls() and fls64()
* - the arch is not required to handle n==0 if implementing the
fallback
*/
#ifndef CONFIG_ARCH_HAS_ILOG2_U32
static inline __attribute__((const))
int __ilog2_u32(u32 n)
{
return fls(n) - 1;
}
#endif
I'll add a comment.
- k
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH v2] ppc: Added fls, fls64, __ilog2_u64, and ffs64 to bitops
fls64, __ilog2_u64, ffs64 are variants that work on an u64 and fls
is used to implement them.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
added comment about __ilog2() x == 0 being undefined.
include/asm-ppc/bitops.h | 50 ++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/include/asm-ppc/bitops.h b/include/asm-ppc/bitops.h
index 4e9c608..23f5449 100644
--- a/include/asm-ppc/bitops.h
+++ b/include/asm-ppc/bitops.h
@@ -152,6 +152,7 @@ extern __inline__ int test_bit(int nr, __const__ volatile
void *addr)
}
/* Return the bit position of the most significant 1 bit in a word */
+/* - the result is undefined when x == 0 */
extern __inline__ int __ilog2(unsigned int x)
{
int lz;
@@ -167,6 +168,55 @@ extern __inline__ int ffz(unsigned int x)
return __ilog2(x -x);
}
+/*
+ * fls: find last (most-significant) bit set.
+ * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
+ */
+static __inline__ int fls(unsigned int x)
+{
+ return __ilog2(x) + 1;
+}
+
+/**
+ * fls64 - find last set bit in a 64-bit word
+ * @x: the word to search
+ *
+ * This is defined in a similar way as the libc and compiler builtin
+ * ffsll, but returns the position of the most significant set bit.
+ *
+ * fls64(value) returns 0 if value is 0 or the position of the last
+ * set bit if value is nonzero. The last (most significant) bit is
+ * at position 64.
+ */
+#if BITS_PER_LONG == 32
+static inline int fls64(__u64 x)
+{
+ __u32 h = x 32;
+ if (h)
+ return fls(h) + 32;
+ return fls(x);
+}
+#elif BITS_PER_LONG == 64
+static inline int fls64(__u64 x)
+{
+ if (x == 0)
+ return 0;
+ return __ilog2(x) + 1;
+}
+#else
+#error BITS_PER_LONG not 32 or 64
+#endif
+
+static inline int __ilog2_u64(u64 n)
+{
+ return fls64(n) - 1;
+}
+
+static inline int ffs64(u64 x)
+{
+ return __ilog2_u64(x -x) + 1ull;
+}
+
#ifdef __KERNEL__
/*
--
1.5.5.1
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH v3] ppc: Added fls, fls64, __ilog2_u64, and ffs64 to bitops
fls64, __ilog2_u64, ffs64 are variants that work on an u64 and fls
is used to implement them.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Added comment about __ilog2(0) not being generally safe from Haavard Skinnemoen
- k
include/asm-ppc/bitops.h | 52 ++
1 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/include/asm-ppc/bitops.h b/include/asm-ppc/bitops.h
index 4e9c608..daa66cf 100644
--- a/include/asm-ppc/bitops.h
+++ b/include/asm-ppc/bitops.h
@@ -152,6 +152,7 @@ extern __inline__ int test_bit(int nr, __const__ volatile
void *addr)
}
/* Return the bit position of the most significant 1 bit in a word */
+/* - the result is undefined when x == 0 */
extern __inline__ int __ilog2(unsigned int x)
{
int lz;
@@ -167,6 +168,57 @@ extern __inline__ int ffz(unsigned int x)
return __ilog2(x -x);
}
+/*
+ * fls: find last (most-significant) bit set.
+ * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
+ *
+ * On powerpc, __ilog2(0) returns -1, but this is not safe in general
+ */
+static __inline__ int fls(unsigned int x)
+{
+ return __ilog2(x) + 1;
+}
+
+/**
+ * fls64 - find last set bit in a 64-bit word
+ * @x: the word to search
+ *
+ * This is defined in a similar way as the libc and compiler builtin
+ * ffsll, but returns the position of the most significant set bit.
+ *
+ * fls64(value) returns 0 if value is 0 or the position of the last
+ * set bit if value is nonzero. The last (most significant) bit is
+ * at position 64.
+ */
+#if BITS_PER_LONG == 32
+static inline int fls64(__u64 x)
+{
+ __u32 h = x 32;
+ if (h)
+ return fls(h) + 32;
+ return fls(x);
+}
+#elif BITS_PER_LONG == 64
+static inline int fls64(__u64 x)
+{
+ if (x == 0)
+ return 0;
+ return __ilog2(x) + 1;
+}
+#else
+#error BITS_PER_LONG not 32 or 64
+#endif
+
+static inline int __ilog2_u64(u64 n)
+{
+ return fls64(n) - 1;
+}
+
+static inline int ffs64(u64 x)
+{
+ return __ilog2_u64(x -x) + 1ull;
+}
+
#ifdef __KERNEL__
/*
--
1.5.5.1
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/4] Change initdram() return type to phys_size_t
On Jun 11, 2008, at 5:53 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: This patch changes the return type of initdram() from long int to phys_size_t. This is required for a couple of reasons: long int limits the amount of dram to 2GB, and u-boot in general is moving over to phys_size_t to represent the size of physical memory. phys_size_t is defined as an unsigned long on almost all current platforms. This patch *only* changes the return type of the initdram function (in include/common.h, as well as in each board's implementation of initdram). It does not actually modify the code inside the function on any of the platforms; platforms which wish to support more than 2GB of DRAM will need to modify their initdram() function code. Build tested with MAKEALL for ppc, arm, mips, mips-el. Booted on powerpc MPC8641HPCN. Patch is too large for the list, and is located at: http://gate.crashing.org/~galak/0001-Change-initdram-return-type-to-phys_size_t.patch Sorry, but I'm afraid this doesn't apply at all: Applying Change initdram() return type to phys_size_t error: board/amcc/kilauea/memory.c: does not exist in index error: board/amcc/makalu/memory.c: does not exist in index error: patch failed: board/amcc/yosemite/yosemite.c:331 error: board/amcc/yosemite/yosemite.c: patch does not apply error: patch failed: board/esd/ar405/ar405.c:192 error: board/esd/ar405/ar405.c: patch does not apply error: patch failed: board/esd/canbt/canbt.c:184 error: board/esd/canbt/canbt.c: patch does not apply error: patch failed: board/g2000/g2000.c:158 error: board/g2000/g2000.c: patch does not apply error: board/tqm5200/tqm5200.c: does not exist in index error: board/tqm8260/tqm8260.c: does not exist in index error: board/tqm8272/tqm8272.c: does not exist in index error: board/tqm834x/tqm834x.c: does not exist in index error: board/tqm85xx/sdram.c: does not exist in index error: board/tqm8xx/tqm8xx.c: does not exist in index error: patch failed: board/w7o/w7o.c:151 error: board/w7o/w7o.c: patch does not apply error: patch failed: nand_spl/board/amcc/bamboo/sdram.c:89 error: nand_spl/board/amcc/bamboo/sdram.c: patch does not apply Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merged board/amcc/acadia/memory.c ... Auto-merged board/amcc/ebony/ebony.c CONFLICT (delete/modify): board/amcc/kilauea/memory.c deleted in HEAD and modified in Change initdram() return type to phys_size_t. Version Change initdram() return type to phys_size_t of board/amcc/ kilauea/memory.c left in tree. CONFLICT (delete/modify): board/amcc/makalu/memory.c deleted in HEAD and modified in Change initdram() return type to phys_size_t. Version Change initdram() return type to phys_size_t of board/amcc/ makalu/memory.c left in tree. Auto-merged board/amcc/ocotea/ocotea.c ... Auto-merged board/amcc/yosemite/yosemite.c CONFLICT (content): Merge conflict in board/amcc/yosemite/yosemite.c Auto-merged board/csb272/csb272.c ... Auto-merged board/esd/ar405/ar405.c CONFLICT (content): Merge conflict in board/esd/ar405/ar405.c Auto-merged board/esd/canbt/canbt.c CONFLICT (content): Merge conflict in board/esd/canbt/canbt.c Auto-merged board/exbitgen/exbitgen.c ... Auto-merged board/g2000/g2000.c CONFLICT (content): Merge conflict in board/g2000/g2000.c Auto-merged board/gth2/gth2.c ... Auto-merged board/purple/purple.c CONFLICT (delete/modify): board/tqm8272/tqm8272.c deleted in HEAD and modified in Change initdram() return type to phys_size_t. Version Change initdram() return type to phys_size_t of board/ tqm8272/tqm8272.c left in tree. CONFLICT (delete/modify): board/tqm85xx/sdram.c deleted in HEAD and modified in Change initdram() return type to phys_size_t. Version Change initdram() return type to phys_size_t of board/tqm85xx/ sdram.c left in tree. Auto-merged board/w7o/w7o.c ... Auto-merged nand_spl/board/amcc/bamboo/sdram.c CONFLICT (content): Merge conflict in nand_spl/board/amcc/bamboo/ sdram.c Failed to merge in the changes. Patch failed at 0001. Can you please rebase your patch set? Since Becky's been under the weather today and I'm feeling generous how about this version: http://gate.crashing.org/~galak/0001-v2-Change-initdram-return-type-to-phys_size_t.patch It should apply clean to: commit cdeb62e20d94005f2e80604fda03b498c3a6f704 Merge: 1859e42... ae9e97f... Author: Wolfgang Denk [EMAIL PROTECTED] Date: Wed Jun 11 22:30:47 2008 +0200 Merge branch 'master' of git://www.denx.de/git/u-boot-fdt - k - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list
Re: [U-Boot-Users] [PATCH] 85xx: extended cpu identification
On Jun 10, 2008, at 12:57 AM, Kim Phillips wrote:
On Thu, 29 May 2008 03:20:08 -0500 (CDT)
Kumar Gala [EMAIL PROTECTED] wrote:
+struct cpu_type cpu_type_list [] = {
+CPU_TYPE_ENTRY(8533, 8533, 0),
+CPU_TYPE_ENTRY(8533, 8533_E, CPU_FTRS_HAS_CRYPTO),
+CPU_TYPE_ENTRY(8540, 8540, 0),
+CPU_TYPE_ENTRY(8541, 8541, 0),
+CPU_TYPE_ENTRY(8541, 8541_E, CPU_FTRS_HAS_CRYPTO),
+CPU_TYPE_ENTRY(8543, 8543, 0),
+CPU_TYPE_ENTRY(8543, 8543_E, CPU_FTRS_HAS_CRYPTO),
+CPU_TYPE_ENTRY(8544, 8544, 0),
+CPU_TYPE_ENTRY(8544, 8544_E, CPU_FTRS_HAS_CRYPTO),
+CPU_TYPE_ENTRY(8545, 8545, 0),
+CPU_TYPE_ENTRY(8545, 8545_E, CPU_FTRS_HAS_CRYPTO),
+CPU_TYPE_ENTRY(8547, 8547_E, CPU_FTRS_HAS_CRYPTO),
+CPU_TYPE_ENTRY(8548, 8548, 0),
+CPU_TYPE_ENTRY(8548, 8548_E, CPU_FTRS_HAS_CRYPTO),
+CPU_TYPE_ENTRY(8555, 8555, 0),
+CPU_TYPE_ENTRY(8555, 8555_E, CPU_FTRS_HAS_CRYPTO),
+CPU_TYPE_ENTRY(8560, 8560, 0),
+CPU_TYPE_ENTRY(8567, 8567, 0),
+CPU_TYPE_ENTRY(8567, 8567_E, CPU_FTRS_HAS_CRYPTO),
+CPU_TYPE_ENTRY(8568, 8568, 0),
+CPU_TYPE_ENTRY(8568, 8568_E, CPU_FTRS_HAS_CRYPTO),
+CPU_TYPE_ENTRY(8572, 8572, 0),
+CPU_TYPE_ENTRY(8572, 8572_E, CPU_FTRS_HAS_CRYPTO),
this seems like overkill given all we have to do is check one bit (see
IS_E_PROCESSOR macro in handle crypto node patch I just sent out).
I don't trust our HW guys to keep w/that convention. Plus we can use
this mechanism for other things if need be.
- k
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] 85xx: extended cpu identification
On Jun 10, 2008, at 8:48 AM, Kim Phillips wrote:
On Tue, 10 Jun 2008 08:23:46 -0500
Kumar Gala [EMAIL PROTECTED] wrote:
On Jun 10, 2008, at 12:57 AM, Kim Phillips wrote:
On Thu, 29 May 2008 03:20:08 -0500 (CDT)
Kumar Gala [EMAIL PROTECTED] wrote:
+struct cpu_type cpu_type_list [] = {
+ CPU_TYPE_ENTRY(8533, 8533, 0),
+ CPU_TYPE_ENTRY(8533, 8533_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8540, 8540, 0),
+ CPU_TYPE_ENTRY(8541, 8541, 0),
+ CPU_TYPE_ENTRY(8541, 8541_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8543, 8543, 0),
+ CPU_TYPE_ENTRY(8543, 8543_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8544, 8544, 0),
+ CPU_TYPE_ENTRY(8544, 8544_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8545, 8545, 0),
+ CPU_TYPE_ENTRY(8545, 8545_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8547, 8547_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8548, 8548, 0),
+ CPU_TYPE_ENTRY(8548, 8548_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8555, 8555, 0),
+ CPU_TYPE_ENTRY(8555, 8555_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8560, 8560, 0),
+ CPU_TYPE_ENTRY(8567, 8567, 0),
+ CPU_TYPE_ENTRY(8567, 8567_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8568, 8568, 0),
+ CPU_TYPE_ENTRY(8568, 8568_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8572, 8572, 0),
+ CPU_TYPE_ENTRY(8572, 8572_E, CPU_FTRS_HAS_CRYPTO),
this seems like overkill given all we have to do is check one bit
(see
IS_E_PROCESSOR macro in handle crypto node patch I just sent out).
I don't trust our HW guys to keep w/that convention. Plus we can use
this mechanism for other things if need be.
they've been pretty good so far, and until the other thing comes
around, we can compact this table instead of expanding it - the 85xx_E
entries themselves are unnecessary.
I disagree and would prefer to keep it as I've done as it provides the
most flexibility.
- k
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: unshadow global working fdt variable
On Jun 10, 2008, at 11:06 AM, Kim Phillips wrote: differentiate with local variables of the same name by renaming the global 'fdt' variable 'working_fdt'. Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- applies to current u-boot-fdt.git. thank you, this was just evil. - k - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] FSL LAW: Add new interface to use the last free LAW
LAWs have the concept of priority so its useful to be able to allocate
the lowest (highest number) priority. We will end up using this with the
new DDR code.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
drivers/misc/fsl_law.c| 19 +++
include/asm-ppc/fsl_law.h |1 +
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/fsl_law.c b/drivers/misc/fsl_law.c
index d7d6c40..48ece4f 100644
--- a/drivers/misc/fsl_law.c
+++ b/drivers/misc/fsl_law.c
@@ -70,6 +70,25 @@ int set_next_law(phys_addr_t addr, enum law_size sz, enum
law_trgt_if id)
return idx;
}
+int set_last_law(phys_addr_t addr, enum law_size sz, enum law_trgt_if id)
+{
+ u32 idx;
+
+ /* we have no LAWs free */
+ if (gd-used_laws == -1)
+ return -1;
+
+ /* grab the last free law */
+ idx = __ilog2(~(gd-used_laws));
+
+ if (idx = FSL_HW_NUM_LAWS)
+ return -1;
+
+ set_law(idx, addr, sz, id);
+
+ return idx;
+}
+
void disable_law(u8 idx)
{
volatile u32 *base = (volatile u32 *)(CFG_IMMR + 0xc08);
diff --git a/include/asm-ppc/fsl_law.h b/include/asm-ppc/fsl_law.h
index 6c445a4..227bf83 100644
--- a/include/asm-ppc/fsl_law.h
+++ b/include/asm-ppc/fsl_law.h
@@ -74,6 +74,7 @@ struct law_entry {
extern void set_law(u8 idx, phys_addr_t addr, enum law_size sz, enum
law_trgt_if id);
extern int set_next_law(phys_addr_t addr, enum law_size sz, enum law_trgt_if
id);
+extern int set_last_law(phys_addr_t addr, enum law_size sz, enum law_trgt_if
id);
extern void disable_law(u8 idx);
extern void init_laws(void);
extern void print_laws(void);
--
1.5.5.1
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt_support: add crypto node handling for MPC8{3, 5}xxE processors
void ft_cpu_setup(void *blob, bd_t *bd)
{
+ /* delete crypto node if not on an E-processor */
+ if (!IS_E_PROCESSOR(get_svr()))
+ fdt_fixup_crypto_node(blob, 0);
+
This is wrong or you need to fix the IS_E_PROCESSOR() macro.
IS_E_PROCESSOR(svr) should be defined:
svr 0x8
or you want:
IS_E_PROCESSOR(SVR_SOC_VER(get_svr()))
- k
#if defined(CONFIG_HAS_ETH0) || defined(CONFIG_HAS_ETH1) ||\
defined(CONFIG_HAS_ETH2) || defined(CONFIG_HAS_ETH3)
fdt_fixup_ethernet(blob, bd);
diff --git a/include/asm-ppc/processor.h b/include/asm-ppc/processor.h
index 8bdfb9d..14d3d70 100644
--- a/include/asm-ppc/processor.h
+++ b/include/asm-ppc/processor.h
@@ -883,6 +883,15 @@
/* Some parts define SVR[0:23] as the SOC version */
#define SVR_SOC_VER(svr) (((svr) 8) 0xFF)/* SOC Version
fields */
+/* whether MPC8xxxE (i.e. has SEC) */
+#if defined(CONFIG_MPC85xx)
+#define IS_E_PROCESSOR(svr) (svr 0x800)
+#else
+#if defined(CONFIG_MPC83XX)
+#define IS_E_PROCESSOR(spridr) (!(spridr 0x0001))
+#endif
+#endif
+
/*
* SVR_SOC_VER() Version Values
*/
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] 85xx: expose cpu identification
The current cpu identification code is used just to return the name
of the processor at boot. There are some other locations that the name
is useful (device tree setup). Expose the functionality to other bits
of code.
Also, drop the 'E' suffix and add it on by looking at the SVR version
when we print this out. This is mainly to allow the most flexible use
of the name. The device tree code tends to not care about the 'E' suffix.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Reworked and dropped the flags idea and just use SVR to determine the 'E' bit.
At this point he HW guys will now break the convention of using the particular
bit we test to determine if we have crypto or not.
- k
cpu/mpc85xx/cpu.c | 76 ++
include/asm-ppc/processor.h | 11 ++
2 files changed, 51 insertions(+), 36 deletions(-)
diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index 58d23f4..d585e87 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -32,38 +32,41 @@
DECLARE_GLOBAL_DATA_PTR;
-struct cpu_type {
- char name[15];
- u32 soc_ver;
+struct cpu_type cpu_type_list [] = {
+ CPU_TYPE_ENTRY(8533, 8533),
+ CPU_TYPE_ENTRY(8533, 8533_E),
+ CPU_TYPE_ENTRY(8540, 8540),
+ CPU_TYPE_ENTRY(8541, 8541),
+ CPU_TYPE_ENTRY(8541, 8541_E),
+ CPU_TYPE_ENTRY(8543, 8543),
+ CPU_TYPE_ENTRY(8543, 8543_E),
+ CPU_TYPE_ENTRY(8544, 8544),
+ CPU_TYPE_ENTRY(8544, 8544_E),
+ CPU_TYPE_ENTRY(8545, 8545),
+ CPU_TYPE_ENTRY(8545, 8545_E),
+ CPU_TYPE_ENTRY(8547, 8547_E),
+ CPU_TYPE_ENTRY(8548, 8548),
+ CPU_TYPE_ENTRY(8548, 8548_E),
+ CPU_TYPE_ENTRY(8555, 8555),
+ CPU_TYPE_ENTRY(8555, 8555_E),
+ CPU_TYPE_ENTRY(8560, 8560),
+ CPU_TYPE_ENTRY(8567, 8567),
+ CPU_TYPE_ENTRY(8567, 8567_E),
+ CPU_TYPE_ENTRY(8568, 8568),
+ CPU_TYPE_ENTRY(8568, 8568_E),
+ CPU_TYPE_ENTRY(8572, 8572),
+ CPU_TYPE_ENTRY(8572, 8572_E),
};
-#define CPU_TYPE_ENTRY(x) {#x, SVR_##x}
+struct cpu_type *identify_cpu(uint ver)
+{
+ int i;
+ for (i = 0; i ARRAY_SIZE(cpu_type_list); i++)
+ if (cpu_type_list[i].soc_ver == ver)
+ return cpu_type_list[i];
-struct cpu_type cpu_type_list [] = {
- CPU_TYPE_ENTRY(8533),
- CPU_TYPE_ENTRY(8533_E),
- CPU_TYPE_ENTRY(8540),
- CPU_TYPE_ENTRY(8541),
- CPU_TYPE_ENTRY(8541_E),
- CPU_TYPE_ENTRY(8543),
- CPU_TYPE_ENTRY(8543_E),
- CPU_TYPE_ENTRY(8544),
- CPU_TYPE_ENTRY(8544_E),
- CPU_TYPE_ENTRY(8545),
- CPU_TYPE_ENTRY(8545_E),
- CPU_TYPE_ENTRY(8547_E),
- CPU_TYPE_ENTRY(8548),
- CPU_TYPE_ENTRY(8548_E),
- CPU_TYPE_ENTRY(8555),
- CPU_TYPE_ENTRY(8555_E),
- CPU_TYPE_ENTRY(8560),
- CPU_TYPE_ENTRY(8567),
- CPU_TYPE_ENTRY(8567_E),
- CPU_TYPE_ENTRY(8568),
- CPU_TYPE_ENTRY(8568_E),
- CPU_TYPE_ENTRY(8572),
- CPU_TYPE_ENTRY(8572_E),
-};
+ return NULL;
+}
int checkcpu (void)
{
@@ -74,7 +77,7 @@ int checkcpu (void)
uint fam;
uint ver;
uint major, minor;
- int i;
+ struct cpu_type *cpu;
#ifdef CONFIG_DDR_CLK_FREQ
volatile ccsr_gur_t *gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
u32 ddr_ratio = ((gur-porpllsr) 0x3e00) 9;
@@ -89,14 +92,15 @@ int checkcpu (void)
puts(CPU: );
- for (i = 0; i ARRAY_SIZE(cpu_type_list); i++)
- if (cpu_type_list[i].soc_ver == ver) {
- puts(cpu_type_list[i].name);
- break;
- }
+ cpu = identify_cpu(ver);
+ if (cpu) {
+ puts(cpu-name);
- if (i == ARRAY_SIZE(cpu_type_list))
+ if (svr 0x8)
+ puts(E);
+ } else {
puts(Unknown);
+ }
printf(, Version: %d.%d, (0x%08x)\n, major, minor, svr);
diff --git a/include/asm-ppc/processor.h b/include/asm-ppc/processor.h
index 8bdfb9d..61a0d05 100644
--- a/include/asm-ppc/processor.h
+++ b/include/asm-ppc/processor.h
@@ -960,6 +960,17 @@ n:
#define SR15 15
#ifndef __ASSEMBLY__
+
+struct cpu_type {
+ char name[15];
+ u32 soc_ver;
+};
+
+struct cpu_type *identify_cpu(uint ver);
+
+#define CPU_TYPE_ENTRY(n, v) \
+ { .name = #n, .soc_ver = SVR_##v, }
+
#ifndef CONFIG_MACH_SPECIFIC
extern int _machine;
extern int have_of;
--
1.5.5.1
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] ppc: Add u64 versions of fls64 and __ilog bitops
On Jun 10, 2008, at 4:58 PM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED]
you wrote:
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
Comments and code do not match; you'r actually adding much more code.
I was just needing the u64 versions and the other stuff came along to
make it work :)
+/*
+ * fls: find last (most-significant) bit set.
+ * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
+ */
+static __inline__ int fls(unsigned int x)
This is not a u64 version of fls64, or is it? ;-)
+static __inline__ unsigned long __fls(unsigned long x)
Neither is this...
Also: is fls() vs. __fls() a good way to differentiate between int and
ulong?
I took this from the kernel source tree and didn't really pay much
attention to it.
+ * fls64(value) returns 0 if value is 0 or the position of the last
+ * set bit if value is nonzero. The last (most significant) bit is
Sorry, I can't parse this.
again taken from kernel land.
+#elif BITS_PER_LONG == 64
+static inline int fls64(__u64 x)
+{
+if (x == 0)
+return 0;
+return __fls(x) + 1;
Do I have to understand where the +1 is coming from?
Nope, you can just accept it. I can drop this for now since I don't
believe we support any ppc64 machines.
+static inline int ffs64(u64 x)
+{
+return __ilog2_u64(x -x) + 1ull;
Isn't there an easier way to do this?
Not aware of one.
So, I've stolen this from the kernel and am not sure what you'd like
for me to change at this point.
- k
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [RFC][FSL DDR 0/8] Freescale DDR rewrite
This is a series of patches that are a work-in-progress towards a new
DDR initialization for the Freescale 8{3,5,6}xxx devices that have a
common DDR controller.
These patches are also available at:
git://git.kernel.org/pub/scm/boot/u-boot/galak/u-boot.git fsl_ddr
and patch 0002 since its large is at:
http://gate.crashing.org/~galak/fsl_ddr.20080609/0002-Rewrite-the-FSL-mpc8xxx-DDR-controller-setup-code.patch
- k
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [RFC][FSL DDR 1/8] Add proper SPD definitions for DDR1/2/3
Also added a few helper functions for DDR1 DDR2 to print SPD info and
verify the checksum.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
common/Makefile |1 +
common/ddr_spd.c | 504 +
include/ddr_spd.h | 249 ++
3 files changed, 754 insertions(+), 0 deletions(-)
create mode 100644 common/ddr_spd.c
create mode 100644 include/ddr_spd.h
diff --git a/common/Makefile b/common/Makefile
index b425795..503c3b5 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -145,6 +145,7 @@ COBJS-y += cmd_mac.o
COBJS-$(CONFIG_CMD_MFSL) += cmd_mfsl.o
COBJS-$(CONFIG_MP) += cmd_mp.o
COBJS-$(CONFIG_CMD_SF) += cmd_sf.o
+COBJS-$(CONFIG_DDR_SPD) += ddr_spd.o
COBJS := $(COBJS-y)
SRCS := $(AOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/common/ddr_spd.c b/common/ddr_spd.c
new file mode 100644
index 000..bfabb93
--- /dev/null
+++ b/common/ddr_spd.c
@@ -0,0 +1,504 @@
+/*
+ * Copyright 2008 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * Version 2 as published by the Free Software Foundation.
+ */
+
+#include common.h
+#include ddr_spd.h
+
+void
+ddr1_spd_dump(const ddr1_spd_eeprom_t *spd)
+{
+ unsigned int i;
+
+ printf(%-3d: %02x %s\n,
+ 0, spd-info_size,
+ spd-info_size, * 0 # bytes written into serial memory *);
+ printf(%-3d: %02x %s\n,
+ 1, spd-chip_size,
+ spd-chip_size, * 1 Total # bytes of SPD memory device *);
+ printf(%-3d: %02x %s\n,
+ 2, spd-mem_type,
+ spd-mem_type,* 2 Fundamental memory type *);
+ printf(%-3d: %02x %s\n,
+ 3, spd-nrow_addr,
+ spd-nrow_addr, * 3 # of Row Addresses on this assembly *);
+ printf(%-3d: %02x %s\n,
+ 4, spd-ncol_addr,
+ spd-ncol_addr, * 4 # of Column Addrs on this assembly *);
+ printf(%-3d: %02x %s\n,
+ 5, spd-nrows,
+ spd-nrows* 5 # of DIMM Banks *);
+ printf(%-3d: %02x %s\n,
+ 6, spd-dataw_lsb,
+ spd-dataw_lsb, * 6 Data Width lsb of this assembly *);
+ printf(%-3d: %02x %s\n,
+ 7, spd-dataw_msb,
+ spd-dataw_msb, * 7 Data Width msb of this assembly *);
+ printf(%-3d: %02x %s\n,
+ 8, spd-voltage,
+ spd-voltage, * 8 Voltage intf std of this assembly *);
+ printf(%-3d: %02x %s\n,
+ 9, spd-clk_cycle,
+ spd-clk_cycle, * 9 SDRAM Cycle time at CL=X *);
+ printf(%-3d: %02x %s\n,
+ 10, spd-clk_access,
+ spd-clk_access, * 10 SDRAM Access from Clock at CL=X *);
+ printf(%-3d: %02x %s\n,
+ 11, spd-config,
+ spd-config, * 11 DIMM Configuration type *);
+ printf(%-3d: %02x %s\n,
+ 12, spd-refresh,
+ spd-refresh, * 12 Refresh Rate/Type *);
+ printf(%-3d: %02x %s\n,
+ 13, spd-primw,
+ spd-primw, * 13 Primary SDRAM Width *);
+ printf(%-3d: %02x %s\n,
+ 14, spd-ecw,
+ spd-ecw, * 14 Error Checking SDRAM width *);
+ printf(%-3d: %02x %s\n,
+ 15, spd-min_delay,
+ spd-min_delay, * 15 Back to Back Random Access *);
+ printf(%-3d: %02x %s\n,
+ 16, spd-burstl,
+ spd-burstl, * 16 Burst Lengths Supported *);
+ printf(%-3d: %02x %s\n,
+ 17, spd-nbanks,
+ spd-nbanks, * 17 # of Banks on Each SDRAM Device *);
+ printf(%-3d: %02x %s\n,
+ 18, spd-cas_lat,
+ spd-cas_lat, * 18 CAS# Latencies Supported *);
+ printf(%-3d: %02x %s\n,
+ 19, spd-cs_lat,
+ spd-cs_lat, * 19 Chip Select Latency *);
+ printf(%-3d: %02x %s\n,
+ 20, spd-write_lat,
+ spd-write_lat, * 20 Write Latency/Recovery *);
+ printf(%-3d: %02x %s\n,
+ 21, spd-mod_attr,
+ spd-mod_attr,* 21 SDRAM Module Attributes *);
+ printf(%-3d: %02x %s\n,
+ 22, spd-dev_attr,
+ spd-dev_attr,* 22 SDRAM Device Attributes *);
+ printf(%-3d: %02x %s\n,
+ 23, spd-clk_cycle2,
+ spd-clk_cycle2, * 23 Min SDRAM Cycle time at CL=X-1 *);
+ printf(%-3d: %02x %s\n,
+ 24, spd-clk_access2,
+ spd-clk_access2, * 24 SDRAM Access from Clock at CL=X-1 *);
+ printf(%-3d: %02x %s\n,
+ 25, spd-clk_cycle3,
+ spd-clk_cycle3, * 25 Min SDRAM Cycle time at CL=X-2 *);
+ printf(%-3d: %02x %s\n,
+ 26, spd-clk_access3
