Prepared by: | (jeffpc) on 2015-Jan-25 13:29 -0500 EST |
---|---|
Workspace: | /home/jeffpc/illumos/arm/illumos-gate (at d4b7000978c1) |
Compare against: | orcz/arm (ssh://jsipek@repo.or.cz/srv/git/illumos-gate/jeffpc.git at cf9f2a96e287) |
Summary of changes: | 412 lines changed: 375 ins; 18 del; 19 mod; 3538 unchg |
Patch of changes: | 2015-01-25.patch |
Printable review: | 2015-01-25.pdf |
Cdiffs Udiffs Wdiffs Sdiffs Frames Old New Patch Raw usr/src/Makefile.master
we should be using the arm cross-linker1 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 memory6 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 memory6 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.