On Wednesday 26 September 2012 09:21:05 Ed Sutter wrote: > 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.e > >>>>>>>>n.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. Hello Ed I am sorry to not have helped out a bit better here. I have been out of office for a few days. It looks like you have figured yourself out of the hole. If you build yaffs direct tests you are building yaffs direct + a test harness which works in Linux or similar user space. The ram example code is not well integrated into the test harness and might be problematic at present. I will have a look at that. When you integrate into a real embedded system you obviously do not use the whole Linux user space code. What you need is the yaffs direct code (as generated by the handle_common.sh script), flash drivers, configuration and any "OS glue code". Regards Charles