The GPIO revision check assumed the major and minor revision numbers where
located at same location in the register. This is not true.
Change-Id: Ieaff07ed8a19e6b4cf1d121a41d3290880b78a82
The bug in the offset correction code for the 'shrink region from
below' case can easily case an assert(foundregion->offset == offset)
to trigger (if the blocks are touched afterwards, e.g. on fork())
as the offsets become wrong. This commit is a fix & regression test.
Change-Id: I28ed403e3891362a2dea674a49e786d3450d2983
We currently have a few of the POSIX tests failing because filemmap
is enabled by default. The working assumption is that these program
pass a pointer to the file server that points to a not yet loaded
data segment. When the file server tries to access that data it
therefore generates a pagefault and a call to itself it can not
handle because it is unable to first return the current call.
Change-Id: Ic1a2d9cd0a542bd950e2b08accb61cfe2855c5a3
Make the kernel server and driver binaries indentical for the different
ARM platforms. We no longer need to define the AM335X or DM37XX flags
during compilation. The remaining differences are all located in u-boot.
Change-Id: I14ac60837dd2d7f116bc5fa56d3989b48d7c4fea
During startup machine.board_id is now determined. The kernel can now
at runtime determine how to configure itself and does so.
Change-Id: I4f615af9bfa5add219e618b911a51af127591d6a
On startup determine the board_id based on the board name
passed from u-boot. This code also export "board" for use
by userland using sysenv.
Change-Id: I1064a49497c82b06f50d98650132bc0a7f543568
Put the boot arguments in uEnv.txt and not in cmdline.txt to allow
a more dynamic configuration of the system. We now also pass the
u-boot board_name parameter to the kernel.
Replaced the wget download of u-boot by a versioned git checkout
this allows us to better manage the u-boot and MLO version we ship
while still allowing us to build ofline.
This changes replaces the BASE_URL setting by U_BOOT_BIN_DIR and
also updates to a newer build of u-boot.
Export the board variable to userland using sysenv. This
allows rc-scrips to perform device specific initialisation.
The board variable follows the following pattern
[ARCH]-[ARCHVARIANT]-[VENDOR]-[BOARD]-[BOARDVARIANT]
We currently we support the following boards:
X86-I586-GENERIC-GENERIC-GENERIC
ARM-ARMV7-TI-BBXM-GENERIC
ARM-ARMV7-TI-BB-WHITE
ARM-ARMV7-TI-BB-BLACK
Change-Id: I9e5f5f24f9a71cc9797cacb1aafb19499613f0be
Modified the machine struct in include/minix/type.h to have an
additional field called board_id. This fields can be read out
by userland and drivers at runtime to enable automatic
configuration. The board_id field contains information about
the hardware architecture / board and such.
Change-Id: Ib12bc0d43fc9dbdb80ee0751c721ee516de1d2d6
Forward-port of the run script change in the testvnd
commit on the 3.3.0 branch by David.
Needed to cleanly run the testisofs test as root in
the Jenkins environment.
'While here,' also fix messy which output in testsh2.
Change-Id: I6ec472e1386a54ae74b6e55394f01fa7c5ce53a9
testmfs: catch MFS format changes
This test tests mkfs.mfs will generate the same FS image given the same
input files. mkproto creates a proto file (normalizing directory entry
order). The assumption is that a change in the output flags a tacit
change in FS format, and that a FS format change will cause the image
to change.
. Changes to mkfs.mfs that innocently change the format can
change the sha1 output in the script along with it.
. The assumption is that corresponding versions of mkfs.mfs and
MFS will always work together; otherwise a lot breaks (ramdisk etc.)
. Therefore, as long as a generated FS image stays the same with the
same input now, incompatible MFS changes will still be flagged,
even if they work together with the current mkfs.mfs.
testisofs: test ISO filesystem
. to test isofs: prepare an ISO FS image using writeisofs, copy it
to a RAM device, mount it using the iso9660fs server, compare the
SHA1 contents of the files on the ISO with the inputs.
. use su to run certain commands in the script as root
run script: run shell script tests
. they are installed without .sh so should be
searched for as such
. add diagnostic when tests are skipped
Change-Id: I30daff58e1e43903dacf3c99996a4a0e7d819b6b
The memory-mapped files implementation (mmap() etc.) is implemented with
the help of the filesystems using the in-VM FS cache. Filesystems tell it
about all cached blocks and their metadata. Metadata is: device offset and,
if any (and known), inode number and in-inode offset. VM can then map in
requested memory-mapped file blocks, and request them if necessary.
A limitation of this system is that filesystem block sizes that are not
a multiple of the VM system (and VM hardware) page size are not possible;
we can't map blocks in partially. (We can copy, but then the benefits of
mapping and sharing the physical pages is gone.) So until before this
commit various pieces of caching code assumed page size multiple
blocksizes. This isn't strictly necessary as long as mmap() needn't be
supported on that FS.
This change allows the in-FS cache code (libminixfs) to allocate any-sized
blocks, and will not interact with the VM cache for non-pagesize-multiple
blocks. In that case it will also signal requestors, by failing 'peek'
requests, that mmap() should not be supported on this FS. VM and VFS
will then gracefully fail all file-mapping mmap() calls, and exec() will
fall back to copying executable blocks instead of mmap()ping executables.
As a result, 3 diagnostics that signal file-mapped mmap()s failing
(hitherto an unusual occurence) are disabled, as ld.so does file-mapped
mmap()s to map in objects it needs. On FSes not supporting it this situation
is legitimate and shouldn't cause so much noise. ld.so will revert to its own
minix-specific allocate+copy style of starting executables if mmap()s fail.
Change-Id: Iecb1c8090f5e0be28da8f5181bb35084eb18f67b
. mkfs.mfs: -T option to set timestamp of files on FS
. mkproto: normalize (sort) order of directory entries
. mkproto bugfix: always print mode in 3 digits (%03o)
Change-Id: Ice06d5f05500cd2ac9b063156c340b8f78fe6441
Jenkins was failing on usr.bin/calendar/calendar.c:386:6: with
"error: 'fd' may be used uninitialized in this function"
when the level of error checking was turned up.
The error was recently fixed upstream. This commit updates
calendar.c to upstream rev 1.50, updates calendar files too.
Change-Id: Ibe0695bf5d0315972f2a4fb1175219dd12cbfa5a
eepromread could only read EEPROMs through the /dev/i2c interface.
Once the cat24c256 driver is started and claims/reserves the
device, it can no longer be read through the /dev/i2c interface.
This patch adds support for reading from EEPROMs through the
/dev/eeprom interface. For example, to read the on-board eeprom
on the BBB, one would do `eepromread -f /dev/eepromb1s50 -i`.
Change-Id: If08ce37231e593982eeb109bdd6d5458ad271108
