I think one of the reason 9load is quite complicated is because
they wanted to boot a kernel from the network, so you need a network stack and
the drivers for the ethernet card, so you really need lots of OS code in the
end.
On Dec 2, 2014, at 2:28 PM, Enrico Weigelt, metux IT consult
wrote:
as far as I can remember, Plan 9 (Bell Labs) as 9load expect each other.
9front, on the other hand, got rid of 9load for its own good.
On Tue, Dec 2, 2014 at 8:28 PM, Enrico Weigelt, metux IT consult
wrote:
> On 02.12.2014 23:02, Iruatã Souza wrote:
>
>>> apropos kernel/bootloader: I just recentl
On 02.12.2014 23:02, Iruatã Souza wrote:
>> apropos kernel/bootloader: I just recently had a look at the code
>> and somewhat got the impression that 9load seems to be a specially
>> tailored plan9 kernel, which then loads the real kernel.
>>
>> is that correct or am I mistaken here ?
>
> Correct
Em 02/12/2014 19:59, "Enrico Weigelt, metux IT consult" <
enrico.weig...@gr13.net> escreveu:
>
> On 02.12.2014 16:21, Steven Stallion wrote:
>
>
>
> apropos kernel/bootloader: I just recently had a look at the code
> and somewhat got the impression that 9load seems to be a specially
> tailored pla
On 02.12.2014 16:21, Steven Stallion wrote:
apropos kernel/bootloader: I just recently had a look at the code
and somewhat got the impression that 9load seems to be a specially
tailored plan9 kernel, which then loads the real kernel.
is that correct or am I mistaken here ?
cu
--
Enrico Weigel
On Tue, Dec 2, 2014 at 8:10 AM, erik quanstrom wrote:
>> One of the functions u-boot performs is configuring the various subsystems
>> in the SoC (individual clocks and power settings for subcomponents, gpio
>> pin functions, ...) -- things a BIOS would do in a more old-timey computer.
>> In my ex
> One of the functions u-boot performs is configuring the various subsystems
> in the SoC (individual clocks and power settings for subcomponents, gpio
> pin functions, ...) -- things a BIOS would do in a more old-timey computer.
> In my experience these are typically undocumented (or worse, incorr
by 'ci ap' i meant cinap_lenrek.
UEFI support was written for 9front by ci ap. It has been tested on the x230
and in OVMF. I have an working gpt editor but it needs cleanup.
On Tuesday 02 December 2014 09:32:22 Richard Miller wrote:
> It's easier just to be
> lazy and let u-boot do it.
Sorry for hijacking a bit. There was a mention on this list a couple of months
ago about work on getting Plan9 working on UEFI/GPT machines...
whoever that was - any progress?
quans...@quanstro.net:
> u-boot has several drawbacks that have hindered my development
> ...
> i worked on an embedded pcie endpoint, and all these factors cost
> me 4-5 weeks of dev time, time enough that i could have brought the
> board up myself directly with plan 9 as a bootloader in tht amoun
> I took Steve's point to be that I don't get to have an opinion
> because he's never seen me in his playground before, but I figured
> it would be more productive to focus on the fact that uboot sucks
> rather than an exercise in disregarding personal experience because
> Steve told me to.
i didn
Quoting erik quanstrom :
while i don't agree that u-boot is nice, i do agree with steve's point,
which i understood to be that hardware is messy, and it's hard to write
software that isn't a tad messy to deal with this. steve has a lot
of experience
with hardware, and knows what he's talkin
On Mon Dec 1 20:00:59 PST 2014, k...@sciops.net wrote:
> Quoting Steven Stallion :
>
> > Clearly you've never worked on hardware.
>
> No, thank Christ, my conscience is clean. Instead I work on
> software, and uboot is a fine example of "well it builds on my
> laptop" development paradigms. Pl
Quoting Steven Stallion :
Clearly you've never worked on hardware.
No, thank Christ, my conscience is clean. Instead I work on
software, and uboot is a fine example of "well it builds on my
laptop" development paradigms. Plenty glad I don't have to
screw with such nonsense any more, and even
On Mon, Dec 1, 2014 at 8:42 PM, Bakul Shah wrote:
> On Mon, 01 Dec 2014 15:54:36 CST Steven Stallion wrote:
>>
>> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
>> boot significantly - there is zero reason to eschew the functionality
>> it brings.
>
> Do you think it is worth
> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
> boot significantly - there is zero reason to eschew the functionality
> it brings.
i don't think this is a full accounting of the situation.
u-boot has several drawbacks that have hindered my development
(a) there are many of
On Mon, 01 Dec 2014 15:54:36 CST Steven Stallion wrote:
>
> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
> boot significantly - there is zero reason to eschew the functionality
> it brings.
Do you think it is worth adding support for "flattened device
tree" (a data structur
Where is the +1 on this whatchamajig?
Sent from my iPhone
> On Dec 1, 2014, at 6:16 PM, Steven Stallion wrote:
>
>> On Mon, Dec 1, 2014 at 6:56 PM, Kurt H Maier wrote:
>> Quoting Steven Stallion :
>>
>>> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
>>> boot significantly
On Mon, Dec 1, 2014 at 6:56 PM, Kurt H Maier wrote:
> Quoting Steven Stallion :
>
>> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
>> boot significantly - there is zero reason to eschew the functionality
>> it brings.
>
> Instead, I'll recommend eschewing hardware that require
Quoting Steven Stallion :
FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
boot significantly - there is zero reason to eschew the functionality
it brings.
Instead, I'll recommend eschewing hardware that requires circus tricks to
load a kernel.
khm
On Tue, Dec 2, 2014, at 03:24 AM, Steven Stallion wrote:
> They do. In fact, I contributed a patch a while back to add u-boot
> image support to 5l a while back. U-boot has also been patched to
> expect these binaries. You can take a look at what has been done in
> the Chromebook port (http://code.
They do. In fact, I contributed a patch a while back to add u-boot
image support to 5l a while back. U-boot has also been patched to
expect these binaries. You can take a look at what has been done in
the Chromebook port (http://code.google.com/p/9chrome), but I've been
stalled due to demands at th
> Thanks. IMX6 documentation is freely available. There is a version of
> u-boot. The manufacturer (Solid Run) also has made the board schematics
> etc available.
>
> From the reading of booting(8), I am assuming that the ARM devices in
> plan9 use the u-boot for booting the kernel up?
some do.
On Mon, Dec 1, 2014, at 11:14 AM, erik quanstrom wrote:
> > Surprisingly I didn't see a paper on porting Plan9 to new architectures
> > in the plan9 paper collection. Any help and pointers on how to get
> > started with the porting effort will be highly appreciated.
>
> it's all about the documen
> Surprisingly I didn't see a paper on porting Plan9 to new architectures
> in the plan9 paper collection. Any help and pointers on how to get
> started with the porting effort will be highly appreciated.
it's all about the documentation. if you can get it, boringing up a new
kernel for a new ar
Hi,
I have a hummingboard i1 board [1] which I would like to use as a Plan9
terminal. I also want to use the opportunity to learn about the plan9
kernel and read the code. The board has a FreeScale iMX6 Solo SoC which
is based on ARM-Cortex A9 core. I am hoping to reuse parts of the OMAP3
port (th
On Mon, Jun 16, 2008 at 4:45 PM, <[EMAIL PROTECTED]> wrote:
> Hi,
> I am plan 9 fan, this is my first post with this google account. :)
> Like the title says, where should i look into first?
There was some work done on that for the gsoc last year. See
http://gsoc.cat-v.org/projects/kencc/ and
ht
Hi,
I am plan 9 fan, this is my first post with this google account. :)
Like the title says, where should i look into first?
I am already compiled plan9port on fedora 9 and using it's acme on
gnome environment.
TIA
29 matches
Mail list logo
