On 9/25/2012 9:27 AM, Ed Sutter wrote:
> On 9/24/2012 3:11 PM, Ed Sutter wrote:
>> On 9/21/2012 8:02 AM, Ed Sutter wrote:
>>> On 9/20/2012 8:22 PM, Charles Manning wrote:
>>>> On Friday 21 September 2012 11:32:26 Charles Manning wrote:
>>>>> On Friday 21 September 2012 08:19:16 Ed Sutter wrote:
>>>>>> On 9/20/2012 1:18 PM, Ed Sutter wrote:
>>>>>>> On 9/17/2012 1:17 PM, Ed Sutter wrote:
>>>>>>>> Hi,
>>>>>>>> What is the status of building "yaffs direct"? Based on a
>>>>>>>> different
>>>>>>>> thread
>>>>>>>> (http://www.aleph1.co.uk/lurker/message/20120614.203459.f1b2edbf.en.ht
>>>>>>>>
>>>>>>>> ml ), am
>>>>>>>> I correct to assume that this is under construction??
>>>>>>>>
>>>>>>>> I suppose I have two levels of non-standard complexity in my
>>>>>>>> attempt
>>>>>>>> to do this...
>>>>>>>> First, I wanna build yaffs direct to run os-less.
>>>>>>>> Second I'd like to be able to build on Cygwin.
>>>>>>>>
>>>>>>>> I didn't find much text on this, so before I start building my own
>>>>>>>> makefile
>>>>>>>> I figured I'd ask if there is a documented procedure for doing
>>>>>>>> this.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ed
>>>>>>> Following up on my own question...
>>>>>>> Does anyone have any experience with building yaffs-direct
>>>>>>> recently?
>>>>> I build it pretty much every day using Linux. I have built it in
>>>>> the past
>>>>> using cygwin, but not recently.
>>>>>
>>>>> I'll set up a Windows PC with Cygwin and give it a go today.
>>>>>
>>>> I just set up a new Win7 PC with Cygwin and built yaffs direct with
>>>> a few
>>>> minor issues.
>>>>
>>>> Here is what I did
>>>>
>>>> 1) Fetched the setup.exe from http://www.cygwin.com/.
>>>> 2) I first just ran it using defaults.
>>>> 3) I then added the gcc and gcc core packages by running setup.exe
>>>> and typing
>>>> gcc in the search box, then selecting those packages.
>>>> 4) Then ran setup.exe again to install make.
>>>> 5) Went to http://yaffs.net/download-yaffs-using-git and fetched a
>>>> tarball.
>>>> 6) Opened up a cygwin terminal and
>>>> 6a) untarred the tarball with
>>>> $ tar xvfz /cygdrive/c/User/charles/Downloads/yaffs....tar.gz\
>>>> 6b) cd to yaffs../direct
>>>> 6c) Ran the script there to copy through the yaffs core files
>>>> $ ./handle_common.sh copy
>>>> 6d) cd to basic-test
>>>> 6e) make
>>>>
>>>> At this point the make failed because the cygwin gcc I had
>>>> installed did not
>>>> like many of the -W options. I edited the Makefile to comment these
>>>> out.
>>>>
>>>> make then ran fine and I got a program called directtest2k.exe
>>>> which ran fine.
>>>>
>>>> NB The step at 6b. In the Old Days this was not required since the
>>>> same
>>>> sources were linked in. These days the core sources are run through
>>>> a simple
>>>> sed filter to modify a few names.
>>>>
>>>>
>>>> I hope that helps.
>>>>
>>>> -- Charles
>>> Hmmm...
>>>
>>> Ok, I wasn't aware of the need to run that script (is that
>>> documented anywhere?); so
>>> my first step was to just run 'make' under direct/basic-test. It
>>> tried to set up a bunch of
>>> links, but that failed because the path of the source file in the ln
>>> line was off by one directory
>>> level. That obviously raised a warning flag in my head, but I
>>> worked around it,
>>> and managed to get the basic-test directory built. But I had to fix
>>> compile time errors to do that...
>>>
>>> Taking a step back and following your instructions (but now I'm on a
>>> linux box just to eliminate
>>> one level of complexity), I ran the "./handle_common.sh copy"
>>> script, then cd'd to basic-test
>>> and run make and still get the same errors...
>>>
>>> 1. yaffs_fileem2k.c:426:12: warning: `nread' may be used
>>> uninitialized in this function
>>> 2. yaffsfs.c:1610:5: error: "CONFIG_YAFFS_WINCE" is not defined
>>> Also, note that those link attempts in the makefile are still off by
>>> one directory level.
>>>
>>> These are all easily fixed problems, but I wasn't thinking I would
>>> run into these kinds
>>> of issues so quickly. Is there more than one tarball? I'm using
>>> yaffs2-HEAD-34292b4.tar,
>>> which is what I got from
>>> http://aleph1.co.uk/gitweb?p=yaffs2.git;a=snapshot;h=HEAD;
>>>
>>> Ed
>>>
>>>
>>> _______________________________________________
>>> yaffs mailing list
>>> yaffs@lists.aleph1.co.uk
>>> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>> Continuing down the path of "I don't think I have the right tarball",
>> I managed to get
>> the yaffs environment built to run on my embedded system. To start
>> simple, I figured I'd
>> just test using RAM, so I changed main() (in dtest.c) to do
>> yy_test("/ram1") instead of
>> yy_test("/yaffs2").
>> This failed with the following trace:
>>
>> yaffs: yaffs: yaffs_guts_initialise()
>> yaffs: device function(s) missing or wrong
>> opendir failed
>>
>> Free space in /ram1 is -1
>>
>> It fails with the exact same error when I run directtest2k on linux.
>> After further investigation it appears that the ramdisk device (as it is
>> initialized in yaffs_start_up()) doesn't pass any of the tests in
>> yaffs_check_dev_fns(). Is something incorrect with the ramdisk
>> initialization
>> code in yaffs_start_up()?
>>
>> Ed
>>
>> PS..(still hoping there's a tarball mixup that will resolve all this)
>>
>>
>>
>> _______________________________________________
>> yaffs mailing list
>> yaffs@lists.aleph1.co.uk
>> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
> Replying to myself again...
> Are the errors/warnings I'm seeing being seen by anyone else?
> I put a printf in the code that generates the warning:
> yaffs_fileem2k.c:426:12: warning: `nread' may be used uninitialized
> in this function
> So that seems to be ok to ignore.
> I've got this built and somewhat running in a os-less environment.
> Seems like I'm pretty close, but sure could use some help with these
> issues.
> Not being very experienced with YAFFS internals, I tried to stub myself
> around the "yaffs: device function(s) missing or wrong" problem, but
> things
> just seem to get worse (see trace below); so I'd like to know how others
> are doing this.
> Thanks
> Ed
>
> uMON>yaffs_app
> yaffs: yaffs: yaffs_guts_initialise()
> yaffs: yaffs1_scan starts intstartblk 1 intendblk 128...
> yaffs: block 1 is bad
> yaffs: block 2 is bad
> ...
> yaffs: block 127 is bad
> yaffs: block 128 is bad
> yaffs: yaffs1_scan ends
> yaffs: Block summary
> yaffs: 0 blocks have illegal states
> yaffs: Unknown 0 blocks
> yaffs: Needs scan 0 blocks
> yaffs: Scanning 0 blocks
> yaffs: Empty 0 blocks
> yaffs: Allocating 0 blocks
> yaffs: Full 0 blocks
> yaffs: Dirty 0 blocks
> yaffs: Checkpoint 0 blocks
> yaffs: Collecting 0 blocks
> yaffs: Dead 128 blocks
> yaffs: yaffs: yaffs_guts_initialise() done.
> /ram1/lost+found inode 2 obj c1eef0 length 72249939853824 mode 0
> directory
>
> Free space in /ram1 is 0
>
> Application Exit Status: 0 (0x0)
> uMON>
>
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
I punted on /ram1, and moved to NOR.
I now have a Blackfin based target that has a ST-M29W320EB NOR flash device
running micromonitor with both TFS and YAFFS sharing the single device.
Not at all tested beyond creating a few files and listing them, but so far
so good.
(text/plain)