Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x
On Thu, Aug 20, 2015 at 08:54:55PM +0100, Russell King - ARM Linux wrote: > On Thu, Aug 20, 2015 at 12:20:10PM -0500, Andy Gross wrote: > > On Thu, Aug 20, 2015 at 02:00:06PM +0100, Russell King - ARM Linux wrote: > > > On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote: > > > > RAM starts at 0x4000 for IPQ. The lower 21MB of RAM is used > > > > for Shared Memory and the kernel can start from 0x4150. > > > > > > Why do people keep creating crap like this? Each time something like > > > this is created, it means that you _need_ to have a special kernel for > > > your platform and you can't be part of the single zImage. > > > > > > Please, rather than creating crap like this, find a better way. > > > > In the case of the IPQ, we don't use the zImage because the decompress > > requires a larger jump than we can do on that platform. Having this > > change at least gets us back 2MB of memory. > > Your argument about "a larger jump" makes no sense what so ever. The > branches between the decompressor and the main kernel are all done > using a mov, which can jump to any 32-bit address. > > Even if you load the compressed kernel image at 0x4150, the > decompressor will mask that with 0xf800, and decide that RAM > starts at 0x4000. It will then want to place the decompressed > kernel image at 0x40008000. Nothing there has anything to do with > jump ranges. With the qcom_defconfig, the kernel gets loaded at 0x40008000. This region is reserved for NSS. > The only restriction that the ARM has as far as jump ranges are > concerned is the 'b' or 'bl' instruction, which in ARM mode is > limited to +/- 32MB. That doesn't apply here since we don't use > that to jump between the decompressor and the decompressed kernel > image. > > So... > > Why is it necessary to have this 21MB block of shared memory at > the start of RAM? Why can't it be reserved by other means higher > up in system memory? The NSS subsystem needs memory to be reserved at 0x4000. The Ubi32 cores (part of NSS) need low address memory close to the Ubi32 address space to do short calls from what is called Ubi32 On Chip Memory to DDR and back again. Since there isn't a way to circumvent this restriction had to reserve at 0x4000. -Varada > It's up to the submitter to justify why any change is required, and > in this case, part of that justification is why the shared memory is > placed at the start of RAM, and why you need to be different from > almost everyone else, and why you need to be a special case. The > justification also must make sense. > > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net. > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x
On Thu, Aug 20, 2015 at 12:20:10PM -0500, Andy Gross wrote: > On Thu, Aug 20, 2015 at 02:00:06PM +0100, Russell King - ARM Linux wrote: > > On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote: > > > RAM starts at 0x4000 for IPQ. The lower 21MB of RAM is used > > > for Shared Memory and the kernel can start from 0x4150. > > > > Why do people keep creating crap like this? Each time something like > > this is created, it means that you _need_ to have a special kernel for > > your platform and you can't be part of the single zImage. > > > > Please, rather than creating crap like this, find a better way. > > In the case of the IPQ, we don't use the zImage because the decompress > requires a larger jump than we can do on that platform. Having this > change at least gets us back 2MB of memory. Your argument about "a larger jump" makes no sense what so ever. The branches between the decompressor and the main kernel are all done using a mov, which can jump to any 32-bit address. Even if you load the compressed kernel image at 0x4150, the decompressor will mask that with 0xf800, and decide that RAM starts at 0x4000. It will then want to place the decompressed kernel image at 0x40008000. Nothing there has anything to do with jump ranges. The only restriction that the ARM has as far as jump ranges are concerned is the 'b' or 'bl' instruction, which in ARM mode is limited to +/- 32MB. That doesn't apply here since we don't use that to jump between the decompressor and the decompressed kernel image. So... Why is it necessary to have this 21MB block of shared memory at the start of RAM? Why can't it be reserved by other means higher up in system memory? It's up to the submitter to justify why any change is required, and in this case, part of that justification is why the shared memory is placed at the start of RAM, and why you need to be different from almost everyone else, and why you need to be a special case. The justification also must make sense. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x
On Thu, Aug 20, 2015 at 02:00:06PM +0100, Russell King - ARM Linux wrote: > On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote: > > RAM starts at 0x4000 for IPQ. The lower 21MB of RAM is used > > for Shared Memory and the kernel can start from 0x4150. > > Why do people keep creating crap like this? Each time something like > this is created, it means that you _need_ to have a special kernel for > your platform and you can't be part of the single zImage. > > Please, rather than creating crap like this, find a better way. In the case of the IPQ, we don't use the zImage because the decompress requires a larger jump than we can do on that platform. Having this change at least gets us back 2MB of memory. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x
On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote: > RAM starts at 0x4000 for IPQ. The lower 21MB of RAM is used > for Shared Memory and the kernel can start from 0x4150. Why do people keep creating crap like this? Each time something like this is created, it means that you _need_ to have a special kernel for your platform and you can't be part of the single zImage. Please, rather than creating crap like this, find a better way. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x
On Thu, Aug 20, 2015 at 02:00:06PM +0100, Russell King - ARM Linux wrote: On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote: RAM starts at 0x4000 for IPQ. The lower 21MB of RAM is used for Shared Memory and the kernel can start from 0x4150. Why do people keep creating crap like this? Each time something like this is created, it means that you _need_ to have a special kernel for your platform and you can't be part of the single zImage. Please, rather than creating crap like this, find a better way. In the case of the IPQ, we don't use the zImage because the decompress requires a larger jump than we can do on that platform. Having this change at least gets us back 2MB of memory. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x
On Thu, Aug 20, 2015 at 08:54:55PM +0100, Russell King - ARM Linux wrote: On Thu, Aug 20, 2015 at 12:20:10PM -0500, Andy Gross wrote: On Thu, Aug 20, 2015 at 02:00:06PM +0100, Russell King - ARM Linux wrote: On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote: RAM starts at 0x4000 for IPQ. The lower 21MB of RAM is used for Shared Memory and the kernel can start from 0x4150. Why do people keep creating crap like this? Each time something like this is created, it means that you _need_ to have a special kernel for your platform and you can't be part of the single zImage. Please, rather than creating crap like this, find a better way. In the case of the IPQ, we don't use the zImage because the decompress requires a larger jump than we can do on that platform. Having this change at least gets us back 2MB of memory. Your argument about a larger jump makes no sense what so ever. The branches between the decompressor and the main kernel are all done using a mov, which can jump to any 32-bit address. Even if you load the compressed kernel image at 0x4150, the decompressor will mask that with 0xf800, and decide that RAM starts at 0x4000. It will then want to place the decompressed kernel image at 0x40008000. Nothing there has anything to do with jump ranges. With the qcom_defconfig, the kernel gets loaded at 0x40008000. This region is reserved for NSS. The only restriction that the ARM has as far as jump ranges are concerned is the 'b' or 'bl' instruction, which in ARM mode is limited to +/- 32MB. That doesn't apply here since we don't use that to jump between the decompressor and the decompressed kernel image. So... Why is it necessary to have this 21MB block of shared memory at the start of RAM? Why can't it be reserved by other means higher up in system memory? The NSS subsystem needs memory to be reserved at 0x4000. The Ubi32 cores (part of NSS) need low address memory close to the Ubi32 address space to do short calls from what is called Ubi32 On Chip Memory to DDR and back again. Since there isn't a way to circumvent this restriction had to reserve at 0x4000. -Varada It's up to the submitter to justify why any change is required, and in this case, part of that justification is why the shared memory is placed at the start of RAM, and why you need to be different from almost everyone else, and why you need to be a special case. The justification also must make sense. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x
On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote: RAM starts at 0x4000 for IPQ. The lower 21MB of RAM is used for Shared Memory and the kernel can start from 0x4150. Why do people keep creating crap like this? Each time something like this is created, it means that you _need_ to have a special kernel for your platform and you can't be part of the single zImage. Please, rather than creating crap like this, find a better way. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x
On Thu, Aug 20, 2015 at 12:20:10PM -0500, Andy Gross wrote: On Thu, Aug 20, 2015 at 02:00:06PM +0100, Russell King - ARM Linux wrote: On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote: RAM starts at 0x4000 for IPQ. The lower 21MB of RAM is used for Shared Memory and the kernel can start from 0x4150. Why do people keep creating crap like this? Each time something like this is created, it means that you _need_ to have a special kernel for your platform and you can't be part of the single zImage. Please, rather than creating crap like this, find a better way. In the case of the IPQ, we don't use the zImage because the decompress requires a larger jump than we can do on that platform. Having this change at least gets us back 2MB of memory. Your argument about a larger jump makes no sense what so ever. The branches between the decompressor and the main kernel are all done using a mov, which can jump to any 32-bit address. Even if you load the compressed kernel image at 0x4150, the decompressor will mask that with 0xf800, and decide that RAM starts at 0x4000. It will then want to place the decompressed kernel image at 0x40008000. Nothing there has anything to do with jump ranges. The only restriction that the ARM has as far as jump ranges are concerned is the 'b' or 'bl' instruction, which in ARM mode is limited to +/- 32MB. That doesn't apply here since we don't use that to jump between the decompressor and the decompressed kernel image. So... Why is it necessary to have this 21MB block of shared memory at the start of RAM? Why can't it be reserved by other means higher up in system memory? It's up to the submitter to justify why any change is required, and in this case, part of that justification is why the shared memory is placed at the start of RAM, and why you need to be different from almost everyone else, and why you need to be a special case. The justification also must make sense. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
