Done in https://svnweb.freebsd.org/base?view=revision&revision=296080
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 26 2016
Addressed review comments.
I decided to drop sys/boot/common/self_reloc.c changes, as currently self relocation is not supported by the MIPS ubldr.
The actual MIPS ubldr support will come with D5313.
Thanks for the reviews. I've responded to some of the comments and will take care of them and submit a new version.
Feb 25 2016
I'm unclear how this supports 64-bit mips. Perhaps a quick note about what I'm missing would be in order?
Feb 17 2016
Cleaned up some leftover issues.
I am not sure whether more reviewers are required?
Will resubmit in a different revision.
Feb 11 2016
Feb 10 2016
Ok, I'll test/commit this one first, as i think it's a pre-requisite for the future patches.
Patch updated.
Patch updated.
Patch updated to use sys/sys/intr.h for the common parts between ARM and MIPS.
Also, FDT-related headers are now conditionally included in order to allow MIPS systems that do not support FDT to move to INTRNG should they wish to.
Feb 9 2016
Feb 8 2016
Feb 7 2016
ok, so how about we (read: me) split out the arm intrng definitions into sys/sys/ and then you can update your patch.
cool! ok, committing this now.
Feb 4 2016
Diff updated.
Renamed sys/mips/mips/intr.c to sys/mips/mips/mips_pic.c per Alexander Kabaev's request (sorry, I must have misunderstood what you meant originally).
I wasn't quite clear, my apologies. I still want to have mips_pic.c, not intr.c in the source. I only wanted intr.c IFF you were to decide to move cpu_establish_hard_intr and friends into a separate file and make them with arbitrary root PICm only then I called for the intr.c file. In other words, rename your intr.c to mips_pic.c for now.
I've updated the patch, addressing kan's comments. I'll send out a separate review for enabling bus pass on MIPS (together with enabling it for the mips_pic (intr.c) tomorrow. I'll also update the bus_space_fdt removal patch tomorrow.
I do not see mips_pic.c in this patch, which is supposed to the the generic MIPS32 intr controller and is the place where cpu_establish_hard_intr for INTRNG is implemented. If you do not need rest of the mips_pic.c, consider moving these into an independent implementation file (mips/mips/intr.c?). You will need to export the root PIC pointer from MI intr code for that and that is the reason why I kept function in the file that implements root PIC on my SOC.
Feb 3 2016
I will fix this in LLDB. Thanks Warner!
In D5171#110109, @imp wrote:Also, the LLVM parser is wrong.
case llvm::ELF::EF_MIPS_ARCH_3: case llvm::ELF::EF_MIPS_ARCH_4: case llvm::ELF::EF_MIPS_ARCH_5: case llvm::ELF::EF_MIPS_ARCH_64: return (endian == ELFDATA2LSB) ? ArchSpec::eMIPSSubType_mips64el : ArchSpec::eMIPSSubType_mips64;This is incorrect. These arch (at least the first two) are both 32-bit and 64-bit. You know what arch you are executing based on the e_ident[EI_CLASS} telling you 32 vs 64 bit.
32-bit mips FreeBSD binaries are MIPS-3. And that's correct. And LLVM doesn't grok that. So the LLVM parser also needs work.
In D5171#110106, @imp wrote:I don't like this interface. The CPU specific eflags aren't a property of the CPU, but rather are a property of how the binary was compiled. These should be in the header for the binary being executed, which is completely ignored. On arm, there's at least two flavors we support executing today. On mips we support 3 different binary ABIs. And we wish to support more flavors of those ABIs (soft-float, hard-float, cheri) and you can't know based on the kernel which one of these you are running.
Also, the LLVM parser is wrong.
I don't like this interface. The CPU specific eflags aren't a property of the CPU, but rather are a property of how the binary was compiled. These should be in the header for the binary being executed, which is completely ignored. On arm, there's at least two flavors we support executing today. On mips we support 3 different binary ABIs. And we wish to support more flavors of those ABIs (soft-float, hard-float, cheri) and you can't know based on the kernel which one of these you are running.
Feb 2 2016
I meant to talk to you about possibly moving the Atheros SoCs to MIPS24K, but then got distracted with other things :-)
Yeah, I guess we can move the SoCs later. I did that for the Ralink SoCs in sys/mips/ralink for now, will be using the new cpu options with the Ralink/Mediatek FDT stuff too.
This fine by me; it reminds me that we never started using the mips24k pieces for those atheros SoC cores (all the ar71xx, ar91xx, ar933x, etc) that are actually mips24k. They're mips4k.
Jan 27 2016
After discussion with imp@, removed the CPU_MIPS24KE option, as 24KE is not really different than 24K, apart from having DSP ASE, which can be detected dynamically via Config3 register.
After discussion with imp@, removed the CPU_MIPS24KE option, as 24KE is not really different than 24K, apart from having DSP ASE, which can be detected dynamically via Config3 register.
After discussion with imp@, removed the CPU_MIPS24KE option, as 24KE is not really different than 24K, apart from having DSP ASE, which can be detected dynamically via Config3 register.
Jan 26 2016
Backed out the sys/mips/include/asm.h change as it is probably too risky at the moment.
Oct 18 2015
Abandon in favor of fix in qemu. Changing ABI is too heavy-handed.
Oct 10 2015
Updates diff to remove hdwr value fixup
Oct 9 2015
Fine with me, make sure to include Relnotes: YES and comment on ABI concerns in the commit message.
This fixes my ability to use unmodified qemu-user code to build mips/mips64 packages.
The alternative approach of fixing sysarch(GET/SET_TLS) in qemu-bsd-user might be called for, pending confirmation from sbruno.
Our kernel does unnatural things in rdhwr emulation codem qemu-user might have to follow.
Jul 29 2015
Committed at svn r286040
Jul 27 2015
Regenerating diff from top of /usr/src. Sorry for the noise.
Ok, I had no interest in the function just ran into the build error while investigating unrelated problems on a device. Removed per review.
The changes to pads() for 64-bit processors aren't quite right. In particular, the second access to segtab[] isn't correct. The changes should look more like what you see in the DDB function just above pads().
Trying to incorporate feedback. I don't understand the pads changes, nor am I sure if all the ifdef I added is necessary.
Jul 26 2015
How about I don't put the rest of my tree in this review.
Drop casts to (void *)
Note that the warning says "argument 3", which is the pv_va parameter, not "argument 2", which is the pmap parameter. Remove the (void *) from before the pmap parameter.