Re: [Bug report] memset is stranger when i use SD_CARD_BENCH program with DMA.

[김은석]

Hellow Norman

 

Thank you for your reply mail. ^^ 

I have tested follow source.

 

genode/os/src/drivers/sd_card/omap4/bench/main.cc          <------ source of os/run/sd_card_bench.run script.

 

I just little modify the source for test data accuration of native write and read with DMA mode.

I wanna know why data is not conformed each other.

Could you please advice me, about this issue.

 

Have a nice day, Norman.

 

Eun Seok, Kim.

 

 

 

 

int main(int argc, char **argv)
{
 using namespace Genode;

 printf("--- OMAP4 SD card benchmark ---\n");

 bool const use_dma = true;

 static Block::Omap4_driver driver(use_dma);

 static Timer::Connection timer;

 long const request_sizes[] = {
  512, 1024, 2048, 4096, 8192, 16384 }; //, 32768, 64*1024, 128*1024, 0 };

 /* total size of communication buffer */
 size_t const buffer_size = 16384 ;  //10*1024*1024;


~~~~~~~~~~~~~~~~~~skip ~~~~~~~~~~~~~~~~~~~~~~

 

 } write_operation;

 

 for (unsigned i = 0; request_sizes[i]; i++)
          run_benchmark(driver, timer, buffer_virt, buffer_phys, buffer_size, request_sizes[i], write_operation);

 

Genode::printf("========== hexdump context of write-buf. ===========\n");
 Genode::memset( buffer_virt, 'a', buffer_size );
 hexdump_func( buffer_virt, buffer_size );             // Disply data of buffer_virt by printf.

 run_benchmark(driver, timer, buffer_virt, buffer_phys, buffer_size, 16384, write_operation );
destroy( env()->heap() , pre_buf );

 

 static Attached_ram_dataspace read_buf(env()->ram_session(), buffer_size, false);
 char * const read_virt = read_buf.local_addr<char>();
 addr_t const read_phys = Dataspace_client(read_buf.cap()).phys_addr();

 

Genode::printf("========== hexdump context of read buf. ===========\n");
 run_benchmark(driver, timer, read_virt, read_phys, buffer_size, 512, read_operation );
 hexdump_func( read_virt, buffer_size );           // Display data of read_virt by printf.

 


 printf("\n--- OMAP4 SD card benchmark finished ---\n");
 sleep_forever();
 return 0;
}


 

-----Original Message-----
From: "Norman Feske"<norman.feske at ...1...> 
To: <genode-main at lists.sourceforge.net>; 
Cc: 
Sent: 2012-10-27 (토) 04:50:48
Subject: Re: [Bug report] memset is stranger when i use SD_CARD_BENCH program with DMA.

Hello,

thanks for your interest in Genode and welcome to the list!

> To compare a data before writing in the SD_CARD to a data after
> reading from the SD_CARD. I use memset function to fill write_buffer
> with simple-data 'a' before the program write to th sd_card. then,
> write_buffer size is 16kbyte and require size is 16kbyte.
> 
> But, result of memset function is failed.
> Follow is the report in terms of this Issue. And, result of memset
> function is successed when I have tested the program with
> Not_USE_DMA-mode. Could you please advice me why result is failed.

I am afraid the log output of the modified version of the SD-card
benchmark does not help much for diagnosing your problem without having
insight into the source code of your modified version. If you seek
useful advice, I recommend you to post your modifications. You might
post a patch or provide a link to a branch at GitHub.

> And, readed data after reading from the sd_card is not conformed with
> write_buffer context when I use Not_USE_DMA-mode. I use write_buffer
> size is 16kbyte, requir_size is 16kbyte when i writing the data to
> the sd_card. I use read_buffer size is 16kbyte, requir_size is
> 512byte when i reading the data from the sd_card. Please, Advice me
> about this problem.

Does the benchmark work without your modifications? Have you also tried
the 'os/run/sd_card.run' test just to make sure that there are no
fundamental issues with the SD card or the driver?

> And, I want to know how to use env()->heap() function instead of
> Attached_ram_dataspace structure in the program.

The heap is not meant for allocating DMA buffers. Hence, there is no way
to obtain the physical adresses of memory allocated from the heap. This
is intended because memory handed out by the heap may (principally) be
paged out or physically non-contigious.

> Example,------------------------------------------------------------------------------------------------
> static Attached_ram_dataspace buffer(env()->ram_session(), buffer_size, false);
> char * const buffer_virt = buffer.local_addr<char>();
> addr_t const buffer_phys = Dataspace_client(buffer.cap()).phys_addr();
> Example, ------------------------------------------------------------------------------------------------
> 
> Do you know how to know virtual_address, and physical_address when i
> use "new (env()->heap())T" instead of Attached_ram_dataspace
> structure. Please, Advice me about these Issue.

The virtual address is the pointer value returned by the new operator.
The physical address cannot be obtained. DMA buffers must be allocated
directly from core's RAM service (i.e., using
'env()->ram_session()->alloc()') and attached to the local address space
via core's RM session (using 'env()->rm_session()->attach()'). The
'Attached_ram_dataspace' class is just a convenience helper for this
procedure.

I am just curious, for which reason do you want to allocate DMA buffers
from the heap?

Best regards
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

------------------------------------------------------------------------------
WINDOWS 8 is here. 
Millions of people. Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/
_______________________________________________
Genode-main mailing list
Genode-main at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20121027/3d44d531/attachment.html>