* The vesa driver no longer uses VGA programming if the chip does not support
VGA compatibility.
* The VESA driver now tries to set the DAC to 8 bits per color gun.
* In VESA modes, the driver no longer tries to use VGA programming; introduced
the new vesa_set_indexed_colors() that is now used for palette programming.
This should fix wrong colors of 8 bit BWindowScreen users with VESA on real
hardware (emulators usually didn't mind either way).
* Note that the app_server needs to maintain a palette per 8 bit screen, as
right now, the colors are garbled after a workspace switch. Stefano, are you
looking into that already?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96
- don't clobber the parameter regs in the entry point,
- fix entry point address for netbsd loader emulation,
- added a gUImage global to point to the uimage blob with the tgz,
- added tgz info to platform stage2 args,
- add simple uimage support, just dumps the header and gets the nth blob in the image, (seems we have a bug in the math code, some infos don't print),
- made devices.cpp use them to publish the MemoryDisk,
- add an haiku_loader_nbsd.ub target which puts both the loader and kernel_arm for now (need to replace with the tgz).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32295 a95241bf-73f2-0310-859d-f6bbb57e9c96
- added some multiboot support code:
- dump some of the passed info,
- parse command line (skip the 'kernel' name and pass the rest to stage2_args.arguments),
- added an add_stage2_driver_settings() function which takes stage2_args.arguments and translates it into safe mode driver settings, a bit dumb for now.
This allows using qemu -kernel haiku_loader -append 'debug_screen true' and get debug output without having to enter the menu (once multiboot info is used to determine the boot device too).
The idea is to allow passing driver settings and using them to pass extra stuff (like 'force_keymap fr' and other stuff for demo), and to help automate tests ('run_test /bin/sometest').
This should answer Axel's question :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32076 a95241bf-73f2-0310-859d-f6bbb57e9c96
- code is disabled yet as the bootloader doesn't have add_boot_item.. will need to pass via kernel args
- add a GetFileMap() method to the vfs, and implement it in FAT code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28445 a95241bf-73f2-0310-859d-f6bbb57e9c96
letting the boot loader provide full paths for the pre-loaded images.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27753 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Reduced the kernel_args array size from 32 to 16 (7 are used on a normal
build).
* Cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27690 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Adjusted used files systems accordingly.
* BFS::Stream::GetName() was broken. It accessed the small data region
which wasn't loaded, since BFS::Stream derived from bfs_inode, which
is a variably-sized structure with the small data region at the end.
Changed that to a ref-counted, shared member instead.
* Implemented RootFileSystem::GetName().
* Added Directory::GetPath() to get a full path of the directory or an
entry.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27664 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implement color palette generation for the boot splash images in the
generate_boot_screen build tool. Only 4-bit screen support is missing now.
* Adopted images.h with the new results from generate_boot_screen.
This should fix black boot screens for graphics cards that don't support
true color modes for the native resolution. I've tried to find the ticket,
#2177 almost looks like the one, but it looks more like the mode is out
of range if I understand the ticket right.
Thanks a lot, David, and sorry it took so very long to apply your patch!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27223 a95241bf-73f2-0310-859d-f6bbb57e9c96
be put into a boot_item in frame_buffer_console_init().
* The VESA driver now supports gettings the EDID information as well; this
is necessary now, since the app_server no longer takes over the mode the
boot loader had chosen.
* Note, we might want to do this via vm86 instead in the future, and remove
the kernel part again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25786 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Revised the RLE algorithm used for compressing the boot splash artwork to
handle uncompressed runs.
* Compress the RGB channels separately for improved efficiency.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24844 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented RLE compression for the boot splash images, resulting in
smaller kernel and boot loader.
* Only the boot loader contains the RLE compressed images, the decompressed
buffer for the icons is passed to the kernel via kernel args.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24812 a95241bf-73f2-0310-859d-f6bbb57e9c96
The dividing line is back although with a little more spacing. Also the icon
spacing is a little increased and I added a subtle outline as well as a little
brighter background for the active icon look. The placement logic is now not
independant of each other anymore, otherwise I couldn't center both images
as a unit. But only the vertical placement is affected.
Comments as always on the commit mailing list... :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24796 a95241bf-73f2-0310-859d-f6bbb57e9c96
the icons are centered.
* The boot loader and kernel now use the placement info that
generate_boot_screen now generates.
* Made the code that draws the images handle the case where any of the images
is larger than the frame buffer.
* All drawing functions need to know the image width (analogous for bytes per
row).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24773 a95241bf-73f2-0310-859d-f6bbb57e9c96
item entry.
* The bios_ia32 video platform code now stores the available VESA modes in
the new vesa_modes kernel_args field.
* When configuring a VESA mode via settings file, it's no longer needed to
specify the exact mode - the closest available mode is now used. This should
help with bug #1962.
* frame_buffer_console_init() now also creates a boot_item for the VESA modes
in the kernel_args.
* The VESA accelerant now filters the mode list to only contain modes that
are actually supported.
* Moved non-shared vesa driver data into its own file vesa_private.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24675 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The boot splash code now checks wether debug screen output is enabled or not
using the above function.
* The boot splash code no longer maps it's own copy of the frame buffer, instead,
it will use the boot item feature as the VESA driver does. Also removed the
lock, as that's not needed at all.
* Renamed splash.cpp to boot_splash.cpp, and boot/splash.h to boot_splash.h
(it's not part of the boot loader, but the kernel).
* Removed dead code from boot_splash.cpp, added license. Replaced license
header in boot_splash.h to a style guide conforming one.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24489 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed the icons image, it was upside down.
* Support the new 24 bit boot screen images in the boot_loader and the kernel.
* Prepare the code for future indexed versions of the boot screen images.
But the generate_boot_screen tool currently does not generate those.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24449 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Calculate icon offset from stage in splash.cpp, remove hard coded placement
values. Draw only icon, not the whole image from top/left to right of
icon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24439 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added the feature of an animated boot screen (icons lighting up at
different boot stages).
* Added first version of new boot splash images, generated by the new
hsbg tool. (Also finally contains the "new" Haiku logo.)
changes by myself:
* Added Artur to the contributors list in About System.
* Fixed some left overs in the patch, kept tracing turned off.
TODO:
* Remove the need for hard coding the icon positions. (Maybe generate
those from hsbg and put them into images.h? Have user provide icon
spacing/offsets at the command line for hsbg?)
* Rename the stages to something meaningful.
* Use hsbg as a build system tool and generate images.h during build
from PNGs provided in the artwork folder.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24434 a95241bf-73f2-0310-859d-f6bbb57e9c96
passes that information on to the kernel. This should fix wrong bytes per row with
certain resolutions and graphics cards.
* The boot loader now recognizes 15 bit modes that are advertised as 16 bit modes.
This should fix wrong colors in 16 bit modes on some cards.
* Reenabled setting MTRR for VESA mode - don't remember why I disabled it, but it
works fine on my test machines.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23006 a95241bf-73f2-0310-859d-f6bbb57e9c96
serial output, and puts it into the new kernel_args::debug_output field.
* syslog_init() will now check if there is anything in kernel_args::debug_output
and will put that into the syslog buffer.
* dump_block() now also prints an offset.
* Fixed warning in mmu.cpp.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23003 a95241bf-73f2-0310-859d-f6bbb57e9c96
does no longer give partitioning systems precedence over file systems.
The one with the greater identification priority wins. ATM, if a file
system wins, we still mount the first file system that recognized the
partition at all, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22446 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
in addr_range.h to add ranges to the arrays. This fixes the crashing bug reported
by Larry Baydak.
* Added some more exported functions to kernel_args.cpp (prototypes are in addr_range.h).
* TODO: let the PPC/OpenFirmware implementation use those as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19739 a95241bf-73f2-0310-859d-f6bbb57e9c96
pretty close, and the number of loaded modules have a direct influence on
this (even though we're currently loading the symbols by default).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19320 a95241bf-73f2-0310-859d-f6bbb57e9c96
This allowes to actually execute the boot loader now.
Need to use Ingo's remote_disk_server now for booting.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19113 a95241bf-73f2-0310-859d-f6bbb57e9c96
information to identify the boot volume - if we want to be able to map all BIOS
drive IDs to the disks in the system, we need to do this always, though.
* Forgot to commit the updated disk_identifier.h in the last commit...
* Removed the unused dumpBlock() function from devices.cpp.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16892 a95241bf-73f2-0310-859d-f6bbb57e9c96
We don't do anything with it yet, though, so the BIOS will probably ignore us since
we are supposed to poll for events.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15900 a95241bf-73f2-0310-859d-f6bbb57e9c96
device in the Open Firmware implementation of boot loader and
pass its path to the kernel, where it's opened and used for
getting/setting the real time. The expensive atomic_*64() on PPC
32-bit make things a bit more complicated. Moreover, missing
64 bit multiplication and division instructions won't really
allow system_time() to be anywhere near as fast as on x86. :-/
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15837 a95241bf-73f2-0310-859d-f6bbb57e9c96
{HAIKU,HOST,TARGET}_KERNEL_PIC_{CC,LINK}FLAGS which define the
compiler/linker flags specifying the kind of position independence
the kernel shall have. For x86 we had and still have -fno-pic, but the
PPC kernel has -fPIE (position independent executable) now, as we
need to relocate it.
* The boot loader relocates the kernel now. Mostly copied the relocation
code from the kernel ELF loader. Almost completely rewrote the PPC
specific relocation code, though. It's more correct and more complete now
(some things are still missing though).
* Added boot platform awareness to the kernel. Moved the generic
Open Firmware code (openfirmware.c/h) from the boot loader to the kernel.
* The kernel PPC serial debug output is sent to the console for the time
being.
* The PPC boot loader counts the CPUs now and allocates the kernel stacks
(made OF device iteration a bit more flexible on the way -- the search
can be restricted to subtree). Furthermore we really enter the kernel...
(Yay! :-) ... and crash in the first dprintf() (in the atomic_set()
called by acquire_spinlock()). kprintf() works, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15756 a95241bf-73f2-0310-859d-f6bbb57e9c96
specifying whether only the exact supplied address is acceptable. If
false, the address is considered a hint only. It will be picked, if
available, otherwise a greater address is tried to be acquired, and
as last resort any address. This feature is only implemented for PPC.
It is needed since the preferred kernel text base address 0x80000000
might not be available (and actually isn't on my Mac mini).
* Fixed a bug in the PPC memory management code:
is_{virtual,physical}_allocated() were checking whether the given
range was completely contained by an existing range instead of
checking for intersection. As a consequence we could (and did) allocate
a range intersecting with already allocated ranges. The kernel segment
thus overwrote OF memory for instance.
* The ELF loader makes sure that it got both text and data segment of
the image to be loaded.
The PPC boot loader successfully loads kernel and modules now. Next
comes the hard part, I'm afraid.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15708 a95241bf-73f2-0310-859d-f6bbb57e9c96
IP, and UDP, as well as a home brewn UDP based protocol, "remote disk",
which provides random access to a single remote file/device. The Open
Firmware flavored boot loader automatically initializes the net stack,
searches for a remote disk, and tries to boot from it, if the boot
device is a network device (e.g. when loading the boot loader via
TFTP).
This is quite nice for developing with a two-machine setup, since one
doesn't even need to install Haiku on the test machine anymore, but can
serve it directly from the development machine. When the networking
support in the kernel is working, this method could even be used to
fully boot, not just for loading kernel and initial modules.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15689 a95241bf-73f2-0310-859d-f6bbb57e9c96
Jonas Sundström