From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Mon, 3 Oct 2011 20:40:10 -0400 Subject: [U-Boot] [PATCH v3 11/21] sandbox: Disable standalone/API support In-Reply-To: References: <1317082255-24247-1-git-send-email-sjg@chromium.org> <201110031537.39511.vapier@gentoo.org> Message-ID: <201110032040.11983.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Monday, October 03, 2011 20:13:03 Simon Glass wrote: > On Mon, Oct 3, 2011 at 12:37 PM, Mike Frysinger wrote: > > On Monday, September 26, 2011 20:10:45 Simon Glass wrote: > >> This is not useful on the sandbox architecture since we can simply link > >> all our code with U-Boot. Also, loading native code doesn't make a lot > >> of sense. > > > > the standalone code would be useful tests i think ... after all, you're > > given an exported API from u-boot which are high level functions like > > I/O. > > > > but getting them to work in the sandbox environment probably will be > > tricky to say the least ... perhaps add a note in the README.sandbox ? > > Yes I will add a note. But it's hard to see why it wouldn't be better > just to link against U-Boot. Or are you thinking of lashing a file > system stress tester to U-Boot somehow? i would like to see automatic testing of the exported API in the same way that standalone applications work. so u-boot runs, loads an arbitrary blob into its external memory, and then jumps into it. if we have tun/tap networking, this should be easy to get arbitrary files into its memory space ... after that, it's a "simple" matter of jumping into the middle of its code :). -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20111003/8c467161/attachment.pgp