Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/Makefile.master

we should be using the arm cross-linker

1 line changed: 0 ins; 0 del; 1 mod; 1229 unchg

Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/uts/arm/sys/bootconf.h

fakebop: use a memlist to keep track of physical memory

6 lines changed: 6 ins; 0 del; 0 mod; 112 unchg

Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/uts/armv6/bcm2835/Makefile

bcm2835: we need a loader on this platform as well
As stated before, the Raspberry Pi loader is terrible.  It claims to
supporte ELF file loading, but what it does is crazy.  It loads the ELF file
into memory, gets the start address from the header, converts it into file
offset, adds it to the address where the file was loaded and jumps there.
This is very wrong.  So, instead of booting the loader as an ELF file, we
objcopy it into a plain ol' binary image.  This should be safe because (1)
the loader has no relocations left, (2) whatever benefit we lose from not
having the whole ELF file in memory is only temporary until the loader hands
off control to unix.
Finally, we force the entry point to appear at the beginning of the binary
file by moving _start into its own section (.text.init) and using the
mapfile to put that section before everything else.

5 lines changed: 2 ins; 0 del; 3 mod; 62 unchg

Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/uts/armv6/bcm2835/Makefile.files

bcm2835: we need a loader on this platform as well
As stated before, the Raspberry Pi loader is terrible.  It claims to
supporte ELF file loading, but what it does is crazy.  It loads the ELF file
into memory, gets the start address from the header, converts it into file
offset, adds it to the address where the file was loaded and jumps there.
This is very wrong.  So, instead of booting the loader as an ELF file, we
objcopy it into a plain ol' binary image.  This should be safe because (1)
the loader has no relocations left, (2) whatever benefit we lose from not
having the whole ELF file in memory is only temporary until the loader hands
off control to unix.
Finally, we force the entry point to appear at the beginning of the binary
file by moving _start into its own section (.text.init) and using the
mapfile to put that section before everything else.

4 lines changed: 4 ins; 0 del; 0 mod; 20 unchg

Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/uts/armv6/bcm2835/Makefile.rules

bcm2835: we need a loader on this platform as well
As stated before, the Raspberry Pi loader is terrible.  It claims to
supporte ELF file loading, but what it does is crazy.  It loads the ELF file
into memory, gets the start address from the header, converts it into file
offset, adds it to the address where the file was loaded and jumps there.
This is very wrong.  So, instead of booting the loader as an ELF file, we
objcopy it into a plain ol' binary image.  This should be safe because (1)
the loader has no relocations left, (2) whatever benefit we lose from not
having the whole ELF file in memory is only temporary until the loader hands
off control to unix.
Finally, we force the entry point to appear at the beginning of the binary
file by moving _start into its own section (.text.init) and using the
mapfile to put that section before everything else.

4 lines changed: 4 ins; 0 del; 0 mod; 22 unchg

Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/uts/armv6/bcm2835/conf/Mapfile

bcm2835: resync unix mapfile with qvpb
The mapfile used by bcm2835's unix was left behind when a bunch of kernel
addresses got changed.  This commit brings it up to date.

14 lines changed: 5 ins; 7 del; 2 mod; 45 unchg

------ ------ ------ ------ ------ --- New Patch Raw usr/src/uts/armv6/bcm2835/conf/Mapfile.loader

bcm2835: we need a loader on this platform as well
As stated before, the Raspberry Pi loader is terrible.  It claims to
supporte ELF file loading, but what it does is crazy.  It loads the ELF file
into memory, gets the start address from the header, converts it into file
offset, adds it to the address where the file was loaded and jumps there.
This is very wrong.  So, instead of booting the loader as an ELF file, we
objcopy it into a plain ol' binary image.  This should be safe because (1)
the loader has no relocations left, (2) whatever benefit we lose from not
having the whole ELF file in memory is only temporary until the loader hands
off control to unix.
Finally, we force the entry point to appear at the beginning of the binary
file by moving _start into its own section (.text.init) and using the
mapfile to put that section before everything else.

44 lines changed: 44 ins; 0 del; 0 mod; 0 unchg

------ ------ ------ ------ ------ --- New Patch Raw usr/src/uts/armv6/bcm2835/loader/Makefile

bcm2835: we need a loader on this platform as well
As stated before, the Raspberry Pi loader is terrible.  It claims to
supporte ELF file loading, but what it does is crazy.  It loads the ELF file
into memory, gets the start address from the header, converts it into file
offset, adds it to the address where the file was loaded and jumps there.
This is very wrong.  So, instead of booting the loader as an ELF file, we
objcopy it into a plain ol' binary image.  This should be safe because (1)
the loader has no relocations left, (2) whatever benefit we lose from not
having the whole ELF file in memory is only temporary until the loader hands
off control to unix.
Finally, we force the entry point to appear at the beginning of the binary
file by moving _start into its own section (.text.init) and using the
mapfile to put that section before everything else.

