On Wed, Oct 10, 2012 at 11:32 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > On Wed, Oct 10, 2012 at 10:57:12AM +0200, vj wrote: >> On Wed, Oct 10, 2012 at 9:40 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: >> > On Tue, Oct 09, 2012 at 12:55:10AM +0200, Vicente wrote: >> >> This patch series is the same as before except for: >> >> [PATCH 03/13] ARM: ensure irqs are disabled >> >> imported irq handling from linux >> >> [PATCH 07/13] uimage: improve transfer speed >> >> solved a compile warning >> > >> > I applied most of this series, please check the result in the -next >> > branch. >> > >> >> I'll check this week > > Thanks. The -next branch works "out-of-the-box". So exiting from barebox leaving the interrupts enabled is not critical. > >> > Of course haven't applied this one >> > >> >> It wasn't meant to be applied > > I know, just thought I'd mention it anyway > >> >> >> omap4: add usb boot source >> >> bootm: close open files >> > >> >> uimage: improve transfer speed >> > >> > Haven't applied this one as you haven't answered my question how >> > much improvement (and on which media) we get. >> >> Yes, it's answered, see: >> http://lists.infradead.org/pipermail/barebox/2012-October/010208.html > > Ups, missed that. That's really a huge speed gain. I wonder why this > happens. Maybe the overhead of request/release sdram region is > significant with MMU disabled. Could you play with the BUFSIZ parameter > to see if there's a good compromise between speeding up your transfer > and still sensible buffer sizes? Here are the results: 13133*PAGE_SIZE: Transferred 53789775 bytes in 3.326 seconds at 15.419 MBps 64*PAGE_SIZE: Transferred 53789775 bytes in 3.478 seconds at 14.748 MBps 32*PAGE_SIZE: Transferred 53789775 bytes in 3.655 seconds at 14.031 MBps 16*PAGE_SIZE: Transferred 53789775 bytes in 3.987 seconds at 12.865 MBps 8*PAGE_SIZE: Transferred 53789775 bytes in 4.540 seconds at 11.297 MBps 4*PAGE_SIZE: Transferred 53789775 bytes in 5.876 seconds at 8.729 MBps 2*PAGE_SIZE: Transferred 53789775 bytes in 8.249 seconds at 6.218 MBps Note: 13133 is reading the file at once. > > BTW I wonder if it would be possible to use the MMU in your setup. We > have a 1:1 flat mapping which should be no problem for the ROM code. > You probably would have to use dma_alloc_coherent to allocate the > buffers which are used for USB transfers. Tested with MMU enabled having the buffers on local stack: fail with buffers allocated with xzalloc: fail with dma_alloc_coherent: fail all of them freezes when calling the ROM function omap4_usbboot_pdata.io->write(...) also tried this initcalls, all with same result: core_initcall(omap4_usbboot_init); postmmu_initcall(omap4_usbboot_init); Why it doesn't work? I don't know. But if anybody wants to investigate attached is the ROM code which is placed at offset 0x00030000. The entry points used by barebox are: omap4_usbboot_pdata.io->init : 0x000340e3 omap4_usbboot_pdata.io->read : 0x00034289 omap4_usbboot_pdata.io->write : 0x00034259 omap4_usbboot_pdata.io->close : 0x00034075 omap4_usbboot_pdata.io->config: 0x000342bb which surely are wrong because aren't dword aligned! I'm lost. > > Sascha > > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
rom.bin.gz
Description: GNU Zip compressed data
_______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
