> > Really? I've had very little problem with modifying U-Boot - the code base
> > is fairly common for most Linux-like projects. The code was consistent, and
> > well documented. As far as setting up the hardware, it's certainly
> > interesting, but of small utility in the grand scheme of things.
> Really? I've had very little problem with modifying U-Boot - the code base
> is fairly common for most Linux-like projects. The code was consistent, and
> well documented. As far as setting up the hardware, it's certainly
> interesting, but of small utility in the grand scheme of things.
perhaps
On Mon, Jun 3, 2013 at 11:43 AM, erik quanstrom wrote:
> > It's more than that. Many board vendors will use a secured stage 1
> > bootloader that assumes U-Boot. It's probably possible to shove in a
>
> good point. what are the secure loaders assuming?
>
I have no idea - those I've dealt with we
> It's more than that. Many board vendors will use a secured stage 1
> bootloader that assumes U-Boot. It's probably possible to shove in a
good point. what are the secure loaders assuming?
> Every SoC is going to have a different process - in the end, you'll have
> something that will probably
> Strange... I will take a look at the code. Which uboot are you using?
> Though we don't have to use the latest uboot.
I grabbed the uboot binary from a freebsd distribution dated 20130201.
Earlier versions won't work with a 512MB pi model B.
On Jun 3, 2013, at 11:21 AM, Richard Miller wrote:
>> The screen size detection code uses rpi's msgbox interface so should work
>> even with uboot.
>
> It should but it doesn't. I notice uboot is now echoing its console output to
> hdmi as well as the serial port, which earlier versions didn't
> The screen size detection code uses rpi's msgbox interface so should work
> even with uboot.
It should but it doesn't. I notice uboot is now echoing its console output to
hdmi as well as the serial port, which earlier versions didn't do. Maybe this
is messing up the screen size.
On Mon, Jun 3, 2013 at 6:19 AM, erik quanstrom wrote:
> unfortunately, as far as i know plan 9 can't be used as a primary
> loader most of the environments where uboot is used because
> we haven't written the (usually small) memory initialization code, etc.
>
It's more than that. Many board vendo
On Jun 3, 2013, at 3:35 AM, Richard Miller <9f...@hamnavoe.com> wrote:
> I just tried this to check it still works, and found that you
> need a vgasize= definition in the /cfg/pxe/NN file if you're
> booting with uboot and want an HDMI screen. I'm not sure that
> was documented anywhere. If yo
On Mon Jun 3 06:42:31 EDT 2013, 9f...@hamnavoe.com wrote:
> > there's something just a little annoying about having a boot
> > loader that is much larger than the kernel than you're loading.
>
> Thanks to /dev/reboot you can alternatively use plan 9 itself
> as a loader, thus guaranteeing the loa
yes, sorry; i was going from memory -- which isn't as reliable as it once
was.
On Mon, Jun 3, 2013 at 3:35 AM, Richard Miller <9f...@hamnavoe.com> wrote:
> > you'll need the uboot sd image that Richard put together
> > (/n/sources/contrib/miller/uboot.img)
>
> No, that file is just an executable
> there's something just a little annoying about having a boot
> loader that is much larger than the kernel than you're loading.
Thanks to /dev/reboot you can alternatively use plan 9 itself
as a loader, thus guaranteeing the loader is no bigger than
the kernel. I've found this useful when loadin
> you'll need the uboot sd image that Richard put together
> (/n/sources/contrib/miller/uboot.img)
No, that file is just an executable binary of uboot. An SD image
for pxe-type loading is /n/sources/extra/pi.uboot.sd.img.gz as
mentioned in booting(8).
I just tried this to check it still works,
On Sun, Jun 2, 2013 at 6:09 AM, erik quanstrom wrote:
> also note, that the kw kernel is bootable without uimage
> support.
>
Sure, though supporting uImage means you get a few things for free, not to
mention it isn't ELF. This deserves a proper write up - I'll probably do
something for IWP9 if I
you'll need the uboot sd image that Richard put together
(/n/sources/contrib/miller/uboot.img)
that's what i use to boot the 9Pi cluster from the file server.
On Sun, Jun 2, 2013 at 8:53 PM, erik quanstrom wrote:
> > > also note, that the kw kernel is bootable without uimage
> > > support.
> >
> > also note, that the kw kernel is bootable without uimage
> > support.
>
> ... and so is any other Plan 9 arm kernel, as long as you
> have access to u-boot's console or config variables.
> See booting(8).
the rpi doesn't use u-boot by default, though, does it?
i certainly don't see any indica
> also note, that the kw kernel is bootable without uimage
> support.
... and so is any other Plan 9 arm kernel, as long as you
have access to u-boot's console or config variables.
See booting(8).
> uImage support to 5l (patch/arm-uboot) - a requirement to exist nicely with
> the loader. The exynos5 port that I am working on (Arndale Board, Samsung
> Chromebook) relies on this exclusively.
this is in 9atom. also note, that the kw kernel is bootable without uimage
support.
- erik
On Sat, Jun 01, 2013 at 06:10:51PM -0400, erik quanstrom wrote:
> > Marvell Development Board (LSP Version KW_LSP_5.1.3_patch18)--
> > RD-88F6281A Soc: 88F6281 A0 LE
> >
> > That is openRD (Marvell 88F6281), it is a starting point for playing
> > with it...
>
> well, good luck. there's a sata d
On Sat, Jun 01, 2013 at 09:06:55PM -0700, Steven Stallion wrote:
>
> It's quite possible. I even have it working. :-)
>
> A couple of months ago I submitted a patch to the U-Boot mainline to add
> formal support for Plan 9 kernels. It has since been accepted. At the same
> time I also submitted a
On Sat, Jun 1, 2013 at 12:19 AM, wrote:
> Since it has u-boot installed and that the mapping of the flash is given
> does one know if one could build a Plan9 kernel, write it (via
> u-boot) to the flash and be able to boot?
>
It's quite possible. I even have it working. :-)
A couple of months a
> Marvell Development Board (LSP Version KW_LSP_5.1.3_patch18)--
> RD-88F6281A Soc: 88F6281 A0 LE
>
> That is openRD (Marvell 88F6281), it is a starting point for playing
> with it...
well, good luck. there's a sata driver in 9atom.
- erik
On Sat, Jun 01, 2013 at 09:31:29AM -0400, erik quanstrom wrote:
> > I have read on the wiki that there is a 5c, for ARM 32bits
> > little-endian, but that there is no flash memory support.
>
> i boot my openrd from flash.
>
So since it is:
Marvell Development Board (LSP Version KW_LSP_5.1.3_pat
On Sat, Jun 01, 2013 at 09:31:29AM -0400, erik quanstrom wrote:
>
> i have some experience with the marvell ferceron, and they are similar to
> the plug computers/open rd, but most of the memory mapping will be
> different.
>
> if your want your focus to be on the file server, and not porting to
> I have read on the wiki that there is a 5c, for ARM 32bits
> little-endian, but that there is no flash memory support.
i boot my openrd from flash.
> Unfortunately, it happens that in France, for small enterprises (not to
> say independant worker like me), we are not a worthy target. And the
>
On Sat, Jun 01, 2013 at 10:04:23AM +0200, lu...@proxima.alt.za wrote:
>
> The ARM world is considerably more complicated, what with dozens of
> subspecies in existence and 600-page manuals to describe how they
> work. Personally, I'd be very interested in setting up a Plan 9/ARM
> Google group in
> Since it has u-boot installed and that the mapping of the flash is given
> does one know if one could build a Plan9 kernel, write it (via
> u-boot) to the flash and be able to boot?
I'm looking for the answer to this question too. Besides the
Sheevaplug, I have a similar ARM gadget that I was p
27 matches
Mail list logo
