Commit graph

11 commits

Author SHA1 Message Date
Ian Lepore
d45f99dee1 Go back to using uintptr_t, because code that actually compiles is
infinitely less buggy than code that is theoretically correct in some
alternate universe.

The uintfptr_t type is apparently a freebsd invention, and exists only when
compiling the kernel.  It's a little hard to say for sure, since it doesn't
seem to be documented anywhere except in email advice to unsuspecting and
overly-trusting souls, who then get to wear the pointy hat for blindly
following advice without investigating or testing it first.
2016-01-13 00:22:12 +00:00
Ian Lepore
c1f892e0d1 Cast using uintfptr_t and eliminate the cast to uint64_t which is uneeded
because rounding down cannot increase the number of bits needed to express
the result.

I had no idea there was such a thing as uintfptr_t.

Requested by: bde
2016-01-12 16:31:07 +00:00
Ian Lepore
24bbe7a40c Cast pointer through uintptr_t on the way to uint64_t to squelch a warning. 2016-01-02 22:55:59 +00:00
Ian Lepore
577353fcbf Use 64-bit math when finding a block of ram to hold the kernel. This fixes
a problem on 32-bit systems which have ram occupying the end of the physical
address space -- for example, a block of ram at 0x80000000 with a size of
0x80000000 was overflowing 32 bit math and ending up with a calculated size
of zero.

This is a fix for one of the two problems mentioned in the PR.  Something
similar will need to be done on the kernel side before the PR is closed.

PR:		201614
2016-01-02 18:16:24 +00:00
Maxim Sobolev
8f207db125 Fix bug in the ubldr introduced in the rev.283035. The new code
fails to properly consider memory regions when the loader is
located below of those regions or engulfs their lower limit. This
results in "not enough RAM to load kernel" panic, which is totally
bogus. On top of that, there are some variables that can be left
unitialized in those cases, which might cause it fail with memory
access violation instead of panic while trying to load kernel to
a wrong or non-existing address of memory.

Augment the code to properly deal with the loader being below or
at the lower bound of the memory region in question. Also, don't
leave ununitialized variables behind.

Reviewed by:	ian
2015-06-19 17:00:36 +00:00
Ian Lepore
45f8d9f9a8 An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that.
Previously, ubldr would use the virtual addresses in the elf headers by
masking off the high bits and assuming the result was a physical address
where the kernel should be loaded.  That would sometimes discard
significant bits of the physical address, but the effects of that were
undone by archsw copy code that would find a large block of memory and
apply an offset to the source/dest copy addresses.  The result was that
things were loaded at a different physical address than requested by the
higher code layers, but that worked because other adjustments were applied
later (such as when jumping to the entry point).  Very confusing, and
somewhat fragile.

Now the archsw copy routines are just simple copies, and instead
archsw.arch_loadaddr is implemented to choose a load address.  The new
routine uses some of the code from the old offset-translation routine to
find the largest block of ram, but it excludes ubldr itself from that
range, and also excludes   If ubldr splits the largest block of ram in
two, the kernel is loaded into the bottom of whichever resulting block is
larger.

As part of eliminating ubldr itself from the ram ranges, export the heap
start/end addresses in a pair of new global variables.

This change means that the virtual addresses in the arm kernel elf headers
now have no meaning at all, except for the entry point address.  There is
an implicit assumption that the entry point is in the first text page, and
that the address in the the header can be turned into an offset by masking
it with PAGE_MASK.  In the future we can link all arm kernels at a virtual
address of 0xC0000000 with no need to use any low-order part of the
address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
Tim Kientzle
3772ab21ab Clarify an error message. The addresses here are
really offsets within the primary mapped memory block
(which may not start at address zero).
2013-02-18 20:11:20 +00:00
Tim Kientzle
5f5ec09bfb Determine kernel load address dynamically from u-boot memory map.
The generic ELF loading code maps the kernel into low memory
by subtracting KERN_BASE.  So the copyin/copyout/readin functions
are always called with low addresses.  This code finds the largest
DRAM block from the U-Boot memory map and adds that base to
the addresses.

In particular, this fixes ubldr on AM3358, which has DRAM
mapped to 0x80000000 at power-on.
2012-05-20 18:07:35 +00:00
David E. O'Brien
149c7c86d2 style(9) & style.Makefile(9)
Reviewed by:	raj
2008-03-13 17:54:21 +00:00
Rafal Jaworowski
7572ed5a08 Eliminate artificial increasing of 'netdev_opens' counter in loader's net_open().
This was introduced as a workaround long time ago for some Alpha firmware
(which is now gone), and actually prevented net_close() to ever be
called.

Certain firmwares (U-Boot) need local shutdown operations to be performed on a
network controller upon transaction end: such platform-specific hooks are
supposed to be called via netif_close() (from within net_close()).

This change effectively reverts the following CVS commit:

    sys/boot/common/dev_net.c

    revision 1.7
    date: 2000/05/13 15:40:46;  author: dfr;  state: Exp;  lines: +2 -1
    Only probe network settings on the first open of the network device.
    The alpha firmware takes a seriously long time to open the network device
    the first time.

Also suppress excessive output while netbooting via loader, unless debugging.

While there, make sys/boot/uboot more style(9) compliant.

Reviewed by:	imp
Approved by:	cognet (mentor)
2008-03-12 16:01:34 +00:00
Marcel Moolenaar
63094c199a MFp4 (e500):
Add support for U-Boot. This uses the U-Boot API as developed by
Rafal and which is (will be) part of U-Boot 1.3.2 and later.

Credits to: raj@
2008-02-16 22:13:11 +00:00