Hi,
I noticed a problem in the multiboot memory map in v3. Instead of the
reserved region:
addr=0x0, len=0x500
we get:
addr=0x0, len=0x10
the reason being that the multiboot map is generated too early in
arch_write_tables(), before a number of routines that write/reserve
stuff are executed (in my test this only affects the 0x0-0x500 region
but I notice there's other stuff too).
Attached patch moves it down, solving the problem. Because stage1 can no
longer assume the MBI is at 0xf0000, I had to add a return path for stage2
to give it a pointer, using its exit status value.
As collateral benefit, my patch removes the FIXME about PIRQ alignment.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Hi,
I noticed that free regions provided by search_global_resources() don't have
the reserved regions substracted from them. This patch introduces a check
to weed them out, splitting when necessary.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Hello everybody,
I'm a french master degree student in Free Software ingeneering, looking
for a year project to join and I really love to be involved in Coreboot
community to :
improve AMD690G chipset support, or
Openmoko coreboot port or
port coreboot-v3 to Gigabyte M57SLI-S4, I've got one to develop.
I just need that someone supervise my work and do, monthly, a feedback to
my teacher at the university to have a note.
Son is someone interested ?
Thank you for your attention,
Regards,
Cedric RIVERA.
Master I2L - Université du Littoral - Côte d'Opale, France.
Hi,
since the market share of machines with a serial port is shrinking
rapidly and USB debug cables are not affordable at all for hobbyists, we
may need to support console on parallel port.
I do realize that not all machines lacking a serial port will have a
parallel port, but as long as it improves our console coverage, I'm
inclined to suggest parallel console support as a viable option.
Parallel port console support has the advantage of being faster than
serial port console, at the same time keeping the cost for a cable in
the single digit dollar range.
What do you think?
Do we have any other devices on board which don't require interrupts to
run? Floppy connector? POST cards? PC speaker (with 1-wire protocol)? Is
it possible to use any of them with cheap home-built adaptors?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Daniel Lindenaar 写道:
> Hi Guys,
> I've almost got coreboot v2 working on my setup. The only big problem I'm still facing is that it only works after I clear the cmos using a jumper on the motherboard. If I then boot, it works, but after rebooting it doesn't work anymore.
I have this problem too on EPIA-MII. But after changed Development
machine to Red Hat 9 or Fedora Core 5, rebooting is ok.
It was a long time ago so I can not remember the exact distro. Suggest
changing distro or Compiler version to have a try.
> It seems as though jumping to the 'normal' image doesn't work correctly.
>
> Sounds familiar? Any suggestions?
>
> regards,
> Daniel
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
#16: console colors need to be padded to end of line
------------------------------------+---------------------------------------
Reporter: hawke(a)hawkesnest.net | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: FILO | Version:
Keywords: | Dependencies:
Patchstatus: there is no patch |
------------------------------------+---------------------------------------
When the console color is specified, the background after a newline
remains black. It should be space-padded, or changed in some other way so
that the screen is entirely as specified.
--
Ticket URL: <http://tracker.coreboot.org/trac/filo/ticket/16>
FILO <http://www.coreboot.org/FILO>
#15: 'color' command doesn't accept
------------------------------------+---------------------------------------
Reporter: hawke(a)hawkesnest.net | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: FILO | Version:
Keywords: | Dependencies:
Patchstatus: there is no patch |
------------------------------------+---------------------------------------
using symbolic color names with the 'color' command (as described in 'help
color') doesn't work. It just prints 'Error 23: Error while parsing
number'.
--
Ticket URL: <http://tracker.coreboot.org/trac/filo/ticket/15>
FILO <http://www.coreboot.org/FILO>
#10: 'help' word wrapping problem
------------------------------------+---------------------------------------
Reporter: hawke(a)hawkesnest.net | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: FILO | Version:
Keywords: | Dependencies:
Patchstatus: there is no patch |
------------------------------------+---------------------------------------
The help system seems to have slight problems with word wrapping.
For example, 'help terminal':
terminal: terminal [--no-echo] [--no-edit] [--timeout=SECS]
[--lines=LINES] [--
s
...that is, the line beginning 'terminal:' goes out to column 79, and then
on column 80 of the next line, the character 's' is printed. It looks
like filo is maybe expecting CR or LF to do both?
--
Ticket URL: <http://tracker.coreboot.org/trac/filo/ticket/10>
FILO <http://www.coreboot.org/FILO>
I need some help with getting a splashscreen up. This is a short
deadline,, I am looking to have coreboot boot and show this screen
for, say, 5 seconds. I need it working by oct. 20.
If anyone has pointers on where to start in learning how to set this
up, I would appreciate it.
It needs to be on real hardware -- I might try it with a DBE62 if I
can get one in time, or and ADL board if not.
Any vendor who would like their logo on this splash (if it makes
sense) be sure to send me your logo and your permission.
This demo is for a cybersecurity workshop I am going to, various
people in the US are realizing now that security concerns extend into
the BIOS, and they're also understanding the value of an open source
bios. Actually some folks are *very* concerned about what can go on in
the BIOS as this point ... I will try to remember to put a recent talk
up on the web site next week.
thanks
ron
