This helps when debugging, since when a driver/module causes a crash
while registering with the device manager, you can actually look at
the device manager state ;-)
The previously used method for programming the timer did not take
into account that our timespec is 64bit while the register we poke
it into is 32 bit. Since the PXA (SoC in Verdex target) has a limited
scale of resolution (us,ms,second) we dynamicly determine the one
that we can most closely match, and set that.
For f.ex. snooze to work however, we also need system_time to work.
The current implementation uses a system timer at microsecond
resolution to keep track of time.
Although the code is far from perfect, committing it now before
it gets lost, since I'm working on the infrastructure code
to properly factor out the SoC specific code out of the core
ARM architecture code (so the kernel can support more then
our poor old Verdex QEMU target ;))
The "blobs" in a U-Boot uimage are aligned at 4 bytes, which we
did not take into account. Found this when adding a 3rd blob
containing the Flattened Device Tree for ARM.
As korli suggested use B_PAGE_SIZE for defining stack size related
definitions what seems to be more natural for them and also may
help if we ever support an architecture with page size different than
4kB.
* Seems like there was no easy way to simply invalidate
a given BRow. Introduced BColumnListView::InvalidateRow().
* BRow::SetField() tried to invalidate the row, but invalidated
the listview instead of the BOutlineView responsible for
drawing the list contents. Use the new InvaalidateRow().
- B_PRIx8 unfortunately doesn't necessarily strictly stay within the bounds
of an 8-bit hex constant, so force the size passed to snprintf to make it
that way.
- The Inspector's memory view now supports selecting chunks of the hex display in
the manner one would in a TextView. The selection can also be copied to the clipboard,
or if it matches the size of a target address, can be used as input for an address to
inspect directly.
Still needs some fine tuning, but basically works.
- If it was necessary to help the debugger locate a particular source
file due to it not being found on disk at the location specified in
the debug information, the associated user-supplied path mappings
are now saved and restored in the team settings. The file manager still
needs a bit of extra work to apply these as files are added though.
The Problem was observed in the Time Preferences Zone view - the
selection was set inside of TimeZoneView::DoLayout() call on
the OutlineListView control that had zero-sized Bounds. After
the control was resized the selection stay mainly hidden "under"
the upper edge. The Problem looks like generic so should be fixed
in the interface kit code. Proposed fix introduces additional check
for the scroll position to not cross the top edge of control.
Instead of storing PackageInfo objects directly in the
PackageLists, store PackageInfoRefs instead. This makes a
lot of operations much cheaper, and it also allows making
changes to a PackageInfo (which now exists only once)
and have those changes reflect everywhere. In particular,
it will be easier to populate some information of the
PackageInfo lazily, and to listen for changes on a
PackageInfo object.
This as the intel partition addon just does a very weak test, and the
NTFS test is much safer. This prevents NTFS filesystems that have a
valid boot sector signature but no partition table, from being
picked up by the intel partition table add-on instead of the ntfs
add-on.
Patch provided by markh, thanks!
...instead of B_DEV_NO_MEDIA. The latter seems to imply we stop testing
the unit is ready in usb_disk_device_added().
Based on a patch provided by markh in #9589.
This is a workaround for hiding U-Boot that is stored in the first 2
128k blocks, so we can put a BFS image into NOR to boot from (since
we do not have support for SD/MMC yet in Haiku).
When manually putting a BFS filesystem at block 3 we actually get
right up to the point where BootScript is attempted to be executed!
Specifying -Werror in the Jamfiles directly prevents the build
system from disabling error-on-warning for some arch specific
warnings (or even globally), breaking the ARM build.
The "src/apps" directory is already setup to compile with -Werror
by the build system anyway, so remove the explicit setting here.
Turns out dd on MacOS does not like '1M' as size descriptor, but
wants '1m'. To prevent us breaking Linux builds (as it does not
accept 1m), just use the actual number of bytes explicitely instead.
