more of a work-around than anything else. the observation is
the PDDB_A* series of constants aren't used outide of the crate
for gen2-targets and so we just remove it as a dependency in
the lib.rs side of things.
This clears up the cargo error we're getting. still don't know
why the dependency tree is not working for that particular target,
but someone is pulling a pddb dependency and it's not obvious who.
still broken, there is a weird dependency problem on
board-baosec target that is still to be debugged, but
wanted to get everything committed so i can try bigger
experiments without losing state
this is a fairly major re-org of where key constants go that
define platform features. things that were in xous-rs that were
platform specific (namely precursor) were moved into a boards file,
and things that are generic to the system (like PAGE_SIZE) are moved
to a public location in xous-rs::arch.
note that this also triggered a huge format of a crate
that was marked for non-formatting to make diffs easier to
the opensk mainline
however, it is OK to format these specific submodules because they
are platform implementations that don't exist in opensk, so there
is nothing to diff against
this constant was just used to create a "realistic" test case
instead of trying to add the dependency we just hard-code the
constant into the test case, because in the end what we wanted
was that specific constant to test a specific edge case of
a progress bar.
BOOKEND test sentinels are moved out of xous-rs, and into the
board definitions allowing us more flexibility on configuration
board-specific test configs (before it was a xous-wide constant,
which seems a bad idea because it makes migrating test infra
hard as the manufacturing infra updates)
MMAP_VIRT as a range is also added is this commit
this allows us move board-specific parameters out of xous-rs
and into a board library that is consistent with the new board
libraries, reducing special case code for Precursor
This enables a couple of things that have been long wanting, including:
- the ability to know what PAGE_SIZE is from a single central define
- the ability to determine where certain virtual memory ranges are
located (useful for the userspace swapper).
Previously these were "hidden" from crates because they were embedded
directly in the kernel implementation module, which is not accessible
as a dependency, thus causing us to e.g. create redundant copies of
the PAGE_SIZE variable. This hopefully makes migrating to a larger
page size in some future version of the OS a bit simpler.
the policy is to format the PDDB automatically on boot if
it can't be mounted.
Need to think about whether this is the right thing to do
or not for the product: if there is any sort of error, it will
just wipe the PDDB entirely, making it unrecoverable.
That being said, why would there be an error? if that happens,
something bad probably happened to the hardware. I feel like
if the SPI interface is reliable this shouldn't be a problem.
So the solution is to make sure the hardware is reliable...
on the other hand, fundamentally, SPI flash can wear out, so
this could aggravate problems at EOL for the device (i.e.
it will take small problems and "amplify them up" into a huge
problem).
The trade-off is...the auto-format makes the token "just work"
on boot. Maybe the right thing to do is to add some code that
checks to see if we're in a true blank state, and if so,
autoformat; and if it looks like something was there before,
prompt for a format?
tbd.
this is a common api problem because yes, while arg1 is strictly
the second item, previously arg0 was hidden and in the argument
list arg1 took the first place not the second. so i make this
mistake a lot...
KB_C2 pin on this test board just got shorted to ground internally
in the chip. I think it may have been due to power glitches
when the ammeter was switching modes feeding through and causing
trouble for the system.
Anyawys, disable that row and remap some keys so we can continue
with testing. MPW boards will hopefully be retired soon enough...
