Author: quozl
Date: Thu Mar 24 22:59:24 2011
New Revision: 2181
URL: http://tracker.coreboot.org/trac/openfirmware/changeset/2181
Log:
OLPC XO-1 - return to using EC version that was used for Q2E45
Modified:
cpu/x86/pc/olpc/versions.fth
Modified: cpu/x86/pc/olpc/versions.fth
==============================================================================
--- cpu/x86/pc/olpc/versions.fth Thu Mar 24 03:52:07 2011 (r2180)
+++ cpu/x86/pc/olpc/versions.fth Thu Mar 24 22:59:24 2011 (r2181)
@@ -2,10 +2,10 @@
\ The overall firmware revision
macro: FW_MAJOR E
-macro: FW_MINOR 45r
+macro: FW_MINOR 45s
\ The EC microcode
-macro: EC_VERSION e34
+macro: EC_VERSION e35
\ Alternate command for getting EC microcode, for testing new versions.
\ Temporarily uncomment the line and modify the path as necessary
Author: quozl
Date: Thu Mar 24 03:52:07 2011
New Revision: 2180
URL: http://tracker.coreboot.org/trac/openfirmware/changeset/2180
Log:
OLPC XO-1 - disable menu dev.laptop.org #10778
Modified:
cpu/x86/pc/olpc/fw.bth
cpu/x86/pc/olpc/versions.fth
Modified: cpu/x86/pc/olpc/fw.bth
==============================================================================
--- cpu/x86/pc/olpc/fw.bth Sat Mar 12 02:04:51 2011 (r2179)
+++ cpu/x86/pc/olpc/fw.bth Thu Mar 24 03:52:07 2011 (r2180)
@@ -665,7 +665,7 @@
unfreeze visible ( no-banner? )
if banner then \ Reissue banner if it was suppressed
- blue-letters ." Type 'help' for more information." black-letters
+ blue-letters ." Type 'help' for more information." black-letters cancel
cr cr
quit
@@ -683,6 +683,11 @@
fload ${BP}/cpu/x86/pc/olpc/diskspeed.fth \ Mass storage speed test
+\ #10778 disable menu
+warning @ warning off
+: menu ;
+warning !
+
\ This helps with TeraTerm, which sends ESC-O as the arrow key prefix
also hidden also keys-forth definitions
warning @ warning off
Modified: cpu/x86/pc/olpc/versions.fth
==============================================================================
--- cpu/x86/pc/olpc/versions.fth Sat Mar 12 02:04:51 2011 (r2179)
+++ cpu/x86/pc/olpc/versions.fth Thu Mar 24 03:52:07 2011 (r2180)
@@ -2,7 +2,7 @@
\ The overall firmware revision
macro: FW_MAJOR E
-macro: FW_MINOR 45q
+macro: FW_MINOR 45r
\ The EC microcode
macro: EC_VERSION e34
Mitch Bradley wrote:
>>> Booting Windows is not supported in the PC demonstration build, but is
>>> possible with a fair amount of effort. It requires ACPI and numerous
>>> other accomodations for Windows' use of conventional BIOS. We support
>>> it on the One Laptop Per Child systems.
>>
>> At present things I'm likely to want to boot are Linux and DOS, although
>> I'm currently trying to evaluate ReactOS and Sanos so I can report back
>> to another group of developers.
>
> DOS and ReactOS are going to have the same problem as Windows, namely
> that they expect to do conventional 16-bit BIOS calls. The OFW demo
> version does not support that.
>
> Are you considering using OFW on both x86 and ARM systems, or is the x86
> work just for exploration?
x86 really just for exploration, but I could say much the same for ARM.
>> Bearing in mind that I've not really used Forth since doing my Masters
>> [mumble] years ago, and that my use of Sun's implementation was mostly
>> pretty trivial, I think I need an idiot's guide as to what can be done
>> from the command line e.g. how to get aliases populated. At the very
>> least so that I can ask questions intelligently.
>
>
> http://www.firmworks.com/QuickRef.html
Thanks, I'd missed that and had been working through the IEEE doc.
>> I've really only got OFW working today, I tried (on some different
>> systems) a few months ago but I suspect that the "Making a Prototype
>> Floppy Image with Linux Commands" didn't work properly for me.
>>
>> Now that I am able to run successfully on a PC, is there a standard
>> config that I can use which will allow me to dump boot sectors etc. on
>> BIOS-supported discs (i.e. preferably both IDE and SCSI)?
>>
>>>> I'm hoping to eventually put it on some ARM-based development boards as
>>>> an interactive layer before they boot Linux (etc.) from disc.
>>>
>>> My current work at One Laptop Per Child is ARM-based, so the OFW ARM
>>> port is being actively maintained and enhanced. I have versions that
>>> you can load from uboot and others that run directly with no
>>> underlying firmware. The latter, of course, requires that you take
>>> responsibility for the low-level issues of memory controller and DRAM
>>> initialization.
>>>
>>> If you are a consumer of the board, then it's probably better to use
>>> whatever firmware is already there as the initial loader, using OFW as
>>> the boot manager as you say. If you are developing your own hardware,
>>> it starts to make sense to use OFW from the ground up.
>>>
>>> Feel free to contact me directly if you need additional guidance. At
>>> this point I'm more interested in the ARM version than the x86
>>> version, so the sooner you get onto ARM, the more help I'll be able to
>>> offer.
>>
>> Bear in mind that I'm doing this on spec,
>
> Effectively, so am I. The existence of other open source firmware
> solutions such as uboot and coreboot (formerly linuxbios) and
> bootloaders like GRUB have made it difficult bordering on impossible to
> make money with Open Firmware, except via consulting, and the market for
> that is rather limited.
Although I think that OFW is about the only one that has the potential
for doing things like listing the partition table (and associated code).
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
Given a copy of OFW booted from floppy on a PC, is there a comparatively
straightforward way of using it to boot an OS or loader from other block
devices or over the LAN, in the way that I'm used to on Sun kit?
I'm hoping to eventually put it on some ARM-based development boards as
an interactive layer before they boot Linux (etc.) from disc.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
Author: wmb
Date: Thu Mar 3 19:32:13 2011
New Revision: 2177
URL: http://tracker.coreboot.org/trac/openfirmware/changeset/2177
Log:
ARM assembler - Changed the "[ifdef] armv7" guarding the use of the
movw instruction in (set) to a runtime value "use-movw?" (default
value false), so the system can be compiled to run anywhere, but
it can later generate architecture-specific code for special purposes.
Modified:
cpu/arm/assem.fth
Modified: cpu/arm/assem.fth
==============================================================================
--- cpu/arm/assem.fth Thu Mar 3 07:14:41 2011 (r2176)
+++ cpu/arm/assem.fth Thu Mar 3 19:32:13 2011 (r2177)
@@ -44,6 +44,8 @@
defer asm-set-relocation-bit
also arm-assembler definitions
+false value use-movw?
+
: asm, ( n -- ) here /l asm-allot asm! ;
previous definitions
@@ -1162,15 +1164,15 @@
true asm-const ( reg# op )
then
else ( reg# imm imm )
-[ifdef] armv7
- 0 1.0000 within if ( reg# imm )
- set-imm16 0300.0000 ( reg# op ) \ movw rN,#<imm16>
- else ( reg# imm )
- false asm-const ( reg# op )
- then
-[else]
- drop false asm-const ( reg# op )
-[then]
+ use-movw? if ( reg# imm imm )
+ 1.0000 u< if ( reg# imm )
+ set-imm16 0300.0000 ( reg# op ) \ movw rN,#<imm16>
+ else ( reg# imm )
+ false asm-const ( reg# op )
+ then ( reg# op )
+ else ( reg# imm imm )
+ drop false asm-const ( reg# op )
+ then ( reg# op )
then ( reg# op )
then ( reg# op )
iop rd-field !op