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
(text/plain)