Re: [U-Boot] Help with TSEC on MPC8343
Hi Johnson, i'm also facing the same problem in MPC8313 board with u-boot-1.1.6. if you have any fix pleas send me Thanks Rudresh Johnson, Justin M (GE Infra, Energy) wrote: I ported U-Boot 1.1.6 to a custom board I am having trouble getting the TSECs to work. I am using an MPC8343 with the reduced interface, and a National Semiconductor DP83848 PHY. When I do a ping, I get the following result: = ping 192.168.0.100 Trying TSEC0 Speed: 100, full duplex Using TSEC0 device TSEC0: tsec: tx error TSEC0: tsec: tx buffers full ping failed; host 192.168.0 is not alive = When I try with the Freescale evaluation board running U-Boot 1.1.3, it works, so I am fairly confident of the network IP addresses, etc. = ping 192.168.0.100 Speed: 100, full duplex Using Freescale TSEC0 device host 192.168.0.100 is alive = I am new to all of this and an not sure what I am forgetting to set up. My board's config file is based on the MPC8349ADS.h file. I have read the README file and searched the mailing list, but haven't found (or completely missed) what I need. Below are some register values at the time the Tx Error occurred. Any help will be greatly appreciated. ***General Control and Status Registers (0x2_n000) Interrupt Event..: 0400 Interrupt Mask...: Error Disabled...: Ethernet Control.: 1018 Minimum Frame Length : 0040 Pause Time Value.: DMA Control..: 00C3 TBI PHY Address..: 001F ***Transmit Control and Status Registers (0x2_n100) Transmit Control.: Transmit Status..: Tx BD Data Length: Current TxBD Pointer.: TxBD Pointer.: 0FFFAB18 TxBD Base Address: 0FFFAB18 Out of Sequence TxBD.: 0800 Out of Sequence Tx Data Buffer Pointer...: ***MAC Registers (0x2_n500) MAC Configuration #1.: 0005 MAC Configuration #2.: 7105 Inter Packet Gap/Inter Frame Gap.: 40605060 Half-duplex..: 00A1F037 Maximum Frame: 0600 MII Management: Configuration: 0003 MII Management: Command .: 0001 MII Management: Address..: 1E10 MII Management: Control..: 0001 MII Management: Status...: 0115 MII Management: Indicators...: Interface Status.: 0008 Station Address, part 1..: 1B5B0046 Station Address, part 2..: E000 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ U-Boot-Users mailing list u-boot-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users -- View this message in context: http://www.nabble.com/NAND-boot-from-file-tp7930776p22369254.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Creating partitions on NAND flash
Hi All, I would like to partition the NAND flash on a canyonlands board. As per my understanding, the partitioning is done using the add_mtd_partitions function in the file drivers/mtd/mtdpart.c. I also understand that the information about a partition is stored in the structure : struct mtd_partition . I could not find out where this structure is getting populated in the u-boot code. Could somebody point out the file in which these partitions are created? I am also interested in knowing the file in which the different start / end addresses for these partitions are defined. On DaVinci EVM's I have found something like this when the u-boot comes up : Creating 5 MTD partitions on nand_davinci.0: 0x-0x0006 : bootloader 0x0006-0x0020 : params 0x0020-0x0040 : kernel 0x0040-0x0180 : filesystem 0x0180-0x0200 : data My aim is to add more such partitions on the NAND flash on my board. Any information regarding partitioning the flash is highly appreciated. Thanks in advance. Regards, Afzal Nadirshah http://www.mindtree.com/email/disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Support for PXA27X UDC.
Hi Remy, There are around ~70 warnings generated for pxa-regs.h for having more than 80 chars in a line, I have taken all the macro definitions from the linux kernel source code should I fix those warnings too ? Also pxa-regs.h already has many line with more than 80 chars. -- Thanks Vivek Kutal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Creating partitions on NAND flash
Dear Afzal Nadirshah, In message 174230991e95d743b0c91df471ef44e8434f1c5...@mtw02msg02.mindtree.com you wrote: I would like to partition the NAND flash on a canyonlands board. As per my understanding, the partitioning is done using the add_mtd_partitions function in the file drivers/mtd/mtdpart.c. Look at the mtdparts command. I also understand that the information about a partition is stored in the structure : struct mtd_partition . I could not find out where this structure is getting populated in the u-boot code. How about trying something like grep -lr mtd_partition * ? My aim is to add more such partitions on the NAND flash on my board. Any information regarding partitioning the flash is highly appreciated. Reading the documentation is usually pretty helpful. I really recommend it. See for example http://www.denx.de/wiki/DULG/UBootCmdGroupFlash#UBootCmdFlMtdparts and http://www.denx.de/wiki/view/DULG/BootTimeConfigurationOfMTDPartitions Also, you should definitely look into UBI support if you're using this on NAND flash. 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 Worlds may change, galaxies disintegrate, but a woman always remains a woman. -- Kirk, The Conscience of the King, stardate 2818.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Seperate mtdpart command from jffs2
Hi Kyungmin, On Tuesday 03 March 2009, Kyungmin Park wrote: Some program such as UBI only used the mtdpart only. however current jffs2 cmdline has dependent with jffs2 cmd This patch make a build only jffs2 cmdline without jffs2 cmd dependency. I tried to rephrase this description a little bit: Currently the mtdparts commands are included in the jffs2 command support. This doesn't make sense anymore since other commands (e.g. UBI) use this infrastructure as well now. This patch separates the mtdparts commands from the jffs2 commands making it possible to only select mtdparts when no JFFS2 support is needed. If you don't have any objections I suggest to use this description in your next patch version. Please find some more comments below. Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- diff --git a/common/Makefile b/common/Makefile index f13cd11..53ca648 100644 --- a/common/Makefile +++ b/common/Makefile @@ -98,6 +98,7 @@ COBJS-$(CONFIG_CMD_IMMAP) += cmd_immap.o COBJS-$(CONFIG_CMD_IRQ) += cmd_irq.o COBJS-$(CONFIG_CMD_ITEST) += cmd_itest.o COBJS-$(CONFIG_CMD_JFFS2) += cmd_jffs2.o +COBJS-$(CONFIG_JFFS2_CMDLINE) += cmd_mtdparts.o Shouldn't we change this define (CONFIG_JFFS2_CMDLINE) to something else now, since it's not really JFFS2 specific anymore? I suggest to change it to CONFIG_CMD_MTDPARTS. This seems more logical to me. What do you think? This patch also breaks (at least some) boards with JFFS2 support: [ste...@kubuntu u-boot (master)]$ ./MAKEALL fx12mm Configuring for fx12mm board... cmd_jffs2.c:164: warning: 'device_validate' defined but not used cmd_jffs2.c:220: warning: 'id_parse' defined but not used common/libcommon.a(cmd_flash.o): In function `do_protect': /home/stefan/git/u-boot/u-boot/common/cmd_flash.c:568: undefined reference to `id_parse' common/libcommon.a(cmd_flash.o): In function `do_flerase': /home/stefan/git/u-boot/u-boot/common/cmd_flash.c:362: undefined reference to `id_parse' make: *** [u-boot] Error 1 ppc_4xx-size: './u-boot': No such file I didn't try to solve this problem (yet). Perhaps you have an idea? Thanks. 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: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad CPU identification on MPC8544DS
On Tue, 2009-03-03 at 14:04 -0500, jeff angielski wrote: Despite the SVR being the same (0x803c0011), the latest u-boot is misidentifying the CPU when compared against the original 1.3.0 u-boot. The CPU is a 8544E but u-boot is reporting 8533E. The wierd part of this is that according to the Chip Errata for the MPC8544E, the SVR *should* be 0x803c01xx - which is different than both the 1.3 and latest git version are reading. Can any of the Freescale guys explain this discrepancy between the manual, the Freescale BSP u-boot, and the latest u-boot? The problem has been resolved. It would appear that two forces were at work. The older u-boot only looked at 16 bits when determining the CPU type and could incorrectly identify the various MPC85xx CPUs. The second issue was that the MPC8544DS hardware was being deployed with incorrect jumper settings. These jumpers relate to the CPU ID. Manufacturing never picked up on this error because of the first problem. So the latest u-boot is correct. -- Jeff Angielski The PTR Group www.theptrgroup.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH]OMAP3:Beagle: Enable mtdparts
http://www.denx.de/wiki/DULG/UBootCmdGroupFlash#UBootCmdFlMtdparts provides a flexible way to create and maintain u-boot mtd partitions. This allows commands such as nand erase fs to work and the user no longer needs to decode the absolute nand offsets. This patch enables this function for beagleboard Signed-off-by: Nishanth Menon n...@ti.com --- include/configs/omap3_beagle.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 9057606..c64999f 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -98,6 +98,11 @@ #define CONFIG_CMD_EXT2/* EXT2 Support */ #define CONFIG_CMD_FAT /* FAT support */ #define CONFIG_CMD_JFFS2 /* JFFS2 Support*/ +#define CONFIG_JFFS2_CMDLINE /* Enable MTD parts commands */ +#define MTDIDS_DEFAULT nand0=nand +#define MTDPARTS_DEFAULT mtdparts=nand:512k(x-loader),\ + 1920k(u-boot),128k(u-boot-env),\ + 4m(kernel),-(fs) #define CONFIG_CMD_I2C /* I2C serial bus support */ #define CONFIG_CMD_MMC /* MMC support */ -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Support for PXA27X UDC.
Hello Vivek, 2009/3/6 Vivek Kutal vivek.ku...@azingo.com: Hi Remy, There are around ~70 warnings generated for pxa-regs.h for having more than 80 chars in a line, I have taken all the macro definitions from the linux kernel source code should I fix those warnings too ? Also pxa-regs.h already has many line with more than 80 chars. Thanks for asking. If you look here: http://www.denx.de/wiki/U-Boot/CodingStyle, you will see that source files originating from different projects (for example the MTD subsystem or the hush shell code from the BusyBox project) may, after careful consideration, be exempted from these rules. For such files, the original coding style may be kept to ease subsequent migration to newer versions of those sources. Maybe you should also read this: http://www.denx.de/wiki/U-Boot/Patches Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help on getting the AT91 u-boot patch
On Thu, 2009-03-05 at 12:40 -0500, John Parten wrote: Hello Mailling List, I am trying to build U-Boot 1.3.4 from source, for the AT91SAM9260EK development board. I am following the instructions at http://www.linux4sam.org/twiki/bin/view/Linux4SAM/U-Boot I get to the point where it says take the AT91 u-boot patch set However, when I try to use ... wget http://www.linux4sam.org/twiki/pub/Linux4SAM/U-Boot/u-boot-1.3.4-exp.diff I get error 404 file not found Also I tried ... wget http://www.linux4sam.org/pub/uboot/u-boot-1.3.4-exp/u-boot-1.3.4-exp.diff as per the table a bit further down on the page - this does not work either. Can anyone tell me how to get the AT91 u-boot patch file please ? ... many thanks ... kind regards ... John Parten John, You are much better off using the mainline U-Boot at this point. It is far more stable and it's been getting better with each release. I looked at the 1.3.4 patch, and nearly all of those features are in 2009.01, plus more. The only major difference is that upstream does not support the AT91SAM9G20-EK. With that being said, this link seems to work: ftp://www.linux4sam.org/pub/uboot/u-boot-1.3.4-exp/u-boot-1.3.4-exp.diff You should probably contact the folks at Linux4Sam to tell them that their instructions are incorrect. -Justin Waters ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help on getting the AT91 u-boot patch
John Parten wrote: I am trying to build U-Boot 1.3.4 from source, for the AT91SAM9260EK development board. I thought that 1.3.4 worked out of the box for AT91SAM9260EK. 2009.01 and 2009.03-rc1 are broken for AT91SAM926x, but the patch in http://lists.denx.de/pipermail/u-boot/2009-February/048414.html should fix that. Detlef ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Request to remove my email address from your email list
Hi, Sir, please remove my email address from your email address, and thanks! Best Regards, Leeming New Email names for you! Get the Email name you#39;ve always wanted on the new @ymail and @rocketmail. Hurry before someone else does! http://mail.promotions.yahoo.com/newdomains/sg/___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] CFI: geometry reversal for STMicro M29W320DT
Follow up to the flash_fixup_stm to fix geometry reversal
on STMicro M29W320ET flash chip. The M29W320DT has 4 erase region.
Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com
---
My baseline is 2009.03-rc1. If there are STMicro/Numonyx guys on
this mailing list, can you help provide a more 'generic' way of
detection? this way the exception list does not have to grow a lot.
drivers/mtd/cfi_flash.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index a66feac..391d169 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1806,8 +1806,9 @@ static void flash_fixup_stm(flash_info_t *info, struct
cfi_qry *qry)
if (qry-num_erase_regions 1) {
/* reverse geometry if top boot part */
if (info-cfi_version 0x3131) {
- /* CFI 1.1, guess by device id (only M29W320ET now) */
- if (info-device_id == 0x2256) {
+ /* CFI 1.1, guess by device id (M29W320{DT,ET} only)
*/
+ if (info-device_id == 0x22CA ||
+ info-device_id == 0x2256) {
cfi_reverse_geometry(qry);
}
}
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CFI: geometry reversal for STMicro M29W320DT
On Friday 06 March 2009, Richard Retanubun wrote: Follow up to the flash_fixup_stm to fix geometry reversal on STMicro M29W320ET flash chip. The M29W320DT has 4 erase region. Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com --- My baseline is 2009.03-rc1. If there are STMicro/Numonyx guys on this mailing list, can you help provide a more 'generic' way of detection? this way the exception list does not have to grow a lot. Did you take a look at the Linux driver to see how this is handled there? Maybe they have a more generic solution... 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: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CONFIG_PRINT_TIME: Measuring boot time.
De : Wolfgang Denk Dear Benoit Monin, In message 13935170.21001.1236183410521.javamail@wwinf8202 you wrote: This option prefixes every console line with the time in seconds since power-up. It is inspired by the Linux kernel option PRINTK_TIME and uses the same output format. Thanks, but I reject this patch, as it adds only code bloat and slows down the boot process. The same effect can be acchieved by a few linex of expect code parsing the output - without adding code or slowing down the system. Plus it's not portable across all arch since ticks2usec only exists for ppc and sparc. Doing the same thing on the other side of the serial line is way smarter ! Thanks for your answer. Best regards, Wolfgang Denk Sincerely, Benoît. -- Créez votre adresse électronique prenom@laposte.net 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add the mfill and mcheck memory commands.
De : Wolfgang Denk Dear Benoit Monin, In message 28907262.11403.1236090567026.javamail@wwinf8303 you wrote: The mfill command writes the value of a counter to a memory area. The mcheck command verifies the memory area against the counter value. Those commands are useful for debugging memory/framebuffer controller. The configuration option is CONFIG_MFILL and this only takes effect if the memory commands are activated globally (CONFIG_CMD_MEM). What exactly is the purpose of this patch? Looks like an extremely simple memory test to me. Don't we have already a rich selection of better ones available yet? I should have detailed more the intent of those commands. We have here a video controller embedded in an fpga with its own video ram. We use mfill to fill the video ram as fast as possible with variable data for each vram address. And we use mcheck to verify (as fast as possible) the content of the vram. So this is not intended to test the main memory but it is a development and debug tool for peripheral containing memory. I've sent a patch because they are useful to us and generic enough, and might be handy for debugging accesses to memory mapped behind programmable logic. But maybe this debug tool is beyond the scope of U-Boot ? Best regards, Wolfgang Denk Sincerely, Benoît. -- Créez votre adresse électronique prenom@laposte.net 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help on getting the AT91 u-boot patch
On 15:37 Fri 06 Mar , Detlef Vollmann wrote: John Parten wrote: I am trying to build U-Boot 1.3.4 from source, for the AT91SAM9260EK development board. I thought that 1.3.4 worked out of the box for AT91SAM9260EK. 2009.01 and 2009.03-rc1 are broken for AT91SAM926x, but the patch in http://lists.denx.de/pipermail/u-boot/2009-February/048414.html should fix that. please give more details I use the HEAD of each release without any problem Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CFI: geometry reversal for STMicro M29W320DT
Stefan Roese wrote:
On Friday 06 March 2009, Richard Retanubun wrote:
Follow up to the flash_fixup_stm to fix geometry reversal
on STMicro M29W320ET flash chip. The M29W320DT has 4 erase region.
Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com
---
My baseline is 2009.03-rc1. If there are STMicro/Numonyx guys on
this mailing list, can you help provide a more 'generic' way of
detection? this way the exception list does not have to grow a lot.
Did you take a look at the Linux driver to see how this is handled there?
Maybe they have a more generic solution...
Hi Stefan,
Thanks for the comments. I took a quick look around /drivers/mtd,
but can't find a similar geometry reversal.
Unfortunately, I found this in:
/driver/mtd/chips/cfi_cmdset_0001.c
[snip]
{ CFI_MFR_ST, 0x00ba, /* M28W320CT */ fixup_st_m28w320ct, NULL },
{ CFI_MFR_ST, 0x00bb, /* M28W320CB */ fixup_st_m28w320cb, NULL },
[/snip]
By no means am I a CFI expert, but my impression is,
if there has to be a part number specific fixup function for any reason,
then it is a good indication that there are just some part specific peculiarity.
What utilities exist in Linux-world to do the equivalent of flinfo in u-boot,
just so I can see if Linux has a more generic way.
And just in case it matters, our board with these flash is MMU-less,
so if there is a different tool for uCLinux that will help too :)
- Richard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help on getting the AT91 u-boot patch
Jean-Christophe PLAGNIOL-VILLARD wrote: On 15:37 Fri 06 Mar , Detlef Vollmann wrote: John Parten wrote: I am trying to build U-Boot 1.3.4 from source, for the AT91SAM9260EK development board. I thought that 1.3.4 worked out of the box for AT91SAM9260EK. 2009.01 and 2009.03-rc1 are broken for AT91SAM926x, but the patch in http://lists.denx.de/pipermail/u-boot/2009-February/048414.html should fix that. please give more details I use the HEAD of each release without any problem Try 'bootp' on an DHCP server that not immediately responds. The timeouts are now in the range of 1ms instead of 1s. And I don't know what other parts except network is affected by get_timer() not returning ms values. Detlef ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 scanning bug
Hi Mark,
Don't you have JTAG debugger so you could find where exactly it hangs?
Or you can try adding debugging printf's to the source... I can't
reproduce your problem myself so that info would be useful.
Okay, I think I've found the problem.
When *not* using JFFS2_CMDLINE mode, U-Boot tries to work out the MTD
table automatically (for me using NOR flash, it's in the function
get_part_sector_size_nor() in cmd_jffs2.c).
Without specifying CONFIG_JFFS2_PART_SIZE, part-size defaults to
0x (use whole device).
However, the scanning code contains the line ...
end_phys = start_phys + flash-size;
... which, in this case, simply sets end_phys to (start_phys - 1).
Then the code has the lines ...
if (flash-start[i] = end_phys)
break;
... which results in an instant break, finally leaving the calculated
sector size as 0 !!
The attached patch seems to work for me, but probably needs double-checking
on some other platforms.
Regards
Mark
---
This patch fixes the JFFS2 scanning code when not using
CONFIG_JFFS2_CMDLINE.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
common/cmd_jffs2.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c
index d0a7cea..2f3b3a9 100644
--- a/common/cmd_jffs2.c
+++ b/common/cmd_jffs2.c
@@ -1814,7 +1814,12 @@ static inline u32 get_part_sector_size_nor(struct
mtdids *id, struct part_info *
flash = flash_info[id-num];
start_phys = flash-start[0] + part-offset;
- end_phys = start_phys + part-size;
+
+ if (part-size == SIZE_REMAINING) {
+ end_phys = start_phys + flash-size;
+ } else {
+ end_phys = start_phys + part-size;
+ }
for (i = 0; i flash-sector_count; i++) {
if (flash-start[i] = end_phys)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl: Don't spew messages related to PHY fixup of device tree
On Tue, Feb 17, 2009 at 8:45 PM, Kumar Gala ga...@kernel.crashing.org wrote: Converted print statements that didn't have much meaning beyond debug from printf() to debug(). Signed-off-by: Kumar Gala ga...@kernel.crashing.org I decided to solve this by removing the printfs. They aren't really useful for debugging, unless you're debugging the problems I already solved using them. :) They should have been removed before I committed the code. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
On Thu, Feb 19, 2009 at 9:45 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
This patch implements fdt_fixup_esdhc() function that is used to fixup
the device tree.
The function adds status = disabled propery if esdhc pins muxed away,
otherwise it fixups clock-frequency for esdhc nodes.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/mmc/fsl_esdhc.c | 22 ++
include/fsl_esdhc.h | 8
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 0ba45cd..fe8bd86 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -33,6 +33,8 @@
#include malloc.h
#include mmc.h
#include fsl_esdhc.h
+#include fsl_can_use.h
+#include fdt_support.h
#include asm/io.h
@@ -346,3 +348,23 @@ int fsl_esdhc_mmc_init(bd_t *bis)
{
return esdhc_initialize(bis);
}
+
+#ifdef CONFIG_MPC85xx
+#define ESDHC_COMPATIBLE fsl,mpc8536-esdhc
+#else
+#define ESDHC_COMPATIBLE fsl,mpc8379-esdhc
+#endif
Isn't there a more global means of doing this? I don't like having
the 8536/8379 in the driver, itself. Actually, there is. Move these
to the config file. But there should be a compatible property that
works for all esdhc devices.
Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
