Hello Mudit,
On Sunday 28 of August 2016 09:27:16 Mudit Jain wrote:
> Hi,
>
> That's great news Pavel.
> Should I start merging all your findings and push it as a patch ?
> What would be the next steps ?
I suggest to invest the time into SD part of the project now.
It needs to use DMA as well. As I have seen, there is/or has been
copy of DMA support in libbsd code. It is necessary to decide
where DMA implementation would sit. There should be only
single implementation to make system maintainable.
Even if two independent APIs are used then channels (resources)
allocation has to be managed by single code.
Try to push SD part code to the state where it reads
sectors through device.
If you compile shell into RTEMS application you can use something
like
hexdump -n 512 /dev/sd-device
to read actual SDcard content. You need to config RTEMS with
#define CONFIGURE_SHELL_COMMANDS_INIT
#define CONFIGURE_SHELL_COMMANDS_ALL
#define CONFIGURE_SHELL_MOUNT_MSDOS
#define SHELL_TASK_PRIORITY 50
and start shell from Init by call like
rtems_shell_init("SHLL",RTEMS_MINIMUM_STACK_SIZE+0x1000,
SHELL_TASK_PRIORITY,"/dev/console",1,0, NULL);
As for the actual DMA API code. It can be considered as initial
base for experiments but it is far from mergeable state.
It has to be cleaned, may it be, it worth to think about
some generalized DMA API which can be used by multiple targets
and then rewrite code to that concept.
So you can take my branch, reorganize and merge patches
to have initial DMA support introduction patch done right
way and functional. You can even send it for review
to document the work and get feedback but expect that
most of the code would require discussion and rewrite.
Good thing is, that evolution can be incremental
and can be tested that it works still after each iteration.
Best wishes,
Pavel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