93 lines changed: 93 ins; 0 del; 0 mod; 0 unchg

------ ------ ------ ------ ------ --- New Patch Raw usr/src/uts/armv6/bcm2835/loader/bcm2835_ldep.c

bcm2835: we need a loader on this platform as well
As stated before, the Raspberry Pi loader is terrible.  It claims to
supporte ELF file loading, but what it does is crazy.  It loads the ELF file
into memory, gets the start address from the header, converts it into file
offset, adds it to the address where the file was loaded and jumps there.
This is very wrong.  So, instead of booting the loader as an ELF file, we
objcopy it into a plain ol' binary image.  This should be safe because (1)
the loader has no relocations left, (2) whatever benefit we lose from not
having the whole ELF file in memory is only temporary until the loader hands
off control to unix.
Finally, we force the entry point to appear at the beginning of the binary
file by moving _start into its own section (.text.init) and using the
mapfile to put that section before everything else.

184 lines changed: 184 ins; 0 del; 0 mod; 0 unchg

Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/uts/armv6/bcm2835/ml/locore.s

bcm2835: remove workaround for u-boot
Since we are not using u-boot, we don't need a work-around for it.
bcm2835: enable access to p10 and p11
When determining whether or not we are running on a supported processor, we
call arm_cpuid_vfpidreg.  This function attempts to get the FPSID which
involves talking to p10.  It however turns out that after a reset only p14
and p15 are accessible.  So, before handing off control to _fakebop_start,
let's enable access to p10 and p11 (privileged mode only).
NOTE: qemu doesn't seem to behave the same - it lets us access p10 & p11
without us doing anything special.

8 lines changed: 1 ins; 2 del; 5 mod; 115 unchg

Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/uts/armv6/bcm2835/unix/Makefile

bcm2835: we need a loader on this platform as well
As stated before, the Raspberry Pi loader is terrible.  It claims to
supporte ELF file loading, but what it does is crazy.  It loads the ELF file
into memory, gets the start address from the header, converts it into file
offset, adds it to the address where the file was loaded and jumps there.
This is very wrong.  So, instead of booting the loader as an ELF file, we
objcopy it into a plain ol' binary image.  This should be safe because (1)
the loader has no relocations left, (2) whatever benefit we lose from not
having the whole ELF file in memory is only temporary until the loader hands
off control to unix.
Finally, we force the entry point to appear at the beginning of the binary
file by moving _start into its own section (.text.init) and using the
mapfile to put that section before everything else.

26 lines changed: 19 ins; 5 del; 2 mod; 124 unchg

Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/uts/armv6/loader/fakeloader.c

loader: pass args along to unix in C
There's no reason why we can't pass the args gotten from the bootloader to
unix in C.
Note: loader's _start sets the ATAG pointer to 0x100.  This change simply
propagates it to unix.

2 lines changed: 1 ins; 0 del; 1 mod; 711 unchg

Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/uts/armv6/loader/fakeloader.h

loader: pass args along to unix in C
There's no reason why we can't pass the args gotten from the bootloader to
unix in C.
Note: loader's _start sets the ATAG pointer to 0x100.  This change simply
propagates it to unix.

2 lines changed: 1 ins; 0 del; 1 mod; 70 unchg

Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/uts/armv6/loader/fakeloader_core.s

loader: pass args along to unix in C
There's no reason why we can't pass the args gotten from the bootloader to
unix in C.
Note: loader's _start sets the ATAG pointer to 0x100.  This change simply
propagates it to unix.
bcm2835: we need a loader on this platform as well
As stated before, the Raspberry Pi loader is terrible.  It claims to
supporte ELF file loading, but what it does is crazy.  It loads the ELF file
into memory, gets the start address from the header, converts it into file
offset, adds it to the address where the file was loaded and jumps there.
This is very wrong.  So, instead of booting the loader as an ELF file, we
objcopy it into a plain ol' binary image.  This should be safe because (1)
the loader has no relocations left, (2) whatever benefit we lose from not
having the whole ELF file in memory is only temporary until the loader hands
off control to unix.
Finally, we force the entry point to appear at the beginning of the binary
file by moving _start into its own section (.text.init) and using the
mapfile to put that section before everything else.

13 lines changed: 9 ins; 2 del; 2 mod; 106 unchg

Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/uts/armv6/os/fakebop.c

fakebop: use a memlist to keep track of physical memory

6 lines changed: 2 ins; 2 del; 2 mod; 922 unchg

This code review page was prepared using /opt/onbld/bin/webrev. Webrev is maintained by the illumos project. The latest version may be obtained here.