* Following the previous discussion on the mailing list and Stippi's final mail.
* I tried to get used to it in the last couple of weeks, but I think it just
looks out of place, and not good either.
* In this case, the value is drawn a bit less intense than incomplete values.
* Make the keyboard focus background color depend on the actual background
color.
* No longer allow to drag remove random hint values after removing a value
from a field.
Our more recent build of gcc4 appears to have switched to using
.eh_frame for almost all useful call frame information when built
with debugging. Use a somewhat crude heuristic (size) to determine
if the .debug_frame section we've been given might actually be of use
or not (assuming it exists at all, this was inconsistent in my tests.
Sometimes apps had no .debug_frame at all, other times it was present
but was only roundabouts 100 bytes).
Fixes ticket #8508.
* Adjusted initial tracker windows width to fit modified column.
* Resolved a TODO: Added get info shortcut to Open with window.
Author: Sergei Reznikov <diver@gelios.net>
Signed-off-by: Alexandre Deckner <alexandre.deckner@uzzl.com>
Factor out updating of the source path view into a dedicated function,
and fix some errors that would sometimes result in the text not updating
properly when switching stack frames, particularly if the target frame
didn't have source code available.
Following some recent changes, the collection of strings does not use
B_COLLECTING_CATKEYS define anymore. Adjust the code to use
B_TRANSLATE_MARK_VOID instead, leading to the same result (string is
added to catalog, but not used)
Calculations that take up the full width of the Deskcalc window
sometimes scroll the result over showing you only the tail end. This
is because the horizontal inset makes the area too small to fit the
result. Removing this horizontal inset means that the result will
always fit in the space provided, and Deskcalc will recalculate to
fit, but it also means that the result always starts at the leftmost
side of the textarea, a fair tradeoff.
* While the baremetal arm book I have says mrc, it breaks
verdex and doesn't work on the Pi.
* Moving the page table address to the p15 coprocessor makes
more logical sense anyway... i think mrc was a typo.
* the common part should try to use the U-Boot API when found.
* the arch part can make use of cpu features (like timer register)
* the ppc code enables the FPU in the MSR, since it's used by vsnprintf(),
which at least saves one FP register in its prologue.
* gPeripheralBase keeps track of the device
peripherals before and after mmu_init
* Add ability to disable mmu for troubleshooting
* Remove static FB_BASE, we actually don't know
where the FB is yet. (depends on firmware used)
If Haiku has the hostname set, inform DHCP server with corresponding
option in DHCPDISCOVER and DHCPREQUEST messages. That should simplify
accessing Haiku hosts by using it's hostname instead of raw addresses.
* BCM2708 defines no longer assume 0x20 address
We will be throwing away the blob memory mapping
and using our own.
* Use existing blob mapping to turn GPIO led on pre mmu_init
* Remap MMU hardware addresses from 0x7E. We could map each device,
however the kernel will throw away the mappings again anyway. For
now we just map the whole range and use offsets.
* Serial uart no longer works, however at least
we know why now :). Serial driver now needs to
use mapped address.
* Use U-Boot mmu code as base
* This will be factored out someday into common arch mmu
code when we can read Flattened Device Trees
* Move mmu_init after serial_init.
Temporary change as we will want serial_init to use
memory mapped addresses... for debugging.
* since we include BoardSetup earlier now, the TARGET_* flags were discarded. Use HAIKU_* instead.
* Add variables to hold the default entry point and the desired uimage OS emulation.
