From: Ira W. Snyder <iws@ovro.caltech.edu>
To: u-boot@lists.denx.de
Subject: [U-Boot] Is there a better way?
Date: Tue, 20 Apr 2010 15:47:54 -0700 [thread overview]
Message-ID: <20100420224754.GO7651@ovro.caltech.edu> (raw)
In-Reply-To: <v2k7753e5291004201503l8c2fa8d9ka32a6fbef76cbaf4@mail.gmail.com>
On Tue, Apr 20, 2010 at 04:03:01PM -0600, Chris Rigg wrote:
> Thanks guys. I'll take a look at this in more depth. It sounds like this
> would be the suggested solution to my problem.
>
> Is there an example somewhere that you could point me towards?
>
As this is a bit off-topic on this list, I'll reply to you with the
patches attached. If anyone else wants the code, please ask me.
Linux is seriously lacking a general purpose solution here. I've made
some attempts at writing one, but haven't had the time to complete them.
I'm happy to test a general solution anyone comes up with. I've been
suggested that virtio would be a good choice here, since they have a
highly optimized network driver.
Ira
> On Tue, Apr 20, 2010 at 3:37 PM, Scott McNutt <smcnutt@psyent.com> wrote:
>
> > Hi Chris,
> >
> > Ira W. Snyder wrote:
> >
> >> My problem:
> >>> If I have an in-memory filesystem on my board (the ramdisk), and I have
> >>> the
> >>> entire 256MB of memory accessible to the host over the PCI bus, you'd
> >>> think
> >>> I could write a tool (or find a tool) that I could point at a block of
> >>> physical memory and have it recognize it as an ext2 filesystem and read
> >>> it
> >>> as such. Unfortunately, there doesn't appear to be a precedent for doing
> >>> this. Is there a better way to accomplish my goal of getting my logs off
> >>> the
> >>> ramdisk on the board from the host?
> >>>
> >>>
> >> I've solved a relatively similar problem here. I have a
> >> mpc8349emds-based board that is a PCI target. I've written a couple of
> >> smallish drivers for U-Boot and Linux that make the board seem like an
> >> ethernet interface.
> >>
> >
> > Ditto. Ira's suggestion is a very elegant and useful technique ... and
> > has been used successfully for many applications.
> >
> >
> > We tftp our kernel and boot our board over NFS using the "ethernet"
> >> interface.
> >>
> >
> > As Ira suggests, once your target appears as an addressable host, the
> > sky's the limit. You can telnet/ssh into your target, run tftpd,
> > run a web server for configuration/status, etc. Cool stuff!
> >
> > Regards,
> > --Scott
> >
> >
next prev parent reply other threads:[~2010-04-20 22:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-20 19:01 [U-Boot] Is there a better way? Chris Rigg
2010-04-20 19:59 ` Ira W. Snyder
2010-04-20 21:37 ` Scott McNutt
2010-04-20 22:03 ` Chris Rigg
2010-04-20 22:47 ` Ira W. Snyder [this message]
2010-04-20 21:50 ` Wolfgang Denk
2010-04-20 22:06 ` Chris Rigg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100420224754.GO7651@ovro.caltech.edu \
--to=iws@ovro.caltech.edu \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox