Re: [U-Boot] SPI on PPC MPC85xx
Hi Matthias, Stefan Roese schrieb: Hi Matthias, On Wednesday 27 October 2010 08:55:42 Matthias Dunda wrote: unfortunately I have to push this message, as I received no comment on it, yet. Is there a reason why the immap_t is not implemented for mpc85xx? I tried to copy it from mpc8360 but there are so many dependent mpc83xx datatypes in that struct that I postponed the work on that, because I think it'll lead to no success... Even trying to use the soft SPI fails, because first thing the code does is using that immap_t datatype... :-( Does anyone have a comment on this? I took a quick glance at this. There are different versions of SPI controllers in the MPC8xxx SoC's. As it seems mpc8xxx_spi.c does only support the CPU- mode (meaning non-CPM/QE-mode) Freescale SPI controllers. This controller is implemented for example in the MPC8349. For your SoC (MPC8568) you need to implement the QE-mode which is currently not supported. I didn't compare the MPC85xx QE SPI controller with the MPC8xx CPM SPI controller, but maybe a look at arch/powerpc/cpu/mpc8xx/spi.c could help you as a base for porting/creating a driver? -- Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] variable substitution not working with cp.b
Hi André,
André Schwarz schrieb:
I'm running on MVBLM7 board using CONFIG_SYS_HUSH_PARSER.
While working on some scripts using env-variables holding some physical
address values I stumbled over this :
my env-variables used :
loadaddr=0x40
kernel_addr=0xff81000
kernel_len=0x20
mvBL-M7 erase $kernel_addr +$kernel_len
done
Erased 32 sectors
# - using variable as source doesn't work.
mvBL-M7 cp.b $load_addr $kernel_addr $kernel_len
cp - memory copy
Usage:
cp [.b, .w, .l] source target count
# - using addr as source works fine.
mvBL-M7 cp.b 0x40 $kernel_addr $kernel_len
Copy to Flash... done
mvBL-M7
Why does $load_addr not get expanded ?
Any ideas ?
Just some ideas:
- Mixed up loadaddr with load_addr?
- And do loadaddr resp. load_addr really exist?
- Tried using ${variable}, instead of $variable?
Kind regards,
Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Low BogoMIPS on MPC8541
Hi Kumar, Kumar Gala schrieb: On Oct 27, 2009, at 10:29 AM, Luigi 'Comio' Mantellini wrote: Hi All, I'm working on a stripped-down mpc8541 board (that has just a serian and twe enets). I have an issue on delay calibration. In fact at boot time, I see the following linux printk message on the serial console: Calibrating delay loop... 83.20 BogoMIPS (lpj=166400) The value seems reasonable. What freq is the core running at (guessing 833Mhz). My 1.5Ghz 8572 has a bogomips of 150. Seems that the value is about a tenth of the core frequency. I observed similar on TQM8548. Although I know, that the value is bogus (as the name tells), do you know the reason, why it isn't the core frequency? Thanks. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC85xx UPM NAND
Hi Alemao, Alemao schrieb: Hi all, I have used UPM in a MPC83xx with LBC running at 64MHz. Now I have a MPC85xx, with LBC at 41MHz. It only works if I put a delay in drivers/mtd/nand/fsl_upm.c : nand_write_buf(), otherwise I lost one byte. But it takes t long writing, which makes their use impractical. I saw in board/tqc/tqm85xx/nand.c that the driver use an UPM configuration for each frequency. Can some one tell me what signals I have to change or just some hint about what could be causing this behavior? Im using UPM waveform editor and u-boot-2009-03. The UPM tables and ORx settings for TQM85xx are optimized for each LBC frequency, the used NAND chips and the used PCB. To get the right timing for *your* HW you probably need a timing simulation before. Eventually, you have to connect a timing analyzer and check the bus signals after. If the timing is correct, check the right order of bus commands, too. The issue with the e500 core is, that it may reorder machine instructions. Perhaps you need to instert mbar instructions. Sorry, I'm not a HW guy, so I can't tell you more. I didn't do the simulation and analysis myself. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Timeout in tftp.c
Wolfgang Denk schrieb: Dear Achim Ehrlich, In message 4a0969fc.2060...@taskit.de you wrote: The timeout for lost packages in tftp.c is defined to 5000 msecs. But when setting the timeout get_timer(0) is called in NetSetTimeout in net.c. But on AT91 the timer code returns usecs and not msecs resulting in a timeout of 5 ms instead of 5 secs, which is kind of short. I looked in the timer code of other ARM-based platforms and they seem to use usec-based timers as well. Of course I can change the defined timeout in tftp.c to one second or so, but that doesn't seem to be the right way to solve this issue. Any suggestions or ideas or do I miss something here? Any chance that you are using an old version of U-Boot? Hi Achim, I'm interested in this, too. I observed timeouts on ARM11 (MX31), but couldn't do any investigation due to other projects. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ppc: using d-cache for C stack and as cache at the same time?
Hi, AFAIK, while running from flash, u-boot uses (part of) d-cache on some platforms for the C stack. I think, it's on MPC83xx and MPC85xx? Does anybody know, if I can use the remaining part of the d-cache as normal d-cache, e.g. to generate bursts on the SDRAM interface while testing the RAM? Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc: using d-cache for C stack and as cache at thesame time?
Liu Dave-R63238 schrieb: AFAIK, while running from flash, u-boot uses (part of) d-cache on some platforms for the C stack. I think, it's on MPC83xx and MPC85xx? Does anybody know, if I can use the remaining part of the d-cache as normal d-cache, e.g. to generate bursts on the SDRAM interface while testing the RAM? On which platform? Note that implementing a memory test that actually triggers burst mode accesses is really, really tricky. You probably do NOT want to do this while running from flash (i. e. from a very restrictive envrionment). You might want to have a look at examples/test_burst* but note that this code was written for a MPC8xx system, so changes will be required for 83xx or 85xx. Also note that a much more reliable test for burst mode errors is to boot Linux with root file system over NFS and then compile the Linux kernel on the target. It needs case by case. * 83xx, the whole d-cache is locked If you need generate bursts on DRAM interface, you have to change to way locked. Otherwise, you can use the DMA to generate burst. Good idea. * 85xx, half of d-cache is locked. it is possible to generate the burst at 85xx. Try to use dcbf Thank you for the hints. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc: using d-cache for C stack and as cache at the same time?
Dear Wolfgang Denk, Wolfgang Denk schrieb: Dear Jens Gehrlein, In message 49d323e5.9080...@tqs.de you wrote: AFAIK, while running from flash, u-boot uses (part of) d-cache on some platforms for the C stack. I think, it's on MPC83xx and MPC85xx? Does anybody know, if I can use the remaining part of the d-cache as normal d-cache, e.g. to generate bursts on the SDRAM interface while testing the RAM? On which platform? Note that implementing a memory test that actually triggers burst mode accesses is really, really tricky. You probably do NOT want to do this while running from flash (i. e. from a very restrictive envrionment). Why not? Of course, it's only possible if I can use a part of the D-Cache as C stack (or another internal RAM if available). This must be separately checked for each processor. You might want to have a look at examples/test_burst* but note that this code was written for a MPC8xx system, so changes will be required for 83xx or 85xx. Thank you for the hint. I'll have a look. Also note that a much more reliable test for burst mode errors is to boot Linux with root file system over NFS and then compile the Linux kernel on the target. I agree. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc: using d-cache for C stack and as cache at thesame time?
Peter Tyser schrieb: You should be able to use the 85xx DMA engine to generate the bursts too (I'd assume the same for 83xx, but never tried it). See cpu/mpc85xx/cpu.c dma_*(). The default values of the satr0 and datr0 don't allow the processor to snoop transactions, so you'd have to use cache operations or change datr0/satr0 to something like 0x5 for your tests. We've added a very basic DMA test to the mtest command which is used for board testing here. Let me know if you'd like me to send it - its not cleaned up but could give you a starting point. Although, I will not start before next month with burst testing, it would be very nice, if could send it. Thank you very much. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] video: mx3fb: board specific settings?
Hi, currently drivers/video/mx3fb.c contains some defines, which are usually board specific: #define XRES240 #define YRES320 #define PANEL_TYPE IPU_PANEL_TFT #define PIXEL_CLK 185925 #define PIXEL_FMT IPU_PIX_FMT_RGB666 #define H_START_WIDTH 9 /* left_margin */ #define H_SYNC_WIDTH1 /* hsync_len */ #define H_END_WIDTH (16 + 1)/* right_margin + hsync_len */ #define V_START_WIDTH 7 /* upper_margin */ #define V_SYNC_WIDTH1 /* vsync_len */ #define V_END_WIDTH (9 + 1) /* lower_margin + vsync_len */ #define SIG_POL (DI_D3_DRDY_SHARP_POL | DI_D3_CLK_POL) #define IF_CONF 0 #define IF_CLK_DIV 0x175 What could be done to remove these defines? 1. #ifdefery - seems to be the worst solution 2. a structure, filled by board code 3. any other ideas? What has to be done else? For instance, parts of lcd_enable() seem to be board specific, too (pin muxing, display brightness, ...). Thanks. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8548 CPU v2 errata
hendrik schrieb: Thank you Jens, I found MPC8458ECE Rev. 2 but can not find a page 2 or errata considering CPU 1.1 to 2.1 is there another link to the document? Within this document, a very lengthy table 3, starting at page 2, describes (hopefully ;-) ) all known errata. On the right side there are five columns describing for which processor version each erratum applies. Please try this: http://www.freescale.com/files/32bit/doc/errata/MPC8548ECE.pdf?fpsp=1WT_TYPE=ErrataWT_VENDOR=FREESCALEWT_FILE_FORMAT=pdfWT_ASSET=Documentation This should open the PDF within your browser, if configured. Then you can save the document to disk. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TQM85xx: Fix a couple warnings in TQM8548 build
Hi Andy, Andy Fleming schrieb: The ecm variable in sdram.c was being declared for all 8548, but only used by specific 8548 boards, so we make that variable require those specific boards, too [snip] diff --git a/board/tqc/tqm85xx/sdram.c b/board/tqc/tqm85xx/sdram.c index 2b3de44..6d73a88 100644 --- a/board/tqc/tqm85xx/sdram.c +++ b/board/tqc/tqm85xx/sdram.c @@ -79,7 +79,9 @@ long int sdram_setup (int casl) volatile ccsr_ddr_t *ddr = (void *)(CONFIG_SYS_MPC85xx_DDR_ADDR); #ifdef CONFIG_TQM8548 volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); +#if defined(CONFIG_TQM8548_AG) || defined(CONFIG_TQM8548_BE) volatile ccsr_local_ecm_t *ecm = (void *)(CONFIG_SYS_MPC85xx_ECM_ADDR); +#endif #else /* !CONFIG_TQM8548 */ unsigned long cfg_ddr_timing1; unsigned long cfg_ddr_mode; Currently ecm is only used in DDR20 workaround. Strictly speaking, this workaround should apply to all TQM8548, not only to its variants AG and BE, because it's valid for all CPU revisions. I overlooked this, when reviewing the patch MPC85xx: TQM8548: workaround for erratum DDR 19 and 20. But I'm fine with the current code and your patch for now. Currently, there are no other TQM8548 variants than AG and BE. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8548 CPU v2 errata
Hi hendrik, hendrik schrieb: Hi all could someone pls point me to where i can find documentation regarding changes and the implications there of between die Freescale mpc8548 v1 and v2 silicone CPUs. I have searched Freescales website but only turned up errata concerning the reference manual: Errata to MPC8548E PowerQUICC™ III Integrated Host Processor Family Reference Manual, Rev. 2 There is also an errata sheet MPC8458ECE Rev. 2 for the processor. See Tab Documentation of MPC8548E. On page 2 you will find a table of errata considering CPU 1.1 to 2.1 Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] CFI: increase performance
Hi Stefan, Stefan Roese schrieb: On Tuesday 16 December 2008, Jens Gehrlein wrote: The following patches should increase the performance of the CFI driver, particularly with regard to single word programming mode. I tested it on TQM5200S with NOR-Flash Samsung K8P2815UQB, which has no write buffer. At least no write buffer, that could be programmed using standard commands. Performance increase on this TQM is about factor 2.6 (37 KiB/s - 95 KiB/s). On the same module with Spansion S29GL128N (with write buffer) it is about factor 1.2 (455 KiB/s - 585 KiB/s). TQM5200 is a bottom boot module with 2x16 Bit Flash connection. Could someone test the patches on other HW, particularly top boot, other CPU, other flash width, please? Tested on AMCC Kilauea (PPC405EX, with 1*16bit Spansion S29GL512N. The S29GL512N has a write buffer, AFAIK. Thus, U-Boot chooses another programming algorithm. Possibly, you only tested patch 2 or did you override buffered programming for your test so that patch 1 was included? Patch series applied to u-boot-cfi-flash/master. Thanks. Nice, thanks. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] CFI: increase performance
Hi list, The following patches should increase the performance of the CFI driver, particularly with regard to single word programming mode. I tested it on TQM5200S with NOR-Flash Samsung K8P2815UQB, which has no write buffer. At least no write buffer, that could be programmed using standard commands. Performance increase on this TQM is about factor 2.6 (37 KiB/s - 95 KiB/s). On the same module with Spansion S29GL128N (with write buffer) it is about factor 1.2 (455 KiB/s - 585 KiB/s). TQM5200 is a bottom boot module with 2x16 Bit Flash connection. Could someone test the patches on other HW, particularly top boot, other CPU, other flash width, please? Thanks, Jens --- Jens Gehrlein (2): CFI: increase performance of function find_sector() CFI: avoid redundant function call in single word programming mode drivers/mtd/cfi_flash.c | 33 +++-- 1 files changed, 23 insertions(+), 10 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] CFI: avoid redundant function call in single word programming mode
The function find_sector() doesn't need to be called twice in
the case of AMD command set.
Tested on TQM5200S-BD with Samsung K8P2815UQB.
Signed-off-by: Jens Gehrlein se...@tqs.de
---
drivers/mtd/cfi_flash.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index e8afe99..1bd0e2b 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -795,7 +795,8 @@ static int flash_write_cfiword (flash_info_t * info, ulong
dest,
{
void *dstaddr;
int flag;
- flash_sect_t sect;
+ flash_sect_t sect = 0;
+ char sect_found = 0;
dstaddr = map_physmem(dest, info-portwidth, MAP_NOCACHE);
@@ -840,6 +841,7 @@ static int flash_write_cfiword (flash_info_t * info, ulong
dest,
sect = find_sector(info, dest);
flash_unlock_seq (info, sect);
flash_write_cmd (info, sect, info-addr_unlock1, AMD_CMD_WRITE);
+ sect_found = 1;
break;
}
@@ -864,8 +866,10 @@ static int flash_write_cfiword (flash_info_t * info, ulong
dest,
unmap_physmem(dstaddr, info-portwidth);
- return flash_full_status_check (info, find_sector (info, dest),
- info-write_tout, write);
+ if (!sect_found)
+ sect = find_sector (info, dest);
+
+ return flash_full_status_check (info, sect, info-write_tout, write);
}
#ifdef CONFIG_SYS_FLASH_USE_BUFFER_WRITE
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] CFI: increase performance of function find_sector()
Tested on TQM5200S-BD with Samsung K8P2815UQB
Signed-off-by: Jens Gehrlein se...@tqs.de
---
drivers/mtd/cfi_flash.c | 23 ---
1 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 1bd0e2b..bc5e151 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -774,17 +774,26 @@ static void flash_add_byte (flash_info_t * info,
cfiword_t * cword, uchar c)
}
}
-/* loop through the sectors from the highest address when the passed
- * address is greater or equal to the sector address we have a match
+/*
+ * Loop through the sector table starting from the previously found sector.
+ * Searches forwards or backwards, dependent on the passed address.
*/
static flash_sect_t find_sector (flash_info_t * info, ulong addr)
{
- flash_sect_t sector;
+ static flash_sect_t saved_sector = 0; /* previously found sector */
+ flash_sect_t sector = saved_sector;
- for (sector = info-sector_count - 1; sector = 0; sector--) {
- if (addr = info-start[sector])
- break;
- }
+ while ((info-start[sector] addr)
+(sector info-sector_count - 1))
+ sector++;
+ while ((info-start[sector] addr) (sector 0))
+ /*
+* also decrements the sector in case of an overshot
+* in the first loop
+*/
+ sector--;
+
+ saved_sector = sector;
return sector;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] CFI: increase performance
Jean-Christophe PLAGNIOL-VILLARD schrieb: On 17:25 Tue 16 Dec , Jens Gehrlein wrote: Hi list, The following patches should increase the performance of the CFI driver, particularly with regard to single word programming mode. I tested it on TQM5200S with NOR-Flash Samsung K8P2815UQB, which has no write buffer. At least no write buffer, that could be programmed using standard commands. Performance increase on this TQM is about factor 2.6 (37 KiB/s - 95 KiB/s). On the same module with Spansion S29GL128N (with write buffer) it is about factor 1.2 (455 KiB/s - 585 KiB/s). TQM5200 is a bottom boot module with 2x16 Bit Flash connection. Could someone test the patches on other HW, particularly top boot, other CPU, other flash width, please? Could you try it against the qemu SVN HEAD ??? Sorry, what is qemu SVN HEAD ??? P.S.: I still can't reply to your e-mail address... Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] CFI: increase performance
Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD schrieb: On 17:46 Tue 16 Dec , Jens Gehrlein wrote: Jean-Christophe PLAGNIOL-VILLARD schrieb: On 17:25 Tue 16 Dec , Jens Gehrlein wrote: Hi list, The following patches should increase the performance of the CFI driver, particularly with regard to single word programming mode. I tested it on TQM5200S with NOR-Flash Samsung K8P2815UQB, which has no write buffer. At least no write buffer, that could be programmed using standard commands. Performance increase on this TQM is about factor 2.6 (37 KiB/s - 95 KiB/s). On the same module with Spansion S29GL128N (with write buffer) it is about factor 1.2 (455 KiB/s - 585 KiB/s). TQM5200 is a bottom boot module with 2x16 Bit Flash connection. Could someone test the patches on other HW, particularly top boot, other CPU, other flash width, please? Could you try it against the qemu SVN HEAD ??? Sorry, what is qemu SVN HEAD ??? In qemu you have 2 boards emulated with u-boot support qemu_mips and SX1 Now, I understand, what you meant. it'll be nice to test them also please note they are only in the SVN tree of qemu Because I'm neither familiar with qemu nor with svn I can't do that with little effort (installation, familiarization, etc.). Beside that, how could a virtual machine simulate the real bus access with it's bus timing? If I'm right in this point, only testing on another architecture is possible, but no performance test. Shortly, I will get a TQM8548 with Samsung Flash. It's a top boot system, but also has a 2x16 Bit Flash connection. For my part, I can only offer you a test on this board. Stefan, as the CFI custodian, how is your procedure to check such kind of common code patches? Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Size optimization of start.S
Hi Scott, Scott Wood schrieb: On Mon, Dec 15, 2008 at 08:26:03AM +0100, Jens Gehrlein wrote: Hi Ron, Ron Madrid schrieb: Currently there are in excess of 100 bytes located at the beginning of the image built by start.S that are not being utilized. Hmmm, are you sure? What if someone designs a board, where the processor shall load its reset configuration from a local bus EEPROM, e.g. the same NOR-Flash containing the U-Boot image (CFG_RESET_SOURCE[0:2] = 000b? Or did I misunderstand something? That's covered by the _HRCW_TABLE_ENTRY lines earlier in the file. I see. I understood Ron's comment as first 100 hex bytes. Thanks for the hint, Scott. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Size optimization of start.S
Hi Ron, Ron Madrid schrieb: Currently there are in excess of 100 bytes located at the beginning of the image built by start.S that are not being utilized. Hmmm, are you sure? What if someone designs a board, where the processor shall load its reset configuration from a local bus EEPROM, e.g. the same NOR-Flash containing the U-Boot image (CFG_RESET_SOURCE[0:2] = 000b? Or did I misunderstand something? Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CFI: flash_write_cfiword() slow
Hi Wolfgang, Wolfgang Denk schrieb: Dear Jens Gehrlein, In message 490edd63.1010...@tqs.de you wrote: find_sector() loops through the sector table from the last sector to the current sector. And the more sectors the device has, the slower the algorithm becomes. And this process for every sector to be programmed. And yes, there are still devices around without (standard) write buffer, e.g. the Samsung K8P2815UQB. A classic (and trivial to implement) approach is not to start searching at the end, but at the last used sector (assuming search driection and direction of growth are identical). Okay. Because I never have seen, that a flash has been written backwards, as a prerequisite I have to change the loop from counting down to counting up. Any objections? This way, you will typically find the match either immediately or with a single step. Maybe you want to give that a try... I'm currently trying :-) Had some other projects in the meantime. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CFI: flash_write_cfiword() slow
Hi list, having a look at function drivers/mtd/cfi_flash.c::flash_write_cfiword(), I found that find_sector() is called twice when having AMD standard, extended or legacy device. The first time, when writing the command. The second time, when calling flash_full_status_check(). Maybe this is the reason, why this programming mode is so slow. find_sector() loops through the sector table from the last sector to the current sector. And the more sectors the device has, the slower the algorithm becomes. And this process for every sector to be programmed. And yes, there are still devices around without (standard) write buffer, e.g. the Samsung K8P2815UQB. Before spending time to create a patch, I would like to read your opinion about this proposal/question: Would it be sufficient to just add a flag, that indicates, that the sector number has already been calculated for AMD flashes or would it be better to pass parameters to flash_full_status_check() dependent on the command set? Other proposals? Do you see any unwanted side effects? -- Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Custodian update
Wolfgang Denk schrieb: Hi everybody, here some custodian news: 1) Kyungmin Park is now custodian for the (new) u-boot-ubi reposi- tory where UBI related work will be added. Thanks to Kyungmin Park for volunteering. 2) Anatolij Gustschin is now custodian for the u-boot-video reposi- tory where graphics and video driver related work will be added. Thanks to Anatolij Gustschin for volunteering, and thanks to Rodolfo Giometti for his work done so far. What's about the ARM custodian entry in U-Boot's Gitweb? Peter or Jean-Christophe? -- Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Fix the NAND size overflow issue.
Hi Jason,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jason Jin
Sent: Friday, September 19, 2008 11:33 AM
To: [EMAIL PROTECTED]
Cc: u-boot@lists.denx.de; Jason Jin
Subject: [U-Boot] [PATCH 1/4] Fix the NAND size overflow issue.
When the NAND size is or large than 4G, the size will overflow,
The adjustment in this patch try to fix this.
Signed-off-by: Jason Jin [EMAIL PROTECTED]
---
drivers/mtd/nand/nand.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/nand.c b/drivers/mtd/nand/nand.c
index ebd2acd..71a0e4b 100644
--- a/drivers/mtd/nand/nand.c
+++ b/drivers/mtd/nand/nand.c
@@ -63,11 +63,11 @@ void nand_init(void)
unsigned int size = 0;
for (i = 0; i CFG_MAX_NAND_DEVICE; i++) {
nand_init_chip(nand_info[i], nand_chip[i],
base_address[i]);
- size += nand_info[i].size;
+ size += nand_info[i].size / 1024;
if (nand_curr_device == -1)
nand_curr_device = i;
}
- printf(%u MiB\n, size / (1024 * 1024));
^
According to this line I suppose, the value of nand_info[i].size
is in Bytes. So, if the NAND chip is = 4 GiB this variable
has already been overflowed, when nand_init_chip returns.
Indeed, I didn't check the source code of the NAND driver. Am I
wrong or did you modify the driver?
Kind Regards,
Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Watchdog doesn't get triggered on U-Boot command line
Hi Wolfgang, hi Andrew, Please restrict your line length to something readable, i. e. some 70 characters or so. Thanks. OK. It seems Outlo*k needs some manual override... Hope, this mail is better... Is it intended, that the watchdog isn't triggered in U-Boot's interactive mode? I can't believe that. Or did I missed something? Normally the console I/O routines will trigger the watchdog while waiting for characters to arrive or to be sent. Obviously you missed to add such code. On 2008-09-14 in Re: [U-Boot] Watchdog support. you wrote to Luigi, that this souldn't be necessary. Why couldn't it be in the main loop of U-Boot? Andrew, I read the mail thread but didn't quite unterstand it, especially it was about PPC and MIPS. Now, I see more clear. It seems, PPC uses real interrupts. Up to now I thought U-Boot doesn't handle interrupts at all. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull request
Wolfgang Denk schrieb: Dear Jean-Christophe PLAGNIOL-VILLARD, In message [EMAIL PROTECTED] you wrote: Hi Wolfgang, please pull The following changes since commit afe3848b79a7ff351e9fbf3a7c162d2de002279b: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-ppc4xx are available in the git repository at: git://git.denx.de/u-boot-arm.git master Gururaja Hebbar K R (2): Add ARM AMBA PL031 RTC Support Correct ARM Versatile Timer Initialization Hugo Villeneuve (2): ARM DaVinci: Fix compilation error with new MTD code. ARM DaVinci: Removed redundant NAND initialization code. Jens Gehrlein (1): MX31: fix bit masks in function mx31_decode_pll() Hm... this looks strange to me - is there any special reason that you select and apply patch 02/10 from Jens' series, but omit all the other 9 patches? There are still issues with the other patches (some comments from the ML). I have to rework them as soon as there is time. Additionally, Magnus submitted patches, which overlap my patches. I first have to rebase. But the patch above applies applies independently. Thank you Jean-Christophe for picking up. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand_spl/nand_boot.c: why can't we do anything on ECC error?
Scott Wood schrieb: On Wed, Aug 13, 2008 at 07:03:25PM +0200, Jens Gehrlein wrote: Hi, in nand_spl/nand_boot.c in function nand_read_page() one can read the comment in the case of ECC errors: No chance to do something with the possible error message from correct_data(). We just hope that all possible errors are corrected by this routine. Why can't we do anything? We can't fit printf() into the 4K NAND loader. We could fit puts(), though (it's included on 8313erdb's NAND loader). If an uncorrectable error has been recognized, we could at least execute an endless loop or issue a reset. Depending on the bit errors and their location in the U-Boot image, U-Boot may though boot and a runtime error could probably appear never or later or only under special circumtances. Because this is a risk (the image is corrupted), what do you think of inserting some blocking functionality? I'm open to halting if the image is corrupt (it's what nand_boot_fsl_elbc does), though I'm concerned about boards bricking when they might survive well enough to reflash. What about a function pointer or similar, so that the developer could decide himself what to do in this new routine? Of course, it has to fit into the 4 KiB block. In some cases it could be meaningful to block in order not to run into a critical state because, for instance, peripheral HW has been wrongly initialized. We should definitely try to get some sort of message out. Better than nothing, although some boards won't be connected to, for instance, a serial terminal in the end version at the customer's site. Dependent on the board and it's application there may be no chance to signal the problem to the user. One way, for instance, is that it just doesn't boot. The service staff or board vendor could at least do a post analysis if the error is reproducible. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
