On Thu, Sep 7, 2017 at 1:43 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:
>
> Please, could you try to do this with INTEL ATOM or CORE in this time for
> this price? ;-)
>
>
>
This is a very interesting point about time to market, which is everything
nowadays. I regret that ARM de
Julius Werner wrote:
> while the program was running it mostly interacted with the BIOS directly.
Not in general - that is/was highly dependent on the program.
BIOS interrupt services offer a hardware abstraction, but they come
at a (high! interrupts are very expensive!) cost.
For anything perfo
> Linux, for a long time, did not need no steenkin' BIOS (you can find that
quote if you look back far enough).
*But those days are gone.*
This is the reason why INTEL has no chance to win IoT race with ARM (just
in few special use cases). With all these compatibilities, and test modes,
INTEL is f
The original statement about BIOS -- that it was a second OS from the first
day on -- is not correct.
I am pretty sure the term BIOS (Basic Input Output Subsystem) comes from
the early days, from CP/M. That's when I started hearing it anyway.
The BIOS was the bottom half of CP/M. It provided an a
> The awkward thing about BIOS is that it was a second OS from the first
> day on – while the reasonable philosophy behind firmware should be:
> Start the board, load the OS and go back into your flash until reboot.
My history lessons may be failing me here, but IIRC the main reason
for that was m
> Hint: on x86 it's essentially one billion instructions before you can
even think about using RAM, much less loading the payload.
This is why everybody using INTEL silicon do have FSP as A MUST (instead
SEC+PEI). And this is why CORE CPU creations (2C+) have > 500 million gates
per silicon. There
On Mon, Sep 4, 2017 at 3:41 PM Philipp Stanner wrote:
>
> Start the board, load the OS and go back into your flash until reboot.
>
Just checking, but have you looked at the code to see what "start the
board" really means? Hint: on x86 it's essentially one billion instructions
before you can even
Am Montag, den 04.09.2017, 20:15 + schrieb Peter Stuge:
> legacy
> tables such as ACPI
ACPI is a open standard, isn't it?
>
> The payload directly reads the filesystem from disk, no boot sector
> is used.
Indeed. So a payload built for cb won't try to call BIOS. And if
something after it t
Peter Stuge wrote:
> The MBR is irrelevant in the above scenario, it is never read.
..
> The payload directly reads the filesystem from disk, no boot sector is used.
To clarify, I mean code here. No code is read/loaded/used from MBR.
The partition table is read, but I expect that GRUB2 supports b
Zoran Stojsavljevic wrote:
> > But a bootloader built as a payload could also be built to use BIOS
> > interfaces. GRUB is one example of this.
>
> Let us assume the following configuration:
> FSP -> Coreboot -> Payload: GRUB2 -> Linux
>
> No legacy interrupts, correct?
Correct.
> So, what is t
> But a bootloader built as a payload could also be built to use BIOS
> interfaces. GRUB is one example of this.
Let us assume the following configuration:
FSP -> Coreboot -> Payload: GRUB2 -> Linux
No legacy interrupts, correct? So, what is this for the architecture? CSM?
UEFI look alike?
I ass
Thanks so far. Very interesting.
Am Montag, den 04.09.2017, 07:28 + schrieb Peter Stuge:
>
> coreboot itself can only start one payload, but SeaBIOS allows the
> user to choose which of those payloads to start, in which case a
> payload *does* have interrupt services available.
>
> Just to l
Philipp Stanner wrote:
> Once coreboot jumped into SeaBIOS-code the latter is responsible for
> providing the right interface for interrupt services.
Sure, coreboot does not provide interrupt services. I did not mean to
claim that it does. Sorry if there was confusion.
> I guess it doesn't matte
Am Samstag, den 02.09.2017, 12:36 + schrieb Peter Stuge:
>
> Sure, but a payload can. SeaBIOS aims to provide a complete BIOS with
> all neccessary interrupt services for legacy compatibility.
Once coreboot jumped into SeaBIOS-code the latter is responsible for
providing the right interface f
Philipp Stanner wrote:
> > > Why would I want to address memory in RM with 32 Bits? I don't see
> > > any difference to using PM without Paging enabled.
> >
> > In a bootloader (after coreboot) you often want to call BIOS
> > interrupt services which assume real mode, because that was the
> > only
Am Donnerstag, den 03.08.2017, 12:48 + schrieb Peter Stuge:
> Philipp Stanner wrote:
> > Why would I want to address memory in RM with 32 Bits? I don't see
> > any difference to using PM without Paging enabled.
>
> In a bootloader (after coreboot) you often want to call BIOS
> interrupt servic
>
> Unfortunately, this picture represents ONLY 32bit transitions, there are
> two more modes for 64 bit, not shown here. If I find the representative,
> I'll post it on the forum (@ list).
>
The box labeled "IA-32e Mode" is 64-bit mode (in their infinite wisdom,
Intel chose a name containing the
in the akaros virtual machine code, we set up a simple 1:1 map and start
linux at the 64-bit entry point, at which point it builds its own page
tables. So entering a payload in long mode is certainly possible and IMHO
ought to be the standard on amd64 -- not that anyone cares what I think
anyway :-
OK Ron,
I needed some time to reconcile my thoughts. So,as Aaron pointed, it is
impossible to do any long mode paging in ROM stage.
And here we come to the Mystery of CB Organism (h... It is very close
to some other term). ;-)
Now, here is how it will play for you and Coreboot, after ROM sta
Philipp Stanner wrote:
> Why would I want to address memory in RM with 32 Bits? I don't see
> any difference to using PM without Paging enabled.
In a bootloader (after coreboot) you often want to call BIOS
interrupt services which assume real mode, because that was the
only mode, when the interrup
On Wed, Aug 2, 2017 at 1:38 PM Philipp Stanner wrote:
> Dear Patrick, dear Zoran & List,
>
> thank you, this was *very* helpful. I had some misunderstandings regarding
> function and features of the CPU-modes.
>
> Let me sum it up again and feel free to correct further mistakes.
>
>- 16-Bit-R
Dear Patrick, dear Zoran & List,
thank you, this was *very* helpful. I had some misunderstandings
regarding function and features of the CPU-modes.
Let me sum it up again and feel free to correct further mistakes.
* 16-Bit-Real Mode: No virtual memory, no segmentation. 2^20 addresses
of me
right, Aaron, you keep reminding me of that and I keep forgetting it :-)
so, ok, ramstage it is for paging. The x86 is so darned annoying. We had
paging in the bootblock for PPC on linuxbios.
On Wed, Aug 2, 2017 at 12:43 PM Aaron Durbin wrote:
> On Wed, Aug 2, 2017 at 1:36 PM, ron minnich wrot
On Wed, Aug 2, 2017 at 1:36 PM, ron minnich wrote:
>
>
> On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic
> wrote:
>>
>>
>>
>> So, turning on the Virtual Mode (paging ON), you'll also imply that
>> Coreboot will initialize and use MMU, don't you?
>
>
> sure.
>
>>
>>
>> Am I correct, or you can
On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:
>
>
> So, turning on the Virtual Mode (paging ON), you'll also imply that
> Coreboot will initialize and use MMU, don't you?
>
sure.
>
> Am I correct, or you can use paging without MMU?!
>
MMU must be o
2017-08-02 21:08 GMT+02:00 Zoran Stojsavljevic :
> And my question is: what for? Or I did not get the idea... Who really needs
> to use paging in boot-loaders? Even INTEL, which (on purpose) makes things
> way over-dimensioned and over-complicated, does NOT use paging in UEFI
> BIOSes, so far???
Th
Hey Ron,
> You can't enter long mode (x86-64) mode without enabling paging. you need
long mode if you need to operate on more than 2^36 bytes
> of memory. That's coming everywhere. Hence,* the future of coreboot is
unambiguously one in which paging is on and at least*
*> in my case** I found it's
I'll try not to mess this explanation up too much, but it's partly from the
docs and partly what we've learned over the years. I am assuming that
you've at least looked at the coreboot boot block and read some of the x86
docs, although from this note and previous notes you have written I'm still
no
Hello Philipp,
There are lot of confusion you have created with your naming convention...
So we need here to "Divide and Concur", since this thread really remains me
of Spaghetti Bologneze.
Here is the partial picture how x86 operates:
[image: Inline image 1]
So you see here three modes, you ar
On 01.08.2017 16:49, Peter Stuge wrote:
Note that PM != paging. Neither coreboot nor proprietary BIOS
products used paging traditionally. Ron pushed for paging, there was
a bit of support. I don't know the current situation though.
Also note that PM != "flat real mode" or "32-bit real mode",
On Tue, Aug 01, 2017 at 02:49:27PM +, Peter Stuge wrote:
> Philipp Stanner wrote:
> [...]
> > * Why does every modern CPU still start in RM?
>
> Many industries run on DOS. Many system developers have created
> in-house BIOS extensions. x86 will never fully lose its 16-bit legacy.
And, just t
Philipp Stanner wrote:
> the more I want to contribute and learn about low-level-code the less I
> understand, it seems.
The x86 is a true rabbit hole. :)
> 2. When CB switches to PM - who generates and administrates the Page
> Tables and where?
Note that PM != paging. Neither coreboot no
2017-07-31 14:46 GMT+02:00 Nico Huber :
> No idea about the kernel's requirements
Windows 7's kernel uses int10 calls for checking out various graphics
properties, even when booting with UEFI (and therefore GOP drivers
better put some int10 handler in the right place if they want to
continue to sup
On 31.07.2017 13:48, Philipp Stanner wrote:
> Well, many thanks.
>
> I didn't expect it to work that way. Would be interesting to know what
> Windows 7 needs BIOS calls for.
It seems to be their policy to have a boot loader (and probably kernel)
that can't work on its own. So Windows (including c
Well, many thanks.
I didn't expect it to work that way. Would be interesting to know what
Windows 7 needs BIOS calls for.
Any idea of traditional IBM-PC-Bios-calls are still available in
UEFI-Firmware?
On 31.07.2017 11:43, Patrick Georgi via coreboot wrote:
2017-07-31 10:52 GMT+02:00 Phil
2017-07-31 10:52 GMT+02:00 Philipp Stanner :
> 1. cb switches the CPU immediately to Protected Mode, yet Payloads like
> seaBIOS work in Real Mode. Does coreboot switch the CPU always back to RM
> before jumping to the payload?
No, payloads are started in pmode.
> 2. When CB switches to PM - who
36 matches
Mail list logo