directory entries cannot span sector boundaries, meaning
that the end of a sector would be zero padded until the
next sector.
we have to skip over these zero paddings to fully read
the directory.
was testing out the git/import tweaks and accidentally
pushed this commit. No comment on whether we want it,
but it definitely wasn't ready for merge.
Oops.
http://fqa.9front.org/fqa1.html#1.2 states the supported archs.
However, clean and nuke also remove build files for 0 (spim) and q
(power). 'mk all' using those archs fails; 'mk kernels' also tries to
build all the kernels, even those which are not supported. For
example, I tried to build the power arch (qc, qa, ql) and without
surprise it failed (when building dtracy): ...
mk dtracy
qc -FTVw dtracy.c
yacc -v -d -D1 parse.y
qc -FTVw cgen.c
qc -FTVw act.c
qc -FTVw type.c
== regfree ==
REGISTER R0 <11> STRUCT DTAct cgen.c:302
== regfree ==
REGISTER R0 <11> STRUCT DTAct act.c:266
== regfree ==
qc -FTVw agg.c
cgen.c:299 unknown type in regalloc: STRUCT DTAct
cgen.c:299 bad opcode in gmove INT -> STRUCT DTAct
cgen.c:302 unknown type in regalloc: STRUCT DTAct
cgen.c:302 bad opcode in gmove INT -> STRUCT DTAct
cgen.c:302 error in regfree: 0 [0]
REGISTERmk: qc -FTVw cgen.c : exit status=rc 387386: qc 387392: error R0
<11> STRUCT DTAct act.c:269
act.c:250 unknown type in regalloc: STRUCT DTAct
act.c:250 bad opcode in gmove INT -> STRUCT DTAct
act.c:266 unknown type in regalloc: STRUCT DTAct
act.c:266 bad opcode in gmove INT -> STRUCT DTAct
act.c:266 error in regfree: 0 [0]
act.c:269 unknown type in regalloc: STRUCT DTAct
act.c:269 bad opcode in gmove INT -> STRUCT DTAct
act.c:269 error in regfree: 0 [0]
act.c:274 unknown type in regalloc: STRUCT DTAct
act.c:274 bad opcode in gmove INT -> STRUCT DTAct
act.c:274 error in regfree: 0 [0]
too many errors
mk: for(i in cc ... : exit status=rc 382748: rc 387379: mk 387381: error
mk: date for (i ... : exit status=rc 373781: rc 382226: mk 382227: error
cpu%
The patch below skips over non-supported architectures. Is that
something we want? This way, 'mk kernels' should work without a
problem (tested on amd64). Then if someone works on getting those
architectures supported again in the future, they can be added back
in.
despite the kernel never doing any efi runtime service calls,
overriding the runtime service regions makes some machines
lock up. so consider them reserved.
the boot service regions should also, in theory, be usable
by the os, but linux says otherwise...
currently the EFI loader's behavior is to search all disks in a
firmware-defined order. we search the list returned by the firmware
in reverse order in the hopes of searching the first 9FAT instead of
the ESP, but this results in unintuitive behavior when there are
multiple FAT partitions (possibly in multiple disks), such as loading
a plan9.ini and kernel from a different disk than the one you executed
the EFI loader from.
to resolve this, we change the EFI loader to instead prefer read
plan9.ini and the kernel from the same disk as the EFI loader was read
from, and then fall back to the old behavior, since the old behavior
is relied on by current installations.
Some UEFI implementations use random UUID based DUID instead of
ethernet address, but use ethernet derived link-local addresses.
So extract the MAC from our IPv6 address.
this makes virtual "memdisk" from SYSLINUX accessible to
the kernel, allowing the iso to be loaded via TFTP and
started without any ethernet or disk drivers available.
copying files from the uefi shell works, reading plan9.ini works,
loading the kernel by calling Read to read in the DATA section of
the kernel *FAILS*. my guess is that uefi filesystem driver or
nvme driver tries to allocate a temporary buffer and hasnt got
the space. limiting the read size fixes it.
there isnt much of a point in keep maintaining separate
kernel configurations for terminal and cpu kernels as
the role can be switched with service=cpu boot parameter.
to make stuff cosistent, we will just have one "pc" kernel
and one "pc64" kernel configuration now.
try the handle buffer in reverse order looking for plan9.ini
to find plan9 partition (9fat). when that fails, we'll default
to the first handle which should be the esp.
instead of including kernel and config in the efi
fat image, we can just include the loaders and
read the plan9.ini and kernel from iso filesystem
just like the bios loaders.
having the memconf() (*e820=) last clutters the screen.
do it first, so we can read *acpi= and *bootscreen=
prints.
we want to continue using tftp even when the /cfg/pxe/$ether
file is not found. only when we detect no pxe/dhcp session,
then we switch to local filesystem (non-network boot).
smart boot manager has a "FAT" signature in its mbr causing
9bootfat to "detect" it as a fat filesystem and then fails
to find plan9.ini.
there shouldnt be a fat filesystem on harddrives at block 0, only
on floppy drives. but some bioses use floppy drive numbers
for usb harddrives so still check for a partition table.
thanks aap for debugging this.
always look for 9fat in plan9 partition even tho the partition
is *not* maked active. marking partitions active is not
recommended anymore with grub so this makes life easier for
some people. multiple plan9 partitions on a single drive
is not supported.
have to copy partition table as buf gets trashed when reading
first block of fat partition. it worked only when the first
fat partition found (the one marked active) was the right one,
but conffat() can fail.
pbs failed to load (silently loading garbage) 9BOOTFAT from start
cluster beyond FFFF because we ignored the low word from the
directory entry. now taking the high 16 bit of the directory's
start cluster into account.
