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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[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=100&url=/ ___ 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 8:22 AM, Wolfgang Denk wrote: > In message [EMAIL PROTECTED]> you wrote: >> >>> 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? > > Not really, but this is not important at the moment. This will be > 1.3.4; for the next release we have a couple of weeks to come to a > conclusion. > >> Andy's out so can you pick up the 85xx linker script patch I'm about >> to send to address Rafal's issues. > > Are there any other 85xx related issues that might be sitting in his > queue? I dont think there is anything in his queue for 1.3.4 - 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=100&url=/ ___ 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 8:21 AM, Wolfgang Denk wrote: > In message > <[EMAIL PROTECTED]> you wrote: >> >>> ./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. > > Hm... previous experience with ld has made me extremely suspicious > about ld warnings. They all turn into subtle, but nasty errors sooner > or later. > > I think we should find a solution that does without such warnings. > > If this is impossible in the remaining time (given the late state in > the release cycle) I think it is better to back out the patch that > causes the problem, and try to solve this wil less pressure in the > next release. sent a v2 that addresses the warning. hopefully that will put this to rest. - 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=100&url=/ ___ 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][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
[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
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=100&url=/ ___ 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] bootm -- load_os inputs/outputs
So I proposed something like: bootm load_os bootm load_fdt so I figured trying to expand on what load_os does might be useful. input: ENV:bootm_low ENV:bootm_size BOOTMAP_SZ image specifier (a standalone uImage, a multi-uImage, a FIT specifier) output: ERROR: if image doesn't pass validity checks ERROR: (if image is compressed) error during decompression ERROR: if resulting decompress exceeds, bootm_size/BOOTMAP_SZ ERROR: if image load address is less than bootm_low ENV?: image OS type (LINUX, NETBSD, etc..) ENV?: LMB to keep track of memory regions used ENV?: entry point MEM: "raw memory image, decompressed, no header, etc." I think that's everything.. So my suggestion is to keep track of the image OS type, LMB, entry point via the existing global 'static bootm_headers_t images'. If this is not acceptable it means adding support to some how pass around the LMB info via env var. 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=100&url=/ ___ 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=100&url=/ ___ 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 [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=100&url=/ ___ 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=100&url=/ ___ 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: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=100&url=/ ___ 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:26 PM, Wolfgang Denk wrote: > In message > <[EMAIL PROTECTED]> you wrote: >> >>> 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. > > Agreed. But compare the benefit of such a soft recovery (versus a > reset of the board) against the added complexity and irregular user > interface - on this board you can write to low RAM, on the other board > you crash the system; on one board the system recovers after a failed > attempt to load a kernel, but maybe not always, just in certain cases, > on another board it always resets the board. > > KISS. Define a point of no return, and after that, recovery == reset. Its not about recovery. Its about using the mechanism to setup the memory state to run and than using another command to jump. In a dual core setup we can run u-boot on core0 and use all the bootm commands but 'jump' to setup the state of memory. Than we can use the 'cpu' command to 'release' core1 to run that OS. >>> 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. > > Why is this needed? We have customers that want to run at non-zero address. Think of a dual core chip with a custom OS that 0 and Linux running at 256M. (We allow this and have customers running in such situations). >>> "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? > > Yes, of course we did. It means exactly what's documented in the > manual. 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=100&url=/ ___ 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
>> 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 " 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
>> 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 (|-)
> " could be used for backward compatibility and "bootm
> " 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 "disa
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
>> 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 " 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
>> 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=100&url=/
___
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=100&url=/ ___ 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=100&url=/ ___ 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
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 " 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
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=100&url=/
___
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=100&url=/
___
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=100&url=/
___
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=100&url=/ ___ 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=100&url=/
___
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 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=100&url=/ ___ 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 [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=100&url=/ ___ 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=100&url=/
___
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/3] Add ePAPR boot command
Add a boot command that supports the ePAPR client interface on powerpc.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
lib_ppc/bootm.c | 63 +++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index a872d31..1182c50 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -821,3 +821,66 @@ 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;
+ }
+
+ kernel = (void (*)(ulong, ulong, ulong, ulong,
+ ulong, ulong, ulong))kern;
+
+ disable_interrupts();
+
+ /*
+* Linux Kernel Parameters (passing device tree):
+* 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)
+ epapr_magic = 0x45504150;
+#else
+ epapr_magic = 0x65504150;
+#endif
+
+ debug (" Booting using OF flat tree...\n");
+ (*kernel) (of_flat_tree, 0, 0, epapr_magic, CFG_BOOTMAPSZ, 0, 0);
+ /* does not return */
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ bootepapr, 3, 1, do_boot_epapr,
+ "bootepapr - boot according to ePAPR client interface\n",
+ " \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=100&url=/
___
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/3] ppc: 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=100&url=/
___
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=100&url=/ ___ 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",
+ " \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=100&url=/
___
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 4:40 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. >> >> 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. > > The current state of the bootm implementation is bad enough, but > adding such a callback opens just another few cans of worms. Sorry, > but I do not want to see that in mainline. I dont see how this is different than the proposal of moving to a script based mechanism for doing a large portion of what bootm does today. I get not wanting to add the the complexity that is bootm. But I dont think the script mechanism is the right answer either. - 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=100&url=/ ___ 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=100&url=/ ___ 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
#include
+#ifdef CFG_HUSH_PARSER
+#include
+#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=100&url=/
___
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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/
___
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
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=100&url=/
___
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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/
___
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 [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 >> 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=100&url=/ ___ 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 >> 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=100&url=/ ___ 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=100&url=/
___
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 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=100&url=/ ___ 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 >> [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=100&url=/
___
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=100&url=/
___
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=100&url=/ ___ 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
#include
+#ifdef CFG_HUSH_PARSER
+#include
+#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=100&url=/
___
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: U-Boot version numbering
On Aug 1, 2008, at 10:32 AM, Wolfgang Denk wrote: > Hello, > > I would like to get your general opinion about changing the U-Boot > version numbering scheme. > > To be honest, I never really understood myself how this is supposed > to work and if the next version should be 1.3.4 or 1.4.0 or 2.0.0, i. > e. which changes / additions are important enough to increment the > PATCHLEVEL or even VERSION number. > > I therefor suggest to drop this style of version numbering and change > to a timestamp based version number system which has been quite > successfully used by other projects (like Ubuntu) or is under > discussion (for Linux). > > My suggestion for the new version numbers is as follows: > > VERSION = 1 (at least for the time being) > > PATCHLEVEL = current year - 2000 > > SUBLEVEL = current month > > Both PATCHLEVEL and SUBLEVEL shall always be 2 digits (at least for > the next 91+ years to come) so listings for example on an FTP server > shall be in a sane sorting order. > > If we accept this system, the next release which probably comes out > in October 2008 would be v1.08.10, and assuming the one after that > comes out in January 2009 would be named v1.09.01 If we go to date based versions. I'd prefer we keep year as 4 digits: v1.2008.10 v1.2009.01 It just seems easier to me at a visual level when I look at try and compare versions. - 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=100&url=/ ___ 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=100&url=/ ___ 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 simple alias support to fdt print command
On Jul 9, 2008, at 12:02 PM, Jerry Van Baren wrote: > > Thinking out loud... we could define the syntax that a leading "*" > indicates the first part of the path is a dereference of /aliases. > > Assuming > /aliases/soc = /[EMAIL PROTECTED] > /aliases/ethernet0 = /[EMAIL PROTECTED]/.../enet0 > then > print *soc/enet0 > and > print *ethernet0 > would both work and print the right thing. You *would* have to know > that the first element of the path is an /aliases dereference. Your > original patch did not require that piece of knowledge (but silently > and automagically, which makes me nervous). did we come to resolution on this? I'd like to see this in 1.3.5. - 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=100&url=/ ___ 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=100&url=/
___
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: 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=100&url=/
___
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 @@ OUT
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=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[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 :
[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_re
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=100&url=/ ___ 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)) -#d
[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=100&url=/
___
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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/
___
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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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
[U-Boot-Users] [REPOST][PATCH 3/4] 85xx: Add some L1/L2 SPR register definitions
Add new L1/L2 SPRs related to e500mc cache config and control. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- include/asm-ppc/processor.h | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/include/asm-ppc/processor.h b/include/asm-ppc/processor.h index 10fd478..581ef52 100644 --- a/include/asm-ppc/processor.h +++ b/include/asm-ppc/processor.h @@ -426,6 +426,7 @@ /* e500 definitions */ #define SPRN_L1CFG00x203 /* L1 Cache Configuration Register 0 */ #define SPRN_L1CFG10x204 /* L1 Cache Configuration Register 1 */ +#define SPRN_L2CFG00x207 /* L2 Cache Configuration Register 0 */ #define SPRN_L1CSR00x3f2 /* L1 Data Cache Control and Status Register 0 */ #define L1CSR0_CPE 0x0001 /* Data Cache Parity Enable */ #define L1CSR0_DCFI 0x0002 /* Data Cache Flash Invalidate */ @@ -434,6 +435,21 @@ #define L1CSR1_CPE 0x0001 /* Instruction Cache Parity Enable */ #define L1CSR1_ICFI 0x0002 /* Instruction Cache Flash Invalidate */ #define L1CSR1_ICE 0x0001 /* Instruction Cache Enable */ +#define SPRN_L1CSR20x25e /* L1 Data Cache Control and Status Register 2 */ +#define SPRN_L2CSR00x3f9 /* L2 Data Cache Control and Status Register 0 */ +#define L2CSR0_L2E 0x8000 /* L2 Cache Enable */ +#define L2CSR0_L2PE 0x4000 /* L2 Cache Parity/ECC Enable */ +#define L2CSR0_L2WP 0x1c00 /* L2 I/D Way Partioning */ +#define L2CSR0_L2CM 0x0300 /* L2 Cache Coherency Mode */ +#define L2CSR0_L2FI 0x0020 /* L2 Cache Flash Invalidate */ +#define L2CSR0_L2IO 0x0010 /* L2 Cache Instruction Only */ +#define L2CSR0_L2DO 0x0001 /* L2 Cache Data Only */ +#define L2CSR0_L2REP 0x3000 /* L2 Line Replacement Algo */ +#define L2CSR0_L2FL 0x0800 /* L2 Cache Flush */ +#define L2CSR0_L2LFC 0x0400 /* L2 Cache Lock Flash Clear */ +#define L2CSR0_L2LOA 0x0080 /* L2 Cache Lock Overflow Allocate */ +#define L2CSR0_L2LO 0x0020 /* L2 Cache Lock Overflow */ +#define SPRN_L2CSR10x3fa /* L2 Data Cache Control and Status Register 1 */ #define SPRN_MMUCSR0 0x3f4 /* MMU control and status register 0 */ #define SPRN_MAS0 0x270 /* MMU Assist Register 0 */ @@ -624,8 +640,12 @@ #define MCSRR1 SPRN_MCSRR1 #define L1CSR0 SPRN_L1CSR0 #define L1CSR1 SPRN_L1CSR1 +#define L1CSR2 SPRN_L1CSR2 #define L1CFG0 SPRN_L1CFG0 #define L1CFG1 SPRN_L1CFG1 +#define L2CFG0 SPRN_L2CFG0 +#define L2CSR0 SPRN_L2CSR0 +#define L2CSR1 SPRN_L2CSR1 #define MCSR SPRN_MCSR #define MMUCSR0SPRN_MMUCSR0 #define BUCSR SPRN_BUCSR -- 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 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] [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
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] 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
[U-Boot-Users] HELP, trying to remove complier warnings
I'm running with gcc-4.3 from fedora 9. I get the following warnings: dlmalloc.c: In function ‘malloc_extend_top’: dlmalloc.c:1971: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:1999: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2029: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2031: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2042: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function ‘malloc’: dlmalloc.c:2245: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2245: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2253: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2258: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2263: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2318: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2327: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2329: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2344: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2356: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2360: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2362: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2363: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function ‘free’: dlmalloc.c:2431: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2444: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function ‘realloc’: dlmalloc.c:2594: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2599: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2604: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2605: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2637: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2646: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2647: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function ‘calloc’: dlmalloc.c:2896: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2897: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function ‘malloc_trim’: dlmalloc.c:2987: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2997: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3008: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3012: error: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3021: error: dereferencing type-punned pointer will break strict-aliasing rules They all result from the bin_at macro in the file. I can't seem to do anything to the code to get rid of them. I see these both on x86 or ppc host builds: x86: gcc -g -Os -m32-D__KERNEL__ -DTEXT_BASE=0x387c -I/local/home/ galak/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem / usr/lib/gcc/x86_64-redhat-linux/4.3.0/include -pipe -DCONFIG_I386 - D__I386__ -march=i386 -Werror -Wall -Wstrict-prototypes -fno-stack- protector -c -o dlmalloc.o dlmalloc.c ppc: gcc -g -Os -fPIC -ffixed-r14 -meabi -D__KERNEL__ - DTEXT_BASE=0xeff8 -I/local/home/galak/git/u-boot-85xx/include -fno- builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/ppc64-redhat- linux/4.3.0/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC85xx -DCONFIG_E500 -ffixed-r2 -Wa,-me500 -msoft-float -mno-string -mno-spe - DCONFIG_E500=1 -DCONFIG_MPC85xx=1 -DCONFIG_PPC_P4080=1 -Wall -Wstrict- prototypes -fno-stack-protector -c -o dlmalloc.o dlmalloc.c - 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 __
Re: [U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command
On Jul 9, 2008, at 10:17 AM, Jerry Van Baren wrote: > Kumar Gala wrote: >> 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]> > > Cool and useful too. Out of curiousity, does "real" Open Firmware > do this sort of thing with aliases? I'm pretty sure it the Apple OF implementation does. However I dont remember to what extent it does from my playing around with OF on Apple HW. > One reservation I have (which may disappear if the answer to the > previous question is "yes"), it automatically and silently > dereferences the /aliases/X node when asked to display /X or X (but > only if /X doesn't exist in the dtb). This is not an obvious > behavior since X isn't real. we could print out something about using an alias so the user knows that its happening. > Should we have a different display syntax to force the dereference > of an alias X? Assuming "*" is a good choice, this would change the > behavior > fdt print *ethernet0 > to dereference /aliases/ethernet0 and print out > /[EMAIL PROTECTED]/.../enet0 (or whatever). Lets says I have an alias for 'soc' to '[EMAIL PROTECTED]'. I want to be able to in the future do print /soc/enet0 and have that work. Introducing some new syntax would make that difficult and more ugly. - 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] 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
Re: [U-Boot-Users] [RFC][FSL DDR 0/8] Freescale DDR rewrit
On Jul 8, 2008, at 2:32 AM, David Saada wrote: > >> > < 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] variable type issues in LMB code
On Jul 7, 2008, at 10:57 AM, Wolfgang Denk wrote: > Dear Becky, > > in message <[EMAIL PROTECTED]> you > wrote: >> >> I see the following when I build for 8641HPCN on the latest tree: >> >> bootm.c: In function ‘do_bootm_linux’: >> bootm.c:208: warning: cast from pointer to integer of different size >> bootm.c:215: warning: cast from pointer to integer of different size > > That's what I see, too. I just posted a patch to fix these warnings. - 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] Fix compiler warnings
gcc-4.3.x generates the following:
bootm.c: In function 'do_bootm_linux':
bootm.c:208: warning: cast from pointer to integer of different size
bootm.c:215: warning: cast from pointer to integer of different size
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
lib_ppc/bootm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index 3c1c18b..1d8be4a 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -205,14 +205,14 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
for (j = 0; j < total; j++) {
fdt_get_mem_rsv(of_flat_tree, j, &addr, &size);
- if (addr == (uint64_t)of_flat_tree) {
+ if (addr == (uint64_t)(u32)of_flat_tree) {
fdt_del_mem_rsv(of_flat_tree, j);
break;
}
}
/* Delete the old LMB reservation */
- lmb_free(lmb, (uint64_t)of_flat_tree,
fdt_totalsize(of_flat_tree));
+ lmb_free(lmb, (uint64_t)(u32)of_flat_tree,
fdt_totalsize(of_flat_tree));
/* Calculate the actual size of the fdt */
actualsize = fdt_off_dt_strings(of_flat_tree) +
--
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] Squash warnings from pointer aliasing in dlmalloc
On Jul 5, 2008, at 5:32 PM, Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> > you wrote: >> When we building with gcc-4.3.x on a ppc host we get the following >> 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 > ... >> This is due to pointer aliasing that the dlmalloc code does and >> depends on. > > Can you please explain why the dlmalloc code depends on this? That's what Scott said when I asked about this on the list. > In my experience so far it has always been possible to avoid such > warnings by trivial changes to the code (the tricky part was usually > to understand what the exact problem was and what changes were > necessary). > >> Instead of trying trying to work around the warnings, we use the >> per file >> CFLAGs to disable the warnings via -fno-strict-aliasing. > > I tend to reject this patch. I would much rather have the problem > fixed in the sources. Hushing up compiler warnings has never been a > good idea. I'm all for trying to fix the code to git rid of the warnings, however nothing I tried was able to accomplish that. The root of the warnings is the bin_at() macro: #define bin_at(i) ((mbinptr)((char*)&(av_[2*(i) + 2]) - 2*SIZE_SZ)) #define next_bin(b)((mbinptr)((char*)(b) + 2 * sizeof(mbinptr))) #define prev_bin(b)((mbinptr)((char*)(b) - 2 * sizeof(mbinptr))) - 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] 85xx: extended cpu identification
On Jul 5, 2008, at 5:32 PM, Wolfgang Denk wrote: > In message [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] [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] 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] 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
> #include
> #include
> +#include
> #include
> #include
>
> @@ -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] 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] 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] 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
[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
Re: [U-Boot-Users] [PATCH v4] fdt: add crypto node handling for MPC8{3, 5}xxE processors
On Jun 16, 2008, at 3:55 PM, Kim Phillips wrote:
> Delete the crypto node if not on an E-processor. If on 8360 or 834x
> family,
> check rev and up-rev crypto node (to SEC rev. 2.4 property values)
> if on an 'EA' processor, e.g. MPC8349EA.
>
> Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
> ---
> diff from v3: prepended "Delete the" to the patch commit message.
> mumble. Thanks gvb.
>
> common/fdt_support.c| 87 ++
> +
> cpu/mpc83xx/fdt.c | 18 +
> cpu/mpc85xx/fdt.c |5 ++
> include/asm-ppc/processor.h |9
> include/fdt_support.h |6 +++
> include/mpc83xx.h |7 +++-
> 6 files changed, 131 insertions(+), 1 deletions(-)
Can you fixup cpu/mpc85xx/cpu.c:
if (svr & 0x8)
puts("E");
to be
if (IS_E_PROCESSOR(svr)
puts("E");
- 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] 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
