[U-Boot-Users] [PATCH] bdinfo not showing correct info about memory size
Signed-off-by: Ricardo Ribalda Delgado ricardo.ribalda@uam.es --- common/cmd_bdinfo.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c index caa467d..583bbc2 100644 --- a/common/cmd_bdinfo.c +++ b/common/cmd_bdinfo.c @@ -48,7 +48,7 @@ int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) print_num ("bd address", (ulong)bd ); #endif print_num ("memstart", bd->bi_memstart ); - print_lnum ("memsize", bd->bi_memsize ); + print_num ("memsize", bd->bi_memsize ); print_num ("flashstart", bd->bi_flashstart ); print_num ("flashsize", bd->bi_flashsize ); print_num ("flashoffset", bd->bi_flashoffset );
In message 1217414549-28700-1-git-send-email-ricardo.ribalda@uam.es you wrote:
Signed-off-by: Ricardo Ribalda Delgado ricardo.ribalda@uam.es
common/cmd_bdinfo.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c index caa467d..583bbc2 100644 --- a/common/cmd_bdinfo.c +++ b/common/cmd_bdinfo.c @@ -48,7 +48,7 @@ int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) print_num ("bd address", (ulong)bd ); #endif print_num ("memstart", bd->bi_memstart );
- print_lnum ("memsize", bd->bi_memsize );
- print_num ("memsize", bd->bi_memsize ); print_num ("flashstart", bd->bi_flashstart ); print_num ("flashsize", bd->bi_flashsize ); print_num ("flashoffset", bd->bi_flashoffset );
This patch is wrong. print_num() takes an ulong argument, but bi_memsize has type phys_size_t.
Rejected.
Best regards,
Wolfgang Denk
Hello Wolfgang
My board has 0x10000000 bytes of memory, without this patch, bdinfo shows 0x0 bytes of ram, but with this patch it shows the correct amount... maybe the problem is in print_lnum
Best regards
On Wed, Jul 30, 2008 at 1:04 PM, Wolfgang Denk wd@denx.de wrote:
In message 1217414549-28700-1-git-send-email-ricardo.ribalda@uam.es you wrote:
Signed-off-by: Ricardo Ribalda Delgado ricardo.ribalda@uam.es
common/cmd_bdinfo.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c index caa467d..583bbc2 100644 --- a/common/cmd_bdinfo.c +++ b/common/cmd_bdinfo.c @@ -48,7 +48,7 @@ int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) print_num ("bd address", (ulong)bd ); #endif print_num ("memstart", bd->bi_memstart );
print_lnum ("memsize", bd->bi_memsize );
print_num ("memsize", bd->bi_memsize ); print_num ("flashstart", bd->bi_flashstart ); print_num ("flashsize", bd->bi_flashsize ); print_num ("flashoffset", bd->bi_flashoffset );This patch is wrong. print_num() takes an ulong argument, but bi_memsize has type phys_size_t.
Rejected.
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: wd@denx.de "If you can, help others. If you can't, at least don't hurt others."
- the Dalai Lama
In message aa76a2be0807300410n33b5623ay8801cd7dd128b1a9@mail.gmail.com you wrote:
My board has 0x10000000 bytes of memory, without this patch, bdinfo shows 0x0 bytes of ram, but with this patch it shows the correct amount... maybe the problem is in print_lnum
It would be strange if this happened for your board only - I rather suspect that you have a problem with your board configuration.
Best regards,
Wolfgang Denk
Hello Wolfwang
I don't think that it is a problem with my board config, otherwhise it won't show the correct size using print_num... Maybe other users didn't have any problems because their memory size is smaller than 256MB.
Best regards
On Wed, Jul 30, 2008 at 1:21 PM, Wolfgang Denk wd@denx.de wrote:
In message aa76a2be0807300410n33b5623ay8801cd7dd128b1a9@mail.gmail.com you wrote:
My board has 0x10000000 bytes of memory, without this patch, bdinfo shows 0x0 bytes of ram, but with this patch it shows the correct amount... maybe the problem is in print_lnum
It would be strange if this happened for your board only - I rather suspect that you have a problem with your board configuration.
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: wd@denx.de Every revolutionary idea - in science, politics, art, or whatever - evokes three stages of reaction in a hearer:
- It is completely impossible - don't waste my time.
- It is possible, but it is not worth doing.
- I said it was a good idea all along.
In message aa76a2be0807300434o332c9da8gaa2e7e3d4486dd64@mail.gmail.com you wrote:
I don't think that it is a problem with my board config, otherwhise it won't show the correct size using print_num... Maybe other users didn't have any problems because their memory size is smaller than 256MB.
There are many, many boards with bigger memory as well. And these don't have problems either. For example:
U-Boot 1.3.4-rc1-00012-g1953d12 (Jul 21 2008 - 09:05:23)
CPU: AMCC PowerPC 440SPe Rev. B at 800 MHz (PLB=160, OPB=53, EBC=17 MHz) RAID 6 support Bootstrap Option D - Boot ROM Location I2C (Addr 0x50) Internal PCI arbiter enabled 32 kB I-Cache 32 kB D-Cache Board: Katmai - AMCC 440SPe Evaluation Board I2C: ready DTT: 1 is 27 C DTT: 2 is 27 C DRAM: 4 GB (ECC not enabled, 640 MHz, CL5) FLASH: 16 MB ... => bdi memstart = 0x00000000 memsize = 0x100000000 ...
As you can see, this board has 4 GB of RAM and everything works just fine.
Best regards,
Wolfgang Denk
On Wednesday 30 July 2008, Wolfgang Denk wrote:
=> bdi memstart = 0x00000000 memsize = 0x100000000 ...
As you can see, this board has 4 GB of RAM and everything works just fine.
Yes. But unfortunately not for all boards. As it seems the patch b57ca3e128cc10a133ba79bc7ec3e7b50e7c8fbe [Change bd/gd memsize/ram_size to be phys_size_t.] introduced %llX unconditionally for all non-ARM boards. And many boards don't have support for 64bit printf formats enabled.
So what to do? Enable 64bit format on all boards? Or make this size printing conditionally somehow?
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Ricardo,
On Wednesday 30 July 2008, Ricardo Ribalda Delgado wrote:
I don't think that it is a problem with my board config, otherwhise it won't show the correct size using print_num... Maybe other users didn't have any problems because their memory size is smaller than 256MB.
Most likely you need to enable 64bit printf format (%ll) support:
#define CFG_64BIT_VSPRINTF #define CFG_64BIT_STRTOUL
This is already done for all 440 PPC's (include/ppc4xx.h) in the current git head. I'll merge this soon into the next branch of my ppc4xx repository, then your problem should go away.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
In message 200807301354.50242.sr@denx.de you wrote:
I don't think that it is a problem with my board config, otherwhise it won't show the correct size using print_num... Maybe other users didn't have any problems because their memory size is smaller than 256MB.
Most likely you need to enable 64bit printf format (%ll) support:
#define CFG_64BIT_VSPRINTF #define CFG_64BIT_STRTOUL
This is already done for all 440 PPC's (include/ppc4xx.h) in the current git head. I'll merge this soon into the next branch of my ppc4xx repository, then your problem should go away.
Given the fact that print_lnum() unconditionally takes a u64 arg and unconditionally uses a %llX format, I thinkwe shoudl either fix print_lnum() for non-64bit cases, or drop the CFG_64BIT_VSPRINTF / CFG_64BIT_STRTOUL options completely.
Best regards,
Wolfgang Denk
On Wednesday 30 July 2008, Wolfgang Denk wrote:
Most likely you need to enable 64bit printf format (%ll) support:
#define CFG_64BIT_VSPRINTF #define CFG_64BIT_STRTOUL
This is already done for all 440 PPC's (include/ppc4xx.h) in the current git head. I'll merge this soon into the next branch of my ppc4xx repository, then your problem should go away.
Given the fact that print_lnum() unconditionally takes a u64 arg and unconditionally uses a %llX format, I thinkwe shoudl either fix print_lnum() for non-64bit cases, or drop the CFG_64BIT_VSPRINTF / CFG_64BIT_STRTOUL options completely.
Personally, I'm voting for dropping the options completely and enabling the 64bit support unconditionally. I took me some time a few days ago to figure out that this support was *not* enabled by default.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hello WD and SR:
because my board is one that it is not working, I am open to receive any snipset and test them on the "real world"
Best Regards
On Wed, Jul 30, 2008 at 2:13 PM, Stefan Roese sr@denx.de wrote:
On Wednesday 30 July 2008, Wolfgang Denk wrote:
Most likely you need to enable 64bit printf format (%ll) support:
#define CFG_64BIT_VSPRINTF #define CFG_64BIT_STRTOUL
This is already done for all 440 PPC's (include/ppc4xx.h) in the current git head. I'll merge this soon into the next branch of my ppc4xx repository, then your problem should go away.
Given the fact that print_lnum() unconditionally takes a u64 arg and unconditionally uses a %llX format, I thinkwe shoudl either fix print_lnum() for non-64bit cases, or drop the CFG_64BIT_VSPRINTF / CFG_64BIT_STRTOUL options completely.
Personally, I'm voting for dropping the options completely and enabling the 64bit support unconditionally. I took me some time a few days ago to figure out that this support was *not* enabled by default.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
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
In message 200807301413.32008.sr@denx.de you wrote:
Given the fact that print_lnum() unconditionally takes a u64 arg and unconditionally uses a %llX format, I thinkwe shoudl either fix print_lnum() for non-64bit cases, or drop the CFG_64BIT_VSPRINTF / CFG_64BIT_STRTOUL options completely.
Personally, I'm voting for dropping the options completely and enabling the 64bit support unconditionally. I took me some time a few days ago to figure out that this support was *not* enabled by default.
Well, it adds some 2.2 kB of code size for all ssytems - even those who have zero benefit from it.
My personal preference would be to fix print_lnum() to take for example a phys_size_t argument instead of u64.
I guess we need an #ifdef for the %llX (versus %lX) format then (or does anybody know of a clever way to avoid this, maybe something like the %zu we used to fix the size_t issues? )
Best regards,
Wolfgang Denk
participants (4)
-
Ricardo -
Ricardo Ribalda Delgado -
Stefan Roese -
Wolfgang Denk