Re: [U-Boot] Debugging u-boot with bdi3000 basics
Dear Alan Carvalho de Assis, In message aanlktik4fypdak9bhvkzrndmvuyccg-xdabqtkqyz...@mail.gmail.com you wrote: Hi Mark, On 5/27/10, Mark Fanara mark.fan...@gmail.com wrote: ... 2) I am using a bdi3000. Is there no way to build u-boot so that it is directly loaded to RAM by the debugger and does not relocate itself? #define CONFIG_SKIP_RELOCATE_UBOOT Note that this doesn't exist on ll architectures. For example on PowerPC, we will always relocate. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Die ganzen Zahlen hat der liebe Gott geschaffen, alles andere ist Menschenwerk... Leopold Kronecker ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Timur Tabi, In message 4bfd837d.2040...@freescale.com you wrote: Wolfgang Denk wrote: It appears you really haven't bothered checking. We have been using it on PowerPC since day 1 - for well over 10 years by now. On many, many systems. Get a clue! I've looked at get_ram_size(), and I don't think I can use it. Then fix it, please. We use phys_addr_t to represent DDR sizes, which is a 64-bit integer on the P1022DS. get_ram_size() takes a 'long' and returns a 'long', so it's not capable of handling the amount of memory that we support on the board. I can use get_ram_size() to test the lower 2GB of DDR, but I can't use it to verify the amount of RAM in the system. Do you really have 4 GB RAM on this board? If this turns out to be a real problem, we have to fix get_ram_size to handle bigger memory sizes as well. I guess this will needed for more and more systems. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If something is different, it's either better or worse, and usually both.- Larry Wall ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
Dear Kumar Gala, In message 1274433478-31849-2-git-send-email-ga...@kernel.crashing.org you wrote: The new is_serdes_configured covers a broader range of devices than the PCI specific code. Use it instead as we convert away from the is_fsl_pci_cfg() code. Additionally move to setting LAWs for PCI based on if its configured. Also updated PCI FDT fixup code to remove PCI controllers from dtb if they are not configured. ... #ifdef CONFIG_PCIE3 ft_fsl_pci_setup(blob, pci0, pcie3_hose); +#else + ft_fsl_pci_setup(blob, pci0, NULL); #endif #ifdef CONFIG_PCIE2 ft_fsl_pci_setup(blob, pci1, pcie2_hose); +#else + ft_fsl_pci_setup(blob, pci1, NULL); #endif #ifdef CONFIG_PCIE1 ft_fsl_pci_setup(blob, pci2, pcie1_hose); +#else + ft_fsl_pci_setup(blob, pci2, NULL); #endif As Timur already pointed out: can we please clean up this mess of 3 = 0 = 3, 2 = 1 = 2, 1 = 2 = 1? This is extremely confusing. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de He had been eight years upon a project for extracting sunbeams out of cucumbers, which were to be put in vials hermetically sealed, and let out to warm the air in raw inclement summers.- Jonathan Swift _Gulliver's Travels_ ``A Voyage to Laputa, etc.'' ch. 5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
On May 27, 2010, at 2:08 AM, Wolfgang Denk wrote: Dear Kumar Gala, In message 1274433478-31849-2-git-send-email-ga...@kernel.crashing.org you wrote: The new is_serdes_configured covers a broader range of devices than the PCI specific code. Use it instead as we convert away from the is_fsl_pci_cfg() code. Additionally move to setting LAWs for PCI based on if its configured. Also updated PCI FDT fixup code to remove PCI controllers from dtb if they are not configured. ... #ifdef CONFIG_PCIE3 ft_fsl_pci_setup(blob, pci0, pcie3_hose); +#else +ft_fsl_pci_setup(blob, pci0, NULL); #endif #ifdef CONFIG_PCIE2 ft_fsl_pci_setup(blob, pci1, pcie2_hose); +#else +ft_fsl_pci_setup(blob, pci1, NULL); #endif #ifdef CONFIG_PCIE1 ft_fsl_pci_setup(blob, pci2, pcie1_hose); +#else +ft_fsl_pci_setup(blob, pci2, NULL); #endif As Timur already pointed out: can we please clean up this mess of 3 = 0 = 3, 2 = 1 = 2, 1 = 2 = 1? This is extremely confusing. This is my fault. However not sure what to do about it since we'd break compatibility with kernel .dts to clean this up. 99% of the u-boot code should match the HW docs. In this one place I tried to rename things such that it made sense. The pci aliases in the .dts are in order of address (so whatever HW controller is @ 0x8000 would be pci0, 0x9000 - pci1, etc.) - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Debugging u-boot with bdi3000 basics
Dear Wolfgang Denk, Yes, it is true. Currently only for ARMs and i386. Best Regards, Alan On 5/27/10, Wolfgang Denk w...@denx.de wrote: Dear Alan Carvalho de Assis, In message aanlktik4fypdak9bhvkzrndmvuyccg-xdabqtkqyz...@mail.gmail.com you wrote: Hi Mark, On 5/27/10, Mark Fanara mark.fan...@gmail.com wrote: ... 2) I am using a bdi3000. Is there no way to build u-boot so that it is directly loaded to RAM by the debugger and does not relocate itself? #define CONFIG_SKIP_RELOCATE_UBOOT Note that this doesn't exist on ll architectures. For example on PowerPC, we will always relocate. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Die ganzen Zahlen hat der liebe Gott geschaffen, alles andere ist Menschenwerk... Leopold Kronecker ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Getting Exception Error while running u-boot from Context-RAM
Hi All, Can I expect a reply from seniors who might have faced this kind of issue? If anyone have faced this kind of issue earlier. Please reply. Thanks in advance. Regards, Prakash On Tue, May 25, 2010 at 12:45 PM, prakash bedge praka sh.be...@gmail.com wrote: Hi, I am using u-boot as Bootloader for my PPC440 core based hardware board. I am trying to run the u-boot code from Context RAM (Size 4 MB) instead of DDR and I am successful in it. But I am observing a machine check exception error while doing board hard reset (by pressing the reset key on board). When I do the Core reset or Chip reset using BDI3000 debugger, I am not getting any exception error. But when I press the reset key on board, I am getting an machine check exception error and my board reboots always and continue to generate the exception error. One thing I noted that, when I shutdown the board system and again restarts the board, then everything is fine and this time I am not getting the exception error. I am little bit confused because of this abnormal behavior. I believe this issue might be relevant with memory allocation. I am getting error after this statement mem_malloc_init (), in lib_ppc/board.c file Code snippet (lib_ppc/board.c) | | asm (sync ; isync); /* initialize malloc() area */ *mem_malloc_init ();* malloc_bin_reloc (); #if !defined(CONFIG_SYS_NO_FLASH) puts (FLASH: ); | | If anyone has faced this kind of problem earlier, please share your experience. Thanks Regards, Prakash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
Dear Kumar Gala, In message 5f58de0b-6ef8-4ed6-a1a8-c0e37c853...@kernel.crashing.org you wrote: This is my fault. However not sure what to do about it since we'd break compatibility with kernel .dts to clean this up. 99% of the u-boot code should match the HW docs. In this one place I tried to rename things such that it made sense. The pci aliases in the .dts are in order of address (so whatever HW controller is @ 0x8000 would be pci0, 0x9000 - pci1, etc.) This doesn't seem to be the case in U-Boot; here we see: #define CONFIG_SYS_PCIE3_ADDR (CONFIG_SYS_CCSRBAR+0x8000) #define CONFIG_SYS_PCIE2_ADDR (CONFIG_SYS_CCSRBAR+0x9000) #define CONFIG_SYS_PCIE1_ADDR (CONFIG_SYS_CCSRBAR+0xa000) i. e. the highest number is at the lowest address?? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The easiest way to figure the cost of living is to take your income and add ten percent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Debugging u-boot with bdi3000 basics
As my target board is PowerPC based (and therefore skipping relocation is not possible), I need help with my previously enumerated questions. 1) In section 10.4, Tips and Tricks, it says To prevent GDB from jumping around in the code when trying to single step, i. e. when it seems as if the code is not executing line by line, you can recompile your code with the following additional compiler options: -fno-schedule-insns -fno-schedule-insns In the u-boot developer world, what is the best practice for adding these compiler options? I see CFLAGS in config.mk and assume that is what needs to be modified. However, I need a HOWTODOITRIGHT 3) The function board_init_f() in board.c makes calls to debug(). I cannot determine how to enable debug() output. I saw one reference in the manual, but it gave no specifics. On Thu, May 27, 2010 at 4:07 AM, Alan Carvalho de Assis acas...@gmail.com wrote: Dear Wolfgang Denk, Yes, it is true. Currently only for ARMs and i386. Best Regards, Alan On 5/27/10, Wolfgang Denk w...@denx.de wrote: Dear Alan Carvalho de Assis, In message aanlktik4fypdak9bhvkzrndmvuyccg-xdabqtkqyz...@mail.gmail.com you wrote: Hi Mark, On 5/27/10, Mark Fanara mark.fan...@gmail.com wrote: ... 2) I am using a bdi3000. Is there no way to build u-boot so that it is directly loaded to RAM by the debugger and does not relocate itself? #define CONFIG_SKIP_RELOCATE_UBOOT Note that this doesn't exist on ll architectures. For example on PowerPC, we will always relocate. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Die ganzen Zahlen hat der liebe Gott geschaffen, alles andere ist Menschenwerk... Leopold Kronecker ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
On May 27, 2010, at 6:20 AM, Wolfgang Denk wrote: Dear Kumar Gala, In message 5f58de0b-6ef8-4ed6-a1a8-c0e37c853...@kernel.crashing.org you wrote: This is my fault. However not sure what to do about it since we'd break compatibility with kernel .dts to clean this up. 99% of the u-boot code should match the HW docs. In this one place I tried to rename things such that it made sense. The pci aliases in the .dts are in order of address (so whatever HW controller is @ 0x8000 would be pci0, 0x9000 - pci1, etc.) This doesn't seem to be the case in U-Boot; here we see: #define CONFIG_SYS_PCIE3_ADDR (CONFIG_SYS_CCSRBAR+0x8000) #define CONFIG_SYS_PCIE2_ADDR (CONFIG_SYS_CCSRBAR+0x9000) #define CONFIG_SYS_PCIE1_ADDR (CONFIG_SYS_CCSRBAR+0xa000) i. e. the highest number is at the lowest address?? Correct, that is matching FSL HW docs numbering/naming. in the .dts the alias: * pci0 is @ 0x8000- FSL HW calls it PCIE3 * pci1 is @ 0x9000- FSL HW calls it PCIE2 * pci2 is @ 0xa000- FSL HW calls it PCIE1 - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Debugging u-boot with bdi3000 basics
Dear Mark Fanara, In message aanlktina8o1otqi93hyazu2udg4qbzzrkt3ql3ip9...@mail.gmail.com you wrote: As my target board is PowerPC based (and therefore skipping relocation is not possible), I need help with my previously enumerated questions. 1) In section 10.4, Tips and Tricks, it says To prevent GDB from jumping around in the code when trying to single step, i. e. when it seems as if the code is not executing line by line, you can recompile your code with the following additional compiler options: -fno-schedule-insns -fno-schedule-insns In the u-boot developer world, what is the best practice for adding these compiler options? I see CFLAGS in config.mk and assume that is what needs to be modified. However, I need a HOWTODOITRIGHT There is many ways to do this. You may or mayu not want to compile all files with this option, so you may add it to the glocal CFLAGS, or just locally in a subdirectory, or manually provide it on the command line, or Ther eis no single right way. 3) The function board_init_f() in board.c makes calls to debug(). I cannot determine how to enable debug() output. I saw one reference in the manual, but it gave no specifics. You just #define DEBUG before the first #include in that file. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Men will always be men -- no matter where they are. -- Harry Mudd, Mudd's Women, stardate 1329.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
Dear Kumar Gala, In message 7d2ba6a1-2eef-4bf5-8b76-07ad55537...@kernel.crashing.org you wrote: i. e. the highest number is at the lowest address?? Correct, that is matching FSL HW docs numbering/naming. in the .dts the alias: * pci0 is @ 0x8000 - FSL HW calls it PCIE3 * pci1 is @ 0x9000 - FSL HW calls it PCIE2 * pci2 is @ 0xa000 - FSL HW calls it PCIE1 IMHO there were several decisions that I would not exactly call intelligent - the first to assign HW names in descending order, and the second to chose a different order for the bus names. Now we sit here and have to suffer from this :-( Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious defi- ciencies. - Charles Anthony Richard Hoare ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Bootoloader remote automation
Hi all, I would like to automate the kernel and filesystem loading using the u-boot instructions. Basically, I would start the loading process from a remote system such as a pc computer for example, and then take some actions depending of the log this pc would receive from the target. Is there a way to make the u-boot to send some logs to the remote system telling if the image was succesfully loaded or not so, with this information, the remote system could create a log that would telll the operator about the procedure situation for example? Thanks in advance and best regards Pet harp ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bootoloader remote automation
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Pet Harp Sent: Thursday, May 27, 2010 7:12 PM To: u-boot@lists.denx.de Subject: [U-Boot] Bootoloader remote automation Hi all, I would like to automate the kernel and filesystem loading using the u-boot instructions. Basically, I would start the loading process from a remote system such as a pc computer for example, and then take some actions depending of the log this pc would receive from the target. Is there a way to make the u-boot to send some logs to the remote system telling if the image was succesfully loaded or not so, with this information, the remote system could create a log that would telll the operator about the procedure situation for example? You can check/use netconsole feature within u-boot for this. You can search for for pxeboot and check if it is applicable in your case Regards.. Prafulla . . Thanks in advance and best regards Pet harp ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Wolfgang Denk wrote: I've looked at get_ram_size(), and I don't think I can use it. Then fix it, please. Let me guess, you won't accept my patch until I fix get_ram_size() first and use it, right? We use phys_addr_t to represent DDR sizes, which is a 64-bit integer on the P1022DS. get_ram_size() takes a 'long' and returns a 'long', so it's not capable of handling the amount of memory that we support on the board. I can use get_ram_size() to test the lower 2GB of DDR, but I can't use it to verify the amount of RAM in the system. Do you really have 4 GB RAM on this board? Actually, anything more than 2GB would cause the problem, since the maximum value of a long is 2GB. On this particular board, there is only 2GB, but all of our new boards are expected to support more than 4GB of RAM. If this turns out to be a real problem, we have to fix get_ram_size to handle bigger memory sizes as well. I guess this will needed for more and more systems. Yes. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
On May 27, 2010, at 8:20 AM, Wolfgang Denk wrote: Dear Kumar Gala, In message 7d2ba6a1-2eef-4bf5-8b76-07ad55537...@kernel.crashing.org you wrote: i. e. the highest number is at the lowest address?? Correct, that is matching FSL HW docs numbering/naming. in the .dts the alias: * pci0 is @ 0x8000 - FSL HW calls it PCIE3 * pci1 is @ 0x9000 - FSL HW calls it PCIE2 * pci2 is @ 0xa000 - FSL HW calls it PCIE1 IMHO there were several decisions that I would not exactly call intelligent - the first to assign HW names in descending order, and the second to chose a different order for the bus names. Now we sit here and have to suffer from this :-( Agree on both fronts. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bootoloader remote automation
Dear Pet Harp,
In message aanlktikgrqxjj_6qigxaueu-exdyqlsq5pmvall1w...@mail.gmail.com you
wrote:
I would like to automate the kernel and filesystem loading using the u-boot
instructions.
No problem. This has been done many, many times before, including
completely automatic production systems.
Basically, I would start the loading process from a remote system such as a
pc computer for example, and then take some actions depending of the log
this pc would receive from the target.
Is there a way to make the u-boot to send some logs to the remote system
telling if the image was succesfully loaded or not so, with this
information, the remote system could create a log that would telll the
operator about the procedure situation for example?
The standard tool to do things like these is expect; in the trivial
case (without the usually needed error checking) this results in
expect scripts like this:
send -s setenv serial# $serial\r
expect =
send -s setenv ethaddr $ethaddr\r
expect =
send -s saveenv\r
expect =
send -s setenv preboot 'echo;echo Type \run flash_nfs\ to
mount root filesystem over NFS;echo'\r
expect =
send -s setenv nfsargs 'setenv bootargs root=/dev/nfs rw
nfsroot=\${serverip}:\${rootpath}'\r
expect =
send -s setenv ramargs setenv bootargs root=/dev/ram rw\r
expect =
...
send -s setenv ipaddr $TARGET_IP\r
expect =
send -s setenv netmask $NETMASK\r
expect =
send -s setenv netdev eth0\r
expect =
send -s setenv hostname $HOSTNAME\r
expect =
send -s setenv serverip $SERVER_IP\r
expect =
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The pathology is to want control, not that you ever get it, because
of course you never do.- Gregory Bateson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
get_ram_size() used to use long data types for addresses and data,
which in limited it to systems with less than 4 GiB memory. As more
and more systems are coming up with bigger memory resources, we adapt
the code to use phys_addr_t / phys_size_t data types instead.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Timur Tabi ti...@freescale.com
---
Note: this is only minimally tested - I just compiled a dozen of ppc
boards with it without appearent problems. Please review and test
carefully.
common/memsize.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/common/memsize.c b/common/memsize.c
index 6c275c9..b99e51b 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -37,14 +37,14 @@
* the actually available RAM size between addresses `base' and
* `base + maxsize'.
*/
-long get_ram_size(volatile long *base, long maxsize)
+phys_size_t get_ram_size(volatile phys_addr_t *base, phys_size_t maxsize)
{
- volatile long *addr;
- long save[32];
- long cnt;
- long val;
- long size;
- inti = 0;
+ volatile phys_addr_t *addr;
+ phys_size_t save[32];
+ phys_size_t cnt;
+ phys_size_t val;
+ phys_size_t size;
+ int i = 0;
for (cnt = (maxsize / sizeof (long)) 1; cnt 0; cnt = 1) {
addr = base + cnt; /* pointer arith! */
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Timur Tabi, In message 4bfe823a.1080...@freescale.com you wrote: I've looked at get_ram_size(), and I don't think I can use it. Then fix it, please. Let me guess, you won't accept my patch until I fix get_ram_size() first and use it, right? Do you think this is an unreasonable request? A quick fix takes me less than it takes to write this email (see following patch). Do you really have 4 GB RAM on this board? Actually, anything more than 2GB would cause the problem, since the maximum value of a long is 2GB. On this particular board, there is only 2GB, but all of our new boards are expected to support more than 4GB of RAM. All the more reasons to fix this. If this turns out to be a real problem, we have to fix get_ram_size to handle bigger memory sizes as well. I guess this will needed for more and more systems. Yes. Well, didn't you say you were looking for a list of task to imrpove U-Boot for your boards? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Gods don't like people not doing much work. People who aren't busy all the time might start to _think_. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
get_ram_size() used to use long data types for addresses and data,
which limited it to systems with less than 4 GiB memory. As more and
more systems are coming up with bigger memory resources, we adapt the
code to use phys_addr_t / phys_size_t data types instead.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Timur Tabi ti...@freescale.com
---
Note: this is only minimally tested - I just compiled a dozen of ppc
boards with it without appearent problems. Please review and test
carefully.
v2: - fix commit message
- change function prototype, too.
common/memsize.c | 14 +++---
include/common.h |2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/common/memsize.c b/common/memsize.c
index 6c275c9..b99e51b 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -37,14 +37,14 @@
* the actually available RAM size between addresses `base' and
* `base + maxsize'.
*/
-long get_ram_size(volatile long *base, long maxsize)
+phys_size_t get_ram_size(volatile phys_addr_t *base, phys_size_t maxsize)
{
- volatile long *addr;
- long save[32];
- long cnt;
- long val;
- long size;
- inti = 0;
+ volatile phys_addr_t *addr;
+ phys_size_t save[32];
+ phys_size_t cnt;
+ phys_size_t val;
+ phys_size_t size;
+ int i = 0;
for (cnt = (maxsize / sizeof (long)) 1; cnt 0; cnt = 1) {
addr = base + cnt; /* pointer arith! */
diff --git a/include/common.h b/include/common.h
index 8bca04f..648e00f 100644
--- a/include/common.h
+++ b/include/common.h
@@ -316,7 +316,7 @@ const char *symbol_lookup(unsigned long addr, unsigned long
*caddr);
void api_init (void);
/* common/memsize.c */
-long get_ram_size (volatile long *, long);
+phys_size_t get_ram_size(volatile phys_addr_t *, phys_size_t);
/* $(BOARD)/$(BOARD).c */
void reset_phy (void);
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
On Thu, May 27, 2010 at 1:11 PM, Wolfgang Denk w...@denx.de wrote:
get_ram_size() used to use long data types for addresses and data,
which in limited it to systems with less than 4 GiB memory. As more
and more systems are coming up with bigger memory resources, we adapt
the code to use phys_addr_t / phys_size_t data types instead.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Timur Tabi ti...@freescale.com
---
The problem is that on all of our PowerPC boards, the TLBs only map
the lower 2GB of memory, regardless as to how much is present. So we
still can't use get_ram_size() to determine how much memory is in the
system, because any attempt to access memory higher than 2GB will
fail.
And even if we did have TLBs for all of memory, an attempt to access
RAM that doesn't exist will cause a machine check, which will hang
U-Boot. So we still couldn't use get_ram_size() to determine how much
RAM actually exists.
-long get_ram_size(volatile long *base, long maxsize)
+phys_size_t get_ram_size(volatile phys_addr_t *base, phys_size_t maxsize)
I don't think you want 'base' to be a pointer to phys_addr_t, because
the pointer type determines how much is read/written in a single
operation. I don't think you want to be doing 64-bit reads and
writes.
Plus, you still have this:
for (cnt = (maxsize / sizeof (long)) 1; cnt 0; cnt = 1) {
addr = base + cnt; /* pointer arith! */
sync ();
save[i++] = *addr;
sync ();
*addr = ~cnt;
}
I'm not quite sure what this loop is doing, but I have a suspicion the
sizeof(long) does not match with phys_addr_t *base.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Wolfgang Denk wrote: Do you think this is an unreasonable request? A quick fix takes me less than it takes to write this email (see following patch). Fixing get_ram_size() is not a quick fix. We would need to implement a temporary TLB mechanism for accessing memory above 2GB, and a machine check handler for handling memory access to non-existent RAM. If this turns out to be a real problem, we have to fix get_ram_size to handle bigger memory sizes as well. I guess this will needed for more and more systems. Yes. Well, didn't you say you were looking for a list of task to imrpove U-Boot for your boards? True. But I also want to get real work done in a timely manner. It's taking a lot longer than I expected to get support for this board approved. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
On Thu, May 27, 2010 at 01:25:38PM -0500, Timur Tabi wrote: Wolfgang Denk wrote: Do you think this is an unreasonable request? A quick fix takes me less than it takes to write this email (see following patch). Fixing get_ram_size() is not a quick fix. We would need to implement a temporary TLB mechanism for accessing memory above 2GB, and a machine check handler for handling memory access to non-existent RAM. Passing the actual, known size of RAM (why guess when we know?) as maxsize should eliminate the machine check problem[1] -- you'd just be using it as a not particularly exhaustive memory tester. I don't see why it should be mandatory. It also doesn't handle non-power-of-two sized memory -- don't rely on the value it returns. -Scott [1] It's worse than machine checks, what if some I/O device is mapped directly after RAM? IIRC people have run into this sort of problem doing this type of memory sizing on PCs. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: fix create_pipe()
Hi, 2010/5/26 Sergei Shtylyov sshtyl...@ru.mvista.com: create_pipe() can give wrong result if an expression is passed as the 'endpoint' argument -- due to missing parentheses. Thanks to Martin Mueller for finding the bug and providing the patch. Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com --- include/usb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-usb Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Scott Wood wrote: Passing the actual, known size of RAM (why guess when we know?) as maxsize should eliminate the machine check problem[1] -- you'd just be using it as a not particularly exhaustive memory tester. I don't see why it should be mandatory. The purpose of get_ram_size() is to verify the known size of RAM. That is, once you think you know how much RAM there is, you ask get_ram_size() to verify that claim. The return value is the true, validated amount of RAM. It also doesn't handle non-power-of-two sized memory -- don't rely on the value it returns. Ah, that's a serious limitation. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-usb
The following changes since commit 01f03bda5b22e5aeae5f02fd537da97a41485c73: Wolfgang Denk (1): Prepare v2010.06-rc1 are available in the git repository at: git://git.denx.de/u-boot-usb.git master Sergei Shtylyov (1): USB: fix create_pipe() include/usb.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
On 05/27/2010 02:07 PM, Timur Tabi wrote: Scott Wood wrote: Passing the actual, known size of RAM (why guess when we know?) as maxsize should eliminate the machine check problem[1] -- you'd just be using it as a not particularly exhaustive memory tester. I don't see why it should be mandatory. The purpose of get_ram_size() is to verify the known size of RAM. That is, once you think you know how much RAM there is, you ask get_ram_size() to verify that claim. It would still (sort of) verify that you don't have less than you claim. Attempting to experimentally determine whether you have more than you claim is dangerous. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
On Thu, May 27, 2010 at 07:45:16AM -0500, Kumar Gala wrote: On May 27, 2010, at 6:20 AM, Wolfgang Denk wrote: Dear Kumar Gala, In message 5f58de0b-6ef8-4ed6-a1a8-c0e37c853...@kernel.crashing.org you wrote: This is my fault. However not sure what to do about it since we'd break compatibility with kernel .dts to clean this up. 99% of the u-boot code should match the HW docs. In this one place I tried to rename things such that it made sense. The pci aliases in the .dts are in order of address (so whatever HW controller is @ 0x8000 would be pci0, 0x9000 - pci1, etc.) This doesn't seem to be the case in U-Boot; here we see: #define CONFIG_SYS_PCIE3_ADDR (CONFIG_SYS_CCSRBAR+0x8000) #define CONFIG_SYS_PCIE2_ADDR (CONFIG_SYS_CCSRBAR+0x9000) #define CONFIG_SYS_PCIE1_ADDR (CONFIG_SYS_CCSRBAR+0xa000) i. e. the highest number is at the lowest address?? Correct, that is matching FSL HW docs numbering/naming. in the .dts the alias: * pci0 is @ 0x8000 - FSL HW calls it PCIE3 * pci1 is @ 0x9000 - FSL HW calls it PCIE2 * pci2 is @ 0xa000 - FSL HW calls it PCIE1 This is why the dts files should live with u-boot, not Linux... but if we can't change the dts file, we could ignore the aliases and look up PCI controllers by address. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
Dear Timur Tabi,
In message aanlktilrfhtwnqgqx9nvmplabl8hpiszy97hkk73-...@mail.gmail.com you
wrote:
On Thu, May 27, 2010 at 1:11 PM, Wolfgang Denk w...@denx.de wrote:
get_ram_size() used to use long data types for addresses and data,
which in limited it to systems with less than 4 GiB memory. As more
and more systems are coming up with bigger memory resources, we adapt
the code to use phys_addr_t / phys_size_t data types instead.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Timur Tabi ti...@freescale.com
---
The problem is that on all of our PowerPC boards, the TLBs only map
the lower 2GB of memory, regardless as to how much is present. So we
still can't use get_ram_size() to determine how much memory is in the
system, because any attempt to access memory higher than 2GB will
fail.
Now this is your problem, then, and you should kno how to fix it.
And even if we did have TLBs for all of memory, an attempt to access
RAM that doesn't exist will cause a machine check, which will hang
U-Boot. So we still couldn't use get_ram_size() to determine how much
RAM actually exists.
Please see how it's done on all other PowerPC systems, and do similar.
-long get_ram_size(volatile long *base, long maxsize)
+phys_size_t get_ram_size(volatile phys_addr_t *base, phys_size_t maxsize)
I don't think you want 'base' to be a pointer to phys_addr_t, because
the pointer type determines how much is read/written in a single
operation. I don't think you want to be doing 64-bit reads and
writes.
I don't know your mnemory bus. This is an RFC patch.
Plus, you still have this:
for (cnt = (maxsize / sizeof (long)) 1; cnt 0; cnt = 1) {
addr = base + cnt; /* pointer arith! */
sync ();
save[i++] = *addr;
sync ();
*addr = ~cnt;
}
I'm not quite sure what this loop is doing, but I have a suspicion the
sizeof(long) does not match with phys_addr_t *base.
Right. This needs to be fixed.
Thanks for pointing out.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
... freedom ... is a worship word...
It is our worship word too.
-- Cloud William and Kirk, The Omega Glory, stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Timur Tabi, In message 4bfeb922.9040...@freescale.com you wrote: Do you think this is an unreasonable request? A quick fix takes me less than it takes to write this email (see following patch). Fixing get_ram_size() is not a quick fix. We would need to implement a temporary TLB mechanism for accessing memory above 2GB, and a machine check handler for handling memory access to non-existent RAM. We don't have machine check handlers on the other PPC systems either. We kust make sure that the mapping is big enough for the maximal RAM size we are going to test. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You've no idea of what a poor opinion I have of myself, and how little I deserve it. - W. S. Gilbert ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
On Thu, May 27, 2010 at 08:16:28PM +0200, Wolfgang Denk wrote: get_ram_size() used to use long data types for addresses and data, which limited it to systems with less than 4 GiB memory. As more and more systems are coming up with bigger memory resources, we adapt the code to use phys_addr_t / phys_size_t data types instead. This cannot work as is. The only systems where this makes a difference are where physical addresses are larger than virtual pointers -- but you try to shove the 64-bit physical offset into a 32-bit pointer. You need to create temporary mappings, if you really want to do this. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
Dear Wolfgang Wegner, In message 20100527185909.gg31...@leila.ping.de you wrote: as the systems I was working on always had far less memory, I can not comment much on the extension you propose here, but as Timur Tabi's comments seem to go in a direction which could lead to a bigger overhaul/discussion, I would like to add 2C from my point of view on coldfire... - MCF53xx/MCF5445x both simply lock up if non-existent memory is accessed. So if the SDRAM controller is set up for a too big size of memory, get_ram_size() will fail. I assume this applies to most coldfire devices. The design of get_ram_size() is based on the assumption that you start with a big enough mapping. Usually we map twice the maximum possible size that actually can be fit. - How about systems/configurations using CONFIG_MONITOR_IS_IN_RAM? Here you obviously cannot use this. What some ARM systems are doing right now is plain wrong. get_ram_size() must always and only be called _before_ the code is running from RAM. - at least in the coldfire world, CONFIG_SYS_SDRAM_SIZE is quite often used for cache setup in the assembly code. This contradicts changing/setting the SDRAM size at runtime... You may want to change this :-) Note that we have plans underway to rework the ARM architecture to do proper relocation including auto-sizing of the RAM. Other architectures are invited to follow. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Never underestimate the bandwidth of a station wagon full of tapes. -- Dr. Warren Jackson, Director, UTCS ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Scott Wood, In message 20100527190340.ga5...@schlenkerla.am.freescale.net you wrote: Passing the actual, known size of RAM (why guess when we know?) as maxsize should eliminate the machine check problem[1] -- you'd just be using it as a not particularly exhaustive memory tester. I don't see why it should be mandatory. Typically we chose maxsize to b twice the actual possible maximum to allow for real testing. It also doesn't handle non-power-of-two sized memory -- don't rely on the value it returns. Such configurations are usually set up of from several differently sized banks of memory, and get_ram_size() is always run per bank. So as long as chip manufacturers continue to make RAM chips with power-of-two sizes only, everything should be fine. [1] It's worse than machine checks, what if some I/O device is mapped directly after RAM? IIRC people have run into this sort of problem doing this type of memory sizing on PCs. Well, let's call this a bug in setting up the memory map for the system ;-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When you say I wrote a program that crashed Windows, people just stare at you blankly and say Hey, I got those with the system, *for free*.- Linus Torvalds in 3itc77$...@ninurta.fer.uni-lj.si ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Timur Tabi, In message 4bfec2fd.5050...@freescale.com you wrote: It also doesn't handle non-power-of-two sized memory -- don't rely on the value it returns. Ah, that's a serious limitation. No, it is not. Testing is done per bank. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I was playing poker the other night... with Tarot cards. I got a full house and 4 people died. - Steven Wright ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Wolfgang Denk wrote: We don't have machine check handlers on the other PPC systems either. We kust make sure that the mapping is big enough for the maximal RAM size we are going to test. What if the mapping is too big? Isn't the whole point of get_ram_size() that there is less RAM than we say there is? That is, if there's only 1GB of RAM, and we do this: dram_size = get_ram_size(0, 2GB); That get_ram_size() will return 1GB? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Scott Wood, In message 4bfec39e.7040...@freescale.com you wrote: Attempting to experimentally determine whether you have more than you claim is dangerous. It's not. Actually it allows to detect certain classes of errors. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A modem is a baudy house. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
Dear Scott Wood, In message 20100527194618.gc5...@schlenkerla.am.freescale.net you wrote: On Thu, May 27, 2010 at 08:16:28PM +0200, Wolfgang Denk wrote: get_ram_size() used to use long data types for addresses and data, which limited it to systems with less than 4 GiB memory. As more and more systems are coming up with bigger memory resources, we adapt the code to use phys_addr_t / phys_size_t data types instead. This cannot work as is. The only systems where this makes a difference are where physical addresses are larger than virtual pointers -- but you try to shove the 64-bit physical offset into a 32-bit pointer. You need to create temporary mappings, if you really want to do this. ? Isn't phys_addr_t assumed to be the right data type to hold a physical address? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de And it should be the law: If you use the word `paradigm' without knowing what the dictionary says it means, you go to jail. No exceptions. - David Jones @ Megatest Corporation ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
On 05/27/2010 02:57 PM, Wolfgang Denk wrote: Dear Scott Wood, In message20100527194618.gc5...@schlenkerla.am.freescale.net you wrote: On Thu, May 27, 2010 at 08:16:28PM +0200, Wolfgang Denk wrote: get_ram_size() used to use long data types for addresses and data, which limited it to systems with less than 4 GiB memory. As more and more systems are coming up with bigger memory resources, we adapt the code to use phys_addr_t / phys_size_t data types instead. This cannot work as is. The only systems where this makes a difference are where physical addresses are larger than virtual pointers -- but you try to shove the 64-bit physical offset into a 32-bit pointer. You need to create temporary mappings, if you really want to do this. ? Isn't phys_addr_t assumed to be the right data type to hold a physical address? Yes. But you can't dereference a physical address directly. When you do addr = base + cnt, you're throwing away the upper 32 bits. phys_addr_t * is not a 64-bit pointer, it is a 32-bit pointer to a 64-bit quantity. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Timur Tabi, In message 4bfecdf7.4070...@freescale.com you wrote: What if the mapping is too big? Isn't the whole point of get_ram_size() that there is less RAM than we say there is? That is, if there's only 1GB of RAM, and we do this: get_ram_size() will also detect a number of hardware problems list stuck / swapped / mirrored address lines etc. (actually a pretty large percentage of the real world hardware problems). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I think it's a new feature. Don't tell anyone it was an accident. :-) -- Larry Wall on s/foo/bar/eieio in 10...@jpl-devvax.jpl.nasa.gov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
Wolfgang Denk wrote: The problem is that on all of our PowerPC boards, the TLBs only map the lower 2GB of memory, regardless as to how much is present. So we still can't use get_ram_size() to determine how much memory is in the system, because any attempt to access memory higher than 2GB will fail. Now this is your problem, then, and you should kno how to fix it. Scott pointed out that writing/reading memory to determine how much memory actually exists is dangerous. I'm not convinced that I should be using get_ram_size(). I still believe that I shouldn't. And even if we did have TLBs for all of memory, an attempt to access RAM that doesn't exist will cause a machine check, which will hang U-Boot. So we still couldn't use get_ram_size() to determine how much RAM actually exists. Please see how it's done on all other PowerPC systems, and do similar. I have not been able to find any other PowerPC system in U-boot that supports more memory than is mapped. If you know of one, please tell me. Otherwise, I would say that there are no other comparable PowerPC systems that I can use as an example. -long get_ram_size(volatile long *base, long maxsize) +phys_size_t get_ram_size(volatile phys_addr_t *base, phys_size_t maxsize) I don't think you want 'base' to be a pointer to phys_addr_t, because the pointer type determines how much is read/written in a single operation. I don't think you want to be doing 64-bit reads and writes. I don't know your mnemory bus. This is an RFC patch. My point is that sizeof(phys_addr_t) has got nothing to do with the size of the read/write operation, so I think it's wrong on all platforms. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Wolfgang Denk wrote: It also doesn't handle non-power-of-two sized memory -- don't rely on the value it returns. Such configurations are usually set up of from several differently sized banks of memory, and get_ram_size() is always run per bank. So as long as chip manufacturers continue to make RAM chips with power-of-two sizes only, everything should be fine. What if the board has two DIMM slots, one of which has a 1GB DIMM and the other has a 512MB DIMM? [1] It's worse than machine checks, what if some I/O device is mapped directly after RAM? IIRC people have run into this sort of problem doing this type of memory sizing on PCs. Well, let's call this a bug in setting up the memory map for the system ;-) I thought get_ram_size() was supposed to safely determine how much RAM is actually in the system? Otherwise, it should be called verify_ram_size(). -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
On 05/27/2010 02:44 PM, Wolfgang Denk wrote: Dear Timur Tabi, In messageaanlktilrfhtwnqgqx9nvmplabl8hpiszy97hkk73-...@mail.gmail.com you wrote: On Thu, May 27, 2010 at 1:11 PM, Wolfgang Denkw...@denx.de wrote: get_ram_size() used to use long data types for addresses and data, which in limited it to systems with less than 4 GiB memory. As more and more systems are coming up with bigger memory resources, we adapt the code to use phys_addr_t / phys_size_t data types instead. Signed-off-by: Wolfgang Denkw...@denx.de Cc: Timur Tabiti...@freescale.com --- The problem is that on all of our PowerPC boards, the TLBs only map the lower 2GB of memory, regardless as to how much is present. So we still can't use get_ram_size() to determine how much memory is in the system, because any attempt to access memory higher than 2GB will fail. Now this is your problem, then, and you should kno how to fix it. Not using get_ram_size(), which is of minimal utility when you know the actual size (and is an unsafe approach to the problem when you don't, unless you know a lot about where I/O is mapped and how the system responds to accessing memory that doesn't exist -- not exactly the sort of thing you want to make a mandate for any board to be accepted), seems like a good way to fix it. And even if we did have TLBs for all of memory, an attempt to access RAM that doesn't exist will cause a machine check, which will hang U-Boot. So we still couldn't use get_ram_size() to determine how much RAM actually exists. Please see how it's done on all other PowerPC systems, and do similar. All other PowerPC systems is a ridiculous overstatement. I see exactly *one* Freescale board that uses this thing, and it's an ARM board. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Wolfgang Denk wrote: Ah, that's a serious limitation. No, it is not. Testing is done per bank. Ok, I get it now. I'm supposed to call get_ram_size() on each DIMM I locate. That's going to be complicated because we don't have any TLBs set up when we do that. And what if we have a 4GB DIMM? Because virtual addresses are still 32-bits, we would need to change get_ram_size() to modify a temporary TLB while it's reading/writing memory. So we'd need to have an e300 version of get_ram_size(), an e500 version, an e600 version, and so on. So I have a question: are you still going to require me to use get_ram_size() in my P1022DS board patch? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
Dear Scott Wood, In message 4bfecf43.40...@freescale.com you wrote: Isn't phys_addr_t assumed to be the right data type to hold a physical address? Yes. But you can't dereference a physical address directly. Ah, right. OK, so this needs more work... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The most difficult thing in the world is to know how to do a thing and to watch someone else doing it wrong, without commenting. -- T.H. White ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
Dear Timur Tabi, In message 4bfecf82.60...@freescale.com you wrote: Scott pointed out that writing/reading memory to determine how much memory actually exists is dangerous. I'm not convinced that I should be using get_ram_size(). I still believe that I shouldn't. And I point out that we have been doing this for a decade on tens of different board configurations with millions of devices in the field. I have not been able to find any other PowerPC system in U-boot that supports more memory than is mapped. If you know of one, please tell me. The systems I know are the opposite - initially they map more memory than they support, then they determine the real size, then they adjust the mapping to the real size. My point is that sizeof(phys_addr_t) has got nothing to do with the size of the read/write operation, so I think it's wrong on all platforms. Actually it will only be wrong on systems where phys_addr_t != ulong, but you are right. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The two most common things in the universe are hydrogen and stupi- dity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Timur Tabi, In message 4bfed01f.1040...@freescale.com you wrote: Such configurations are usually set up of from several differently sized banks of memory, and get_ram_size() is always run per bank. So as long as chip manufacturers continue to make RAM chips with power-of-two sizes only, everything should be fine. What if the board has two DIMM slots, one of which has a 1GB DIMM and the other has a 512MB DIMM? Then you run get_ram_size() twice, and it will find 1 GiB and 512 MiB of memory - what's the problem? I thought get_ram_size() was supposed to safely determine how much RAM is actually in the system? Otherwise, it should be called verify_ram_size(). Indeed it is intended to determine tha actual RAM size - and does so fine in dozens of board configurations. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?- Steve Elias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Scott Wood, In message 4bfed090.1040...@freescale.com you wrote: If you set maxsize beyond what you expect to find, how are you going to constrain it to operating on one bank? Maybe it helps if you read section System Initialization in teh README; this explains the original design when I implemented this a decade ago. Such configurations are usually set up of from several differently sized banks of memory, and get_ram_size() is always run per bank. So as long as chip manufacturers continue to make RAM chips with power-of-two sizes only, everything should be fine. So it's not the board code at all that should be calling this, it's the SDRAM code? Which is already in u-boot, and not in this patch (other than some board-specific tweaks)? I don't know where you initialize the RAM. Let's not. It can be crowded enough as is, we don't need more restrictions coming from u-boot wanting to do questionable and unnecessary things. Well, what seems unnecessary to you is actually pretty important to others. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I realize that command does have its fascination, even under circum- stances such as these, but I neither enjoy the idea of command nor am I frightened of it. It simply exists, and I will do whatever logi- cally needs to be done. -- Spock, The Galileo Seven, stardate 2812.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
Wolfgang Denk wrote: The systems I know are the opposite - initially they map more memory than they support, then they determine the real size, then they adjust the mapping to the real size. But we don't ever do that, at least not on systems that use SPD. We query the DIMMs directly via SPD and calculate how much memory is in the system. Most of our boards support both SPD and fixed DDR programming. In fixed mode, the actual values to be programmed in the controller are hard-coded in the board header file, like this: #define CONFIG_SYS_DDR_CS0_BNDS 0x003F #define CONFIG_SYS_DDR_CS1_BNDS 0x #define CONFIG_SYS_DDR_CS0_CONFIG 0x80014202 #define CONFIG_SYS_DDR_CS1_CONFIG 0x ... So in this case, as long as there's = 2GB of DDR expected, then get_ram_size() can work. But on the P1022DS, I don't support fixed DDR mode. Only SPD is supported, so I have no idea at compile-time how much memory is in the system. That's why I don't think calling get_ram_size() is appropriate for the P1022DS board. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
Dear Scott Wood, In message 4bfed0cd.5010...@freescale.com you wrote: Not using get_ram_size(), which is of minimal utility when you know the actual size (and is an unsafe approach to the problem when you don't, unless you know a lot about where I/O is mapped and how the system responds to accessing memory that doesn't exist -- not exactly the sort of thing you want to make a mandate for any board to be accepted), seems like a good way to fix it. Come on. Anybody who does NOT know the exact memory map of a system (and is able to define it as needed) is obviously not in a position to port U-Boot to this hardware. This is basic knowledge. All other PowerPC systems is a ridiculous overstatement. I see exactly *one* Freescale board that uses this thing, and it's an ARM board. And this uses it incorrectly, like all ARM boards, if I'm not wrong. Well, there is a ton of other boards besides the ones manufactured by Freescale, including many that use Freescale chips. I am not to blame if Freescale did not pick up a number of design concepts. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I object to intellect without discipline; I object to power without constructive purpose. -- Spock, The Squire of Gothos, stardate 2124.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
On May 27, 2010, at 3:57 PM, Wolfgang Denk wrote: Dear Timur Tabi, In message 4bfecf82.60...@freescale.com you wrote: Scott pointed out that writing/reading memory to determine how much memory actually exists is dangerous. I'm not convinced that I should be using get_ram_size(). I still believe that I shouldn't. And I point out that we have been doing this for a decade on tens of different board configurations with millions of devices in the field. I have not been able to find any other PowerPC system in U-boot that supports more memory than is mapped. If you know of one, please tell me. The systems I know are the opposite - initially they map more memory than they support, then they determine the real size, then they adjust the mapping to the real size. Is the point of get_ram_size() to deal with having the same firmware image (binary) be able to be agnostic of memory size? I'm not sure I understand what utility one gets out of it if we have SPD eeprom information? I can see some purpose in the soldered memory case if you dont want to tweak binaries between different memory size configs. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Timur Tabi, In message 4bfed1ea.5060...@freescale.com you wrote: So I have a question: are you still going to require me to use get_ram_size() in my P1022DS board patch? I never *reqired* this. All I wrote was: | + puts(DDR: ); | + return dram_size; | | How about using get_ram_size() for autosizing / testing? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It may be that your whole purpose in life is simply to serve as a warning to others. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces 32 bit
Dear Kumar Gala, In message 48a9b08d-9237-4837-91ca-0d23ce1e5...@kernel.crashing.org you wrote: The systems I know are the opposite - initially they map more memory than they support, then they determine the real size, then they adjust the mapping to the real size. Is the point of get_ram_size() to deal with having the same firmware image (binary) be able to be agnostic of memory size? Yes, this is the key point of it. I'm not sure I understand what utility one gets out of it if we have SPD eeprom information? I can see some purpose in the soldered memory case if you dont want to tweak binaries between different memory size configs. With SPD information the benefits go down to the (limited) testing it does, so you might still detect hardware issues - if you try and insert a 2 GiB DIMM and U-Boot sees only 512 MiB then you can be damn sure that something is not working as expected. Especially on systems where the end user can plug in any types of memory modules that seems to be a pretty useful feature to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de miracle: an extremely outstanding or unusual event, thing, or accomplishment.- Webster's Dictionary ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4 v2] Makefile: rework / cleanup
The top level Makefile is growing and growing. Once, when we supported only a few tens of boards, it was possible to implement board configuration logic in the Makefile, but it quickly turned out that this doesn't scale. Also, it is not really needed (at least not any more) - we now have mechanisnms in place, that allow for more efficient code. The following patch series is an attempt to start some cleanup and reduce the size of the top level Makefile. The solution is neither perfect nor complete - there are quite a lot of boards that resist such a cleanup and need more thorough rework. But it's an initial step, showing what could and should be done, which boards have problems, and why this is the case. Eventually this paves the ground for a more friendly way to add new board configurations. The idea is to have all board descriptions in a single data base in form of a plain text file - no need to add anything to the top level Makefile, and eventually also tools like the MAKEALL script can be replaced / simplified because they can fetch all needed board information from that data base. 1/4: Fix printing of make targets, simplify Makefile Makefile | 740 - 1 files changed, 243 insertions(+), 497 deletions(-) 2/4: Makefile: simplify handling of build target names Makefile | 774 ++ mkconfig |6 +- 2 files changed, 380 insertions(+), 400 deletions(-) 3/4: Makefile: simplify handling of common board configurations Makefile | 1436 ++ 1 files changed, 607 insertions(+), 829 deletions(-) 4/4: Makefile/mkconfig: read simple board configurations from boards.cfg Makefile | 823 ++-- boards.cfg | 356 ++ mkconfig | 72 -- 3 files changed, 431 insertions(+), 820 deletions(-) create mode 100644 boards.cfg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4 v2] Makefile/mkconfig: read simple board configurations from boards.cfg
Instead of adding explicit build rules for each and every board to the top level Makefile (which makes it grow and grow), we now provide a simple default rule and extend the mkconfig script to read board configurations from a plain text file (table), boards.cfg. For simple boards it is now sufficient to add a single line of text to the boards.cfg file, no changes to the top level Makefile are needed any more. To make the table better readable, change the notation for unused fields from NULL into -. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Peter Tyser pty...@xes-inc.com Cc: Mike Frysinger vap...@gentoo.org --- Note: I had to disable the simple and very convenient rule %: %_config $(MAKE) in the top level Makefile, because it caused each invocation of make to fail with an error message: make: *** No rule to make target `Makefile_config'. Stop. Fixes welcome! Makefile | 823 ++-- boards.cfg | 356 ++ mkconfig | 72 -- 3 files changed, 431 insertions(+), 820 deletions(-) create mode 100644 boards.cfg diff --git a/Makefile b/Makefile index 48ca9e5..9c4e600 100644 --- a/Makefile +++ b/Makefile @@ -475,8 +475,11 @@ unconfig: $(obj)board/*/config.tmp $(obj)board/*/*/config.tmp \ $(obj)include/autoconf.mk $(obj)include/autoconf.mk.dep -%: %_config - $(MAKE) +%_config:: unconfig + @$(MKCONFIG) -A $(@:_config=) + +##%: %_config +## $(MAKE) # # Functions to generate common board directory names @@ -489,50 +492,9 @@ ucname = $(shell echo $(1) | sed -e 's/\(.*\)_config/\U\1/') # # -## MPC5xx Systems -# - -cmi_mpc5xx_config: unconfig - @$(MKCONFIG) $@ powerpc mpc5xx cmi - -PATI_config: unconfig - @$(MKCONFIG) $@ powerpc mpc5xx pati mpl - -# ## MPC5xxx Systems # -# generic boards - -BC3450_config \ -canmb_config \ -cm5200_config \ -hmi1001_config \ -jupiter_config \ -inka4x0_config \ -ipek01_config \ -motionpro_config\ -mucmc52_config \ -munices_config \ -o2dnt_config \ -uc101_config \ -v38b_config: unconfig - @$(MKCONFIG) $@ powerpc mpc5xxx $(call lcname,$@) - -# vendor specific boards (sorted by vendor) -### -cpci5200_config\ -mecp5200_config\ -pf5200_config: unconfig - @$(MKCONFIG) $@ powerpc mpc5xxx $(call lcname,$@) esd - -aev_config \ -smmaco4_config \ -spieval_config:unconfig - @$(MKCONFIG) $@ powerpc mpc5xxx tqm5200 tqc - -# special boards - digsy_mtc_config \ digsy_mtc_LOWBOOT_config \ digsy_mtc_RAMBOOT_config: unconfig @@ -717,21 +679,6 @@ TQM5200_STK100_config: unconfig ## MPC512x Systems # -# generic boards - -pdm360ng_config: unconfig - @$(MKCONFIG) $@ powerpc mpc512x $(call lcname,$@) - -# vendor specific boards (sorted by vendor) -### -aria_config: unconfig - @$(MKCONFIG) $@ powerpc mpc512x aria davedenx - -mecp5123_config: unconfig - @$(MKCONFIG) $@ powerpc mpc512x mecp5123 esd - -# special boards - mpc5121ads_config \ mpc5121ads_rev2_config \ : unconfig @@ -745,80 +692,6 @@ mpc5121ads_rev2_config \ ## MPC8xx Systems # -# generic boards - - -c2mon_config \ -EP88x_config \ -ESTEEM192E_config \ -ETX094_config \ -FLAGADM_config \ -GENIETV_config \ -GTH_config \ -hermes_config \ -IP860_config \ -LANTEC_config \ -lwmon_config \ -NX823_config \ -quantum_config \ -R360MPI_config \ -RBC823_config \ -rmu_config \ -spc1920_config \ -svm_sc8xx_config \ -uc100_config : unconfig - @$(MKCONFIG) $@ powerpc mpc8xx $(call lcname,$@) - -RPXClassic_config \ -RPXlite_config \ -RRvision_config: unconfig - @$(MKCONFIG) $@ powerpc mpc8xx $(@:_config=) - -# vendor specific boards (sorted by vendor) -### - -MHPC_config: unconfig - @$(MKCONFIG) $@ powerpc mpc8xx mhpc eltec - -TOP860_config: unconfig - @$(MKCONFIG) $@ powerpc mpc8xx top860 emk - -kmsupx4_config \ -mgsuvd_config :
Re: [U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
Kumar Gala wrote:
We can do something like:
for (hose = hose_head; hose; hose = hose-next) {
off = fdt_node_offset_by_compatible(blob, -1, pci_compat);
while (off != -FDT_ERR_NOTFOUND) {
const int reg * = fdt_getprop(blob, off, reg, NULL);
match hose-cfg_addr against reg
off = fdt_node_offset_by_compatible(blob, off,
pci_compat);
}
}
Ok, I'll start working on this after I'm done with the P1022DS.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
On Fri, May 21, 2010 at 4:17 AM, Kumar Gala ga...@kernel.crashing.org wrote:
if (pcie_configured !(devdisr MPC85xx_DEVDISR_PCIE2)) {
+ set_next_law(CONFIG_SYS_PCIE2_MEM_PHYS, LAW_SIZE_512M,
+ LAW_TRGT_IF_PCIE_2);
+ set_next_law(CONFIG_SYS_PCIE2_IO_PHYS, LAW_SIZE_64K,
+ LAW_TRGT_IF_PCIE_2);
SET_STD_PCIE_INFO(pci_info[num], 2);
How about this instead:
SET_STD_PCIE_INFO(pci_info[num], 2);
+ set_next_law(pci_info[num].mem_phys,
+law_size_bits(pci_info[num].mem_size),
+LAW_TRGT_IF_PCIE_2);
+ set_next_law(pci_info[num].io_phys,
+law_size_bits(pci_info[num].io_size),
+ LAW_TRGT_IF_PCIE_2);
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] old nios arch removal
Thomas, The old nios arch is obsolete and the build has been broken for a long time. Shall we remove it from u-boot? I'm in favor of removing the nios-32 code. It's been a very long time since I had a customer using nios-32 -- never mind nios-32 u-boot. If nobody objects, let's get rid of it. Regards, --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] old nios arch removal
Scott McNutt wrote: Thomas, The old nios arch is obsolete and the build has been broken for a long time. Shall we remove it from u-boot? I'm in favor of removing the nios-32 code. It's been a very long time since I had a customer using nios-32 -- never mind nios-32 u-boot. If nobody objects, let's get rid of it. Regards, --Scott Hi Scott, Yes, the gcc2.9 of nios-32 is too old for current u-boot. I will prepare a branch for the removal on my git server, then you may pull it and verify. The patches might be too big to post entirely on the list. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4 v2] Makefile: rework / cleanup
Wolfgang Denk wrote: The top level Makefile is growing and growing. Once, when we supported only a few tens of boards, it was possible to implement board configuration logic in the Makefile, but it quickly turned out that this doesn't scale. Also, it is not really needed (at least not any more) - we now have mechanisnms in place, that allow for more efficient code. Dear Wolfgang, Build and tested nios2 on boards. But old nios-32 arch is broken and will be removed soon. Shall I perform the removal based on current head or after these patches applied? Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nios: remove nios-32 arch
The nios-32 arch is obsolete and broken. So it is removed. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- Deleted files are snipped. The following changes since commit 01f03bda5b22e5aeae5f02fd537da97a41485c73: Wolfgang Denk (1): Prepare v2010.06-rc1 are available in the git repository at: git://sopc.et.ntust.edu.tw/git/u-boot.git rm_nios32 MAINTAINERS | 16 - MAKEALL | 17 +- Makefile | 62 --- README|7 +- arch/nios/config.mk | 29 -- arch/nios/cpu/Makefile| 48 --- arch/nios/cpu/asmi.c | 695 - arch/nios/cpu/config.mk | 24 -- arch/nios/cpu/cpu.c | 78 arch/nios/cpu/interrupts.c| 196 - arch/nios/cpu/serial.c| 135 --- arch/nios/cpu/spi.c | 195 - arch/nios/cpu/start.S | 238 --- arch/nios/cpu/traps.S | 582 --- arch/nios/include/asm/bitops.h| 38 -- arch/nios/include/asm/byteorder.h | 30 -- arch/nios/include/asm/cache.h |1 - arch/nios/include/asm/config.h| 27 -- arch/nios/include/asm/global_data.h | 54 --- arch/nios/include/asm/io.h| 141 --- arch/nios/include/asm/posix_types.h | 63 --- arch/nios/include/asm/processor.h |1 - arch/nios/include/asm/psr.h | 28 -- arch/nios/include/asm/ptrace.h| 36 -- arch/nios/include/asm/status_led.h| 132 --- arch/nios/include/asm/string.h| 25 -- arch/nios/include/asm/system.h|4 - arch/nios/include/asm/types.h | 60 --- arch/nios/include/asm/u-boot.h| 48 --- arch/nios/lib/Makefile| 50 --- arch/nios/lib/board.c | 168 arch/nios/lib/bootm.c | 34 -- arch/nios/lib/cache.c | 32 -- arch/nios/lib/divmod.c| 101 - arch/nios/lib/math.h | 16 - arch/nios/lib/mult.c | 56 --- arch/nios/lib/time.c | 38 -- board/altera/dk1c20/Makefile | 51 --- board/altera/dk1c20/config.mk | 29 -- board/altera/dk1c20/dk1c20.c | 93 - board/altera/dk1c20/flash.c | 62 --- board/altera/dk1c20/misc.c| 33 -- board/altera/dk1c20/u-boot.lds| 70 board/altera/dk1c20/vectors.S | 123 -- board/altera/dk1s10/Makefile | 51 --- board/altera/dk1s10/config.mk | 29 -- board/altera/dk1s10/dk1s10.c | 72 board/altera/dk1s10/flash.c | 62 --- board/altera/dk1s10/misc.c| 33 -- board/altera/dk1s10/u-boot.lds| 70 board/altera/dk1s10/vectors.S | 139 --- board/ssv/adnpesc1/Makefile | 51 --- board/ssv/adnpesc1/adnpesc1.c | 103 - board/ssv/adnpesc1/config.mk | 29 -- board/ssv/adnpesc1/flash.c| 66 --- board/ssv/adnpesc1/misc.c | 40 -- board/ssv/adnpesc1/u-boot.lds | 70 board/ssv/adnpesc1/vectors.S | 138 --- board/ssv/common/cmd_sled.c | 162 board/ssv/common/flash.c | 207 -- board/ssv/common/post.c | 44 -- board/ssv/common/wd_pio.c | 160 common/cmd_bdinfo.c | 19 - common/cmd_bootm.c|2 - common/image.c|1 - config.mk |8 - doc/README.adnpesc1 | 235 --- doc/README.adnpesc1_base32| 469 -- doc/README.dk1c20 | 153 doc/README.dk1c20_std32 | 366 - doc/README.dk1s10 | 131 -- doc/README.dk1s10_mldk20 | 286 -- doc/README.dk1s10_std32 | 354 - doc/README.dk1s40_std32 | 355 - doc/README.dk20k200_std32 | 242 doc/README.nios | 366 - doc/README.nios_CONFIG_SYS_NIOS_CPU | 140 --- doc/README.nios_DK| 192 - doc/uImage.FIT/source_file_format.txt |3 +- examples/standalone/stubs.c | 17 - fs/fat/fat.c |3 - include/configs/ADNPESC1.h| 689 include/configs/ADNPESC1_base_32.h| 431 include/configs/DK1C20.h | 555 -- include/configs/DK1C20_safe_32.h | 34 -- include/configs/DK1C20_standard_32.h | 279 - include/configs/DK1S10.h | 561
[U-Boot] [PATCH] nios2: use gc sections to reduce image size
Follow the discussion of Charles Manning and Mike Frysinger. Using gc_sections helps reduce image size. Configuring for nios2-generic board... Before, textdata bss dec hex filename 1239793724 22892 150595 24c43 /tmp/u-boot/u-boot After, textdata bss dec hex filename 1159833800 22732 142515 22cb3 /tmp/u-boot/u-boot Signed-off-by: Thomas Chou tho...@wytron.com.tw --- arch/nios2/config.mk |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/nios2/config.mk b/arch/nios2/config.mk index 793cc43..aba96b3 100644 --- a/arch/nios2/config.mk +++ b/arch/nios2/config.mk @@ -31,2 +31,5 @@ PLATFORM_CPPFLAGS += -DCONFIG_NIOS2 -D__NIOS2__ LDSCRIPT ?= $(SRCTREE)/$(CPUDIR)/u-boot.lds + +LDFLAGS += --gc-sections +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections -- 1.7.1.86.g0e460 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] please update ARM mach-types
Dear Tom, Could you please update ARM machine types? I will post the new board that is named goni, but mach-types is not updated. Thanks. Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4 v2] Makefile/mkconfig: read simple board configurations from boards.cfg
Hi Wolfgang, snip Note: I had to disable the simple and very convenient rule %: %_config $(MAKE) in the top level Makefile, because it caused each invocation of make to fail with an error message: make: *** No rule to make target `Makefile_config'. Stop. Fixes welcome! I think adding the following line somewhere in the Makefile should allow the %:%_config rule to be re-enabled: Makefile:; Without the above line, after uncommenting the %: %_config rule and running make -d board the output shows that make is looking to satisfy an implicit 'Makefile' rule which is eventually satisfied by the %: %_config target, which causes the error you mention: Reading makefile `Makefile'... Updating makefiles Considering target file `Makefile'. Looking for an implicit rule for `Makefile'. Trying pattern rule with stem `Makefile'. ... Trying implicit prerequisite `Makefile_config'. Looking for a rule with intermediate file `Makefile_config'. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile'. Trying rule prerequisite `unconfig'. Found an implicit rule for `Makefile'. Considering target file `unconfig'. File `unconfig' does not exist. Finished prerequisites of target file `unconfig'. Must remake target `unconfig'. Putting child 0x080a6f40 (unconfig) PID 20171 on the chain. Live child 0x080a6f40 (unconfig) PID 20171 Reaping winning child 0x080a6f40 PID 20171 Removing child 0x080a6f40 PID 20171 from chain. Successfully remade target file `unconfig'. Considering target file `Makefile_config'. File `Makefile_config' does not exist. Pruning file `unconfig'. Finished prerequisites of target file `Makefile_config'. Must remake target `Makefile_config'. If the unconfig dependency of the %_config rule is removed, Makefile_config no longer needs to be built, and building works expected. Weird... So I'm not sure why the unconfig dependency makes a difference. Anyone have any clue? As a basic test, the following works as expected (eg try running 'make asdf'): unconfig: @echo UNCONFIG for $@ baz_config: @echo applying target baz rules for $...@. %_config: @echo applying DEFAULT rules for $...@. %: %_config @echo DEFAULT_config for $@ while the following exhibits the issue Wolfgang pointed out: unconfig: @echo UNCONFIG for $@ baz_config: @echo applying target baz rules for $...@. %_config: unconfig @echo applying DEFAULT rules for $...@. %: %_config @echo DEFAULT_config for $@ The fix mentioned at the top would look like: Makefile:; unconfig: @echo unconfig for $@ baz_config: @echo applying target baz rules for $...@. %_config: unconfig @echo applying default rules for $...@. %: %_config @echo default_config for $@ For what its worth the Linux kernel also has the empty Makefile rule. Out of curiosity, anyone know why the unconfig dependency of %_config makes any difference? I don't quite get why it does, but I don't think adding the empty Makefile rule has any real downsides, and may actually be an improvement so make doesn't waste its time looking for Makefile.xyz targets we don't care about. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4 v2] Makefile/mkconfig: read simple board configurations from boards.cfg
On Fri, 2010-05-28 at 00:13 -0500, Peter Tyser wrote: Hi Wolfgang, snip Note: I had to disable the simple and very convenient rule %: %_config $(MAKE) in the top level Makefile, because it caused each invocation of make to fail with an error message: make: *** No rule to make target `Makefile_config'. Stop. Fixes welcome! I think adding the following line somewhere in the Makefile should allow the %:%_config rule to be re-enabled: Makefile:; Maybe I spoke too soon... It seems that make looks for other files that are dependencies, but don't have explicit rules. Like include/autoconf.mk, config.mk, etc. Linux has a number of implicit rule overrides (search for implicit in its top-level Makefile) that appear to be for the same type of issue. This seems like a somewhat hokey fix to have a number of empty rules defined though. Any better ideas or comments on why this issue didn't exist before? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: remove EP1C20, EP1S10, EP1S40 boards
Scott McNutt wrote: I tested on the 1c20 this evening as well ... works fine. I will test on the 2c35 board tomorrow. I'd like to get a positive confirmation WRT the 1S10 and 1S40 before applying this patch. Hi Scott, Please follow up this patch. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
