RTEMS 14-03-14 tests on CSB336 - SPI SD-card correction etc.

[Gedare Bloom]

On Sun, Mar 30, 2014 at 6:51 PM, Pavel Pisa <ppisa4lists at pikron.com> wrote:
> Hello Sebastian and others,
>
> I have found time to test RTEMS GIT on LPC1788
> in last days and it works OK. I have tried to
> run code on CSB336/MXS based platform and I have
> noticed two problems.
>
> The firs is broken filesystem embedding at least
> on my setup. The embedded untar breaks if directory
> already exists. And default tar includes './'
> in archive. Next change/workaround solves the problem
>
> diff --git a/cpukit/libmisc/untar/untar.c b/cpukit/libmisc/untar/untar.c
> index 5f1699d..11a6cc6 100644
> --- a/cpukit/libmisc/untar/untar.c
> +++ b/cpukit/libmisc/untar/untar.c
> @@ -224,6 +224,8 @@ Untar_FromMemory(
>        else if (linkflag == DIRTYPE)
>        {
>           if ( mkdir(fname, S_IRWXU | S_IRWXG | S_IRWXO) != 0 ) {
> +           if (!strcmp(fname, "/") || !strcmp(fname, "./"))
> +             continue;
>             printk("Untar: failed to create directory %s\n", fname);
>             retval = UNTAR_FAIL;
>             break;
>
> But I think that it should not be solved this way.
> I expect that  use of stat() libc function to check for directory
> existence before mkdir attempt is better. If you agree with
> this solution, I can prepare patch.
>
Yes it will be better to check if the directory already exists. Unless
you can get this info from the return code from mkdir, then using stat
seems to be appropriate.
-Gedare

> I have tested SD-card support on git RTEMS version as well.
> There is one obvious problem introduced when core block devices
> API has been changed. I am sending patch for this problem as followup.
> But there seems to be some yet another problem on our HW even
> after this correction. The fix helps that a partition is correctly
> recognized but write has some problems. But that is for some
> other drop of available time and can be really only problem of our
> HW.
>
> Best wishes,
>                 Pavel
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel