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.