amusement value:
How long was the minimum time to cross USA from East Coast (NYC) to West
Coast (SF) back then in 1880s (Vayat Erp and Dock Holiday time: by horse or
carriage)?
And how long for the same distance Today/Present time (by plane or shuttle)?
Ron, technology advances... Doesn't it???
OK, then someone just asked me: how long does it take to rewrite that 128
MiB vs. the 512 byte sector on the floppy. :-)
On Wed, Nov 30, 2016 at 1:18 PM ron minnich wrote:
> amusement value:
>
> The 512 bytes used for MBR is about .04% of the 8" floppy disk that
> shipped with the original IBM P
amusement value:
The 512 bytes used for MBR is about .04% of the 8" floppy disk that shipped
with the original IBM PC. For 128 MB to be that fraction of a new disk, the
disk would have to be 256 GiB. That's about $40 worth of disk.
Geez.
On Wed, Nov 30, 2016 at 11:00 AM Zoran Stojsavljevic <
zo
> Or do you want to do the full EFI "let's waste 128MB of *every** disk* on
> a special FAT32 partition" madness (which still requires bootloaders to
> include one specific FS driver they might otherwise not want)?
YES, you do. Accent on: "every disk" .
Zoran
On Tue, Nov 29, 2016 at 10:53 PM, Ju
hey, peter, code wins :-) go for it
On Wed, Nov 30, 2016 at 10:08 AM Peter Stuge wrote:
> Julius Werner wrote:
> > If you really can't stand the idea of BIOS interrupts and real mode,
>
> I for one can't.
>
>
> > I think your next best option would be to try to cram an
> > as-small-as-possible b
Julius Werner wrote:
> If you really can't stand the idea of BIOS interrupts and real mode,
I for one can't.
> I think your next best option would be to try to cram an
> as-small-as-possible binary recovery descriptor and the real mode
> code to parse/load/execute it together into the 446 bytes
> To sum it up, I want something that is lean and clean enough so it could
be added to any bootloader. Even if that boot loader is not of the
let's build a tiny OS type.
I don't really see how you could reach this goal with anything that
requires reading a file from the boot media? There are billi
On 28.11.2016 20:26, David Hendricks via coreboot wrote:
> On Sun, Nov 27, 2016 at 8:28 PM, ron minnich wrote:
>
>> yeah, david and nico both make very good points. I like the idea of JSON
>> file, and further we're working on a Go program
>> on the u-root project that would parse said file (tri
On 28.11.2016 22:38, ron minnich wrote:
> I'm also ok with text protobufs. My only request is that we do not use
> binary blobs or XML.
Interesting, I think almost everyone would agree to never use XML for
anything ;)
I've been looking at protobufs, the text-representation looks nice. I
like it m
I'm also ok with text protobufs. My only request is that we do not use
binary blobs or XML.
Here's one .json from Harvey, defining rules for libraries. It has some
arrays, and shows the use of structure. Seems simple enough to me.
My assumption is that this would be parsed by a user level program
On Mon, Nov 28, 2016 at 12:40 PM, Peter Stuge wrote:
> David Hendricks via coreboot wrote:
> > On Sun, Nov 27, 2016 at 8:28 PM, ron minnich wrote:
> > > I like the idea of JSON file
> >
> > Now we're talkin' - A standardized data format that is human
> > readable/writeable that can be easily par
David Hendricks via coreboot wrote:
> On Sun, Nov 27, 2016 at 8:28 PM, ron minnich wrote:
> > I like the idea of JSON file
>
> Now we're talkin' - A standardized data format that is human
> readable/writeable that can be easily parsed and generated using
> small libraries.
I agree with the conce
On Sun, Nov 27, 2016 at 8:28 PM, ron minnich wrote:
> yeah, david and nico both make very good points. I like the idea of JSON
> file, and further we're working on a Go program
> on the u-root project that would parse said file (trivial in Go to parse
> JSON, it's one statement and blam! your Go
> The measurements are with me. Linux, properly configured, is a very fast
bootloader. UEFI has always been nothing but slow. And
> that's still true; I've seen recent systems with "stripped down" UEFI and
they are still appallingly slow, slower than linuxbios was in
> 2000 on slow CPUs. I still ca
On Sun, Nov 27, 2016 at 5:58 PM Charlotte Plusplus <
pluspluscharlo...@gmail.com> wrote:
> I don't know about you, but once I have a minimal working kernel or a
> coreboot fallback, I never really update them. So having no way to recover
> them without hardware intervention is fine. The kernel I m
yeah, david and nico both make very good points. I like the idea of JSON
file, and further we're working on a Go program
on the u-root project that would parse said file (trivial in Go to parse
JSON, it's one statement and blam! your Go struct is all
filled in) and then decide what to configure/wh
On Sat, Nov 26, 2016 at 2:46 PM, ron minnich wrote:
> coreboot today is linuxbios minus the linux. The original intent was
> always that linux be our lifeboat. The current set of (as you point out)
> not terrific options is a result of linux growing too big for flash, and
> flash growing too big
I don't know about you, but once I have a minimal working kernel or a
coreboot fallback, I never really update them. So having no way to recover
them without hardware intervention is fine. The kernel I may recompile,
patch, etc would be somewhere else.
The job of this minimal kernel and initrd wou
On Sun, Nov 27, 2016 at 07:30:07PM -0500, Charlotte Plusplus wrote:
> [...]
> With the amount of flash we have, sharing the kernel and initrd doesn't
> seem like a bad idea.
The problem is if a bad kernel or initrd is flashed then there is no
way to recover without hardware intervention. Having a
If I had more flash, I would like that too, just for kicks.
With the amount of flash we have, sharing the kernel and initrd doesn't
seem like a bad idea.
If the cmdline for the normal mode can be modified easily by updating the
cbfs with flashrom, I don't see any drawback to using kexec from the
On Sun, Nov 27, 2016 at 4:22 PM Charlotte Plusplus <
pluspluscharlo...@gmail.com> wrote:
>
>
> In my ideal scenario, coreboot would have the 2 images (normal, fallback)
> both starting the same payload (a minimal linux kernel) to save space.
>
at Los Alamos we found we wanted a fallback kernel an
Hello
On Sat, Nov 26, 2016 at 6:19 PM, Trammell Hudson wrote:
> The 4MB flash in the older thinkpads is a little tight, but still
> sufficient for a text-based modern Linux kernel -- the biggest issue is
> the cryptsetup tool brings in quite a few dependencies right now,
> which complicates usin
On Sun, Nov 27, 2016 at 1:03 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:
>
> I'll again repeat what I always believe in, and always advertise(d) here,
> and anywhere else: Coreboot is one excellent absolute minimum required for
> booting HW platform to the next step: OS boot loa
Rettungs (German) - Ubersetzung/translate ist/is rescue. As much as I
know... Desperately trying to learn more Deutsche Sprache these days
(bloody tough - too old for it).
I'll again repeat what I always believe in, and always advertise(d) here,
and anywhere else: Coreboot is one excellent absolut
And let's not forget John Lewis' excellent work on JELTKA for chromebooks,
which is also Linux and kexec. I've used it and it's great.
I have a replacement for petitboot which is an all-Go userland: u-root.
Programs in the root file system are Go source and are compiled on first
use -- there's a
In my opinion there are currently two payloads which are really
interesting and promising for end users:
* HEADS - https://github.com/osresearch/heads
* Petitboot - https://secure.raptorengineering.com/content/kb/1.html
I am currently working on the UI of Heads. So feel free to contribute ;)
B
On Sat, Nov 26, 2016 at 10:46:33PM +, ron minnich wrote:
> [...]
> Every bootloader starts simple, and becomes an OS. Every single one starts
> with the intent of being small and compact and only supporting some needed
> subset of file systems/devices/protocols and ends up implementing
> everyt
coreboot today is linuxbios minus the linux. The original intent was always
that linux be our lifeboat. The current set of (as you point out) not
terrific options is a result of linux growing too big for flash, and flash
growing too big for linux, ca. 2002, when we adopted the payload model. The
or
Oh, my fingers type too much for me now.
The current set of (as you point out) not terrific options is a result of
linux growing too big for flash, and flash growing too SMALL for linux, ca.
2002, when we adopted the payload model.
On Sat, Nov 26, 2016 at 3:46 PM ron minnich wrote:
> coreboot t
On 26.11.2016 19:18, Igor Skochinsky wrote:
> Hello Nico,
>
> Saturday, November 26, 2016, 6:42:40 PM, you wrote:
>
> NH> Hey coreboot folks,
> NH> here's something that's bugging me for a long time: Our lack of an out-
> NH> of-the-box booting experience.
>
> NH> All our payloads that don't imp
Hello Nico,
Saturday, November 26, 2016, 6:42:40 PM, you wrote:
NH> Hey coreboot folks,
NH> here's something that's bugging me for a long time: Our lack of an out-
NH> of-the-box booting experience.
NH> All our payloads that don't implement legacy boot facilities (i.e. BIOS,
NH> UEFI), only work
Hey coreboot folks,
here's something that's bugging me for a long time: Our lack of an out-
of-the-box booting experience.
All our payloads that don't implement legacy boot facilities (i.e. BIOS,
UEFI), only work in the usual case, to boot an installed OS that's con-
figured to work with that pay
32 matches
Mail list logo
