Greetings.
It has recently come to my mind to begin working on an updated firmware
for my employer's CCTV/DVR boxes, which are based around the Hi3520 line
of arm SoC.
In the process of learning which files I need to edit in order to
integrate my changes into the linux build system, I've come to find that
arch/arm/mach-hisi/{Kconfig,Makefile} covers no less than four different
chips from Hisilicon, and that seems to make it a bit awkward to insert
a whole new arch/arm/mach- directory for one single SoC and create
duplicate menuitems for Hisilicon.
So, I'm wondering whereabouts I should place the data for the chips that
I am working on, for the sake of organization and whatnot.
Also, I've been having difficulty getting a response from Hisilicon
regarding my request for source code for this and a few other of their
chips running in our other, newer DVRs, even though a cursory
examination after accessing the devices via telnet shows they do in fact
run a busybox/linux/uClibc based system, with a number of GPL licensed
libraries and kernel modules.
Regards,
Marty
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160826/222521ef/attachment.sig>
From: Jason Cooper <hidden> Date: 2016-08-27 15:04:57
Hi Marty,
+ Arnd, GregKH,
On Fri, Aug 26, 2016 at 07:48:06PM -0500, Marty Plummer wrote:
It has recently come to my mind to begin working on an updated firmware
for my employer's CCTV/DVR boxes, which are based around the Hi3520 line
of arm SoC.
Ah, yes. The same device we were discussing on #mvlinux?
In the process of learning which files I need to edit in order to
integrate my changes into the linux build system, I've come to find that
arch/arm/mach-hisi/{Kconfig,Makefile} covers no less than four different
chips from Hisilicon, and that seems to make it a bit awkward to insert
a whole new arch/arm/mach- directory for one single SoC and create
duplicate menuitems for Hisilicon.
Note that I have no experience with HiSilicon. :-) However, I think
it's correct to add it mach-hisi/. A quick grep shows that there is
devicetree support for hisilicon SoCs (arch/arm/boot/dts/). So that
means there's a *lot* less code to add under mach-hisi/.
So, I'm wondering whereabouts I should place the data for the chips that
I am working on, for the sake of organization and whatnot.
Ideally, most of it will be a devicetree. Assuming we have code for the
SoC and associated drivers.
Also, I've been having difficulty getting a response from Hisilicon
regarding my request for source code for this and a few other of their
chips running in our other, newer DVRs, even though a cursory
examination after accessing the devices via telnet shows they do in fact
run a busybox/linux/uClibc based system, with a number of GPL licensed
libraries and kernel modules.
I've added GregKH to the Cc to see if he knows of anyone currently
working with Hisilicon.
thx,
Jason.
Ah, yes. The same device we were discussing on #mvlinux?
Indeed, the very same
Note that I have no experience with HiSilicon. :-) However, I think
it's correct to add it mach-hisi/. A quick grep shows that there is
devicetree support for hisilicon SoCs (arch/arm/boot/dts/). So that
means there's a *lot* less code to add under mach-hisi/.
The issue here is that mach-hisi/Kconfig and CONFIG_ARCH_HISI require
ARMv7, whereas the hi3520 has an arm1176/arm926 core, thereby being
ARMv6/v5
Ideally, most of it will be a devicetree. Assuming we have code for the
SoC and associated drivers.
Yes, I've been doing some work on that already, but as I've said, unsure
where one should/would insert all these different things.
I've added GregKH to the Cc to see if he knows of anyone currently
working with Hisilicon.
Thanks, mayhaps someone can get even a response from Hisilicon, as I've
yet to recieve even that.
On Saturday, August 27, 2016 1:53:25 PM CEST Marty Plummer wrote:
On 08/27/2016 10:04 AM, Jason Cooper wrote:
quoted
Ah, yes. The same device we were discussing on #mvlinux?
Indeed, the very same
quoted
Note that I have no experience with HiSilicon. :-) However, I think
it's correct to add it mach-hisi/. A quick grep shows that there is
devicetree support for hisilicon SoCs (arch/arm/boot/dts/). So that
means there's a *lot* less code to add under mach-hisi/.
The issue here is that mach-hisi/Kconfig and CONFIG_ARCH_HISI require
ARMv7, whereas the hi3520 has an arm1176/arm926 core, thereby being
ARMv6/v5
No problem, just modify the dependency list for the top-level option.
quoted
Ideally, most of it will be a devicetree. Assuming we have code for the
SoC and associated drivers.
Yes, I've been doing some work on that already, but as I've said, unsure
where one should/would insert all these different things.
start with getting the serial console working. debug_ll is useful for
early bringup and should only need a patch to arch/arm/Kconfig.debug.
Later you would typically use earlycon (using a stdout-path property
in DT to point to the UART and configuration). The approximate order
in which you need other drivers is:
* drivers/irqchip (often a standard VIC or GIC)
* drivers/clocksource
* drivers/tty/serial/
* drivers/clk
* drivers/pinctrl (or drivers/gpio for simpler I/O pins)
* drivers/mmc
* drivers/net/ethernet
* drivers/spi/
* drivers/i2c/
* drivers/mtd/
In each case, look for a driver that works on your hardware first,
or create one based on the old source if that doesn't exist upstream.
quoted
I've added GregKH to the Cc to see if he knows of anyone currently
working with Hisilicon.
Thanks, mayhaps someone can get even a response from Hisilicon, as I've
yet to recieve even that.
I expect that Xu Wei will pick up the patches once they are ready to
go in, but he probably won't have a lot of comments for your patches.
Arnd
From: Jason Cooper <hidden> Date: 2016-08-29 15:46:14
On Mon, Aug 29, 2016 at 12:54:15PM +0200, Arnd Bergmann wrote:
On Saturday, August 27, 2016 1:53:25 PM CEST Marty Plummer wrote:
quoted
On 08/27/2016 10:04 AM, Jason Cooper wrote:
...
quoted
quoted
Ideally, most of it will be a devicetree. Assuming we have code for the
SoC and associated drivers.
Yes, I've been doing some work on that already, but as I've said, unsure
where one should/would insert all these different things.
start with getting the serial console working. debug_ll is useful for
early bringup and should only need a patch to arch/arm/Kconfig.debug.
It looks like the other hisi board we have in the tree uses arm,pl011
for the serial ports. Sometimes, a vendor will stick with an IP block
across multiple SoCs. It's worth trying a minimal mainline kernel with
a minimal dts file and the serial node. If that works, then everything
else is a lot easier. :-)
Since you stated on irc that you have some form of documentation, then
that should go a long way towards mapping uart0 to a register address.
Later you would typically use earlycon (using a stdout-path property
in DT to point to the UART and configuration). The approximate order
in which you need other drivers is:
* drivers/irqchip (often a standard VIC or GIC)
the hip04 is heavily based on the ARM GIC, which just about everyone
uses. You may get lucky here. You're working with an older SoC, so
they might've just used the stock GIC and only branched out later. Or,
worst case, they started with some in-house one-off and the hip04 is them
working towards using a vanilla GIC.
The rest we can worry about later.
thx,
Jason.
Hi Arnd, Marty
On 29/08/2016 11:54, Arnd Bergmann wrote:
On Saturday, August 27, 2016 1:53:25 PM CEST Marty Plummer wrote:
quoted
On 08/27/2016 10:04 AM, Jason Cooper wrote:
quoted
Ah, yes. The same device we were discussing on #mvlinux?
Indeed, the very same
quoted
Note that I have no experience with HiSilicon. :-) However, I think
it's correct to add it mach-hisi/. A quick grep shows that there is
devicetree support for hisilicon SoCs (arch/arm/boot/dts/). So that
means there's a *lot* less code to add under mach-hisi/.
The issue here is that mach-hisi/Kconfig and CONFIG_ARCH_HISI require
ARMv7, whereas the hi3520 has an arm1176/arm926 core, thereby being
ARMv6/v5
No problem, just modify the dependency list for the top-level option.
quoted
quoted
Ideally, most of it will be a devicetree. Assuming we have code for the
SoC and associated drivers.
Yes, I've been doing some work on that already, but as I've said, unsure
where one should/would insert all these different things.
start with getting the serial console working. debug_ll is useful for
early bringup and should only need a patch to arch/arm/Kconfig.debug.
Later you would typically use earlycon (using a stdout-path property
in DT to point to the UART and configuration). The approximate order
in which you need other drivers is:
* drivers/irqchip (often a standard VIC or GIC)
* drivers/clocksource
* drivers/tty/serial/
* drivers/clk
* drivers/pinctrl (or drivers/gpio for simpler I/O pins)
* drivers/mmc
* drivers/net/ethernet
* drivers/spi/
* drivers/i2c/
* drivers/mtd/
In each case, look for a driver that works on your hardware first,
or create one based on the old source if that doesn't exist upstream.
quoted
quoted
I've added GregKH to the Cc to see if he knows of anyone currently
working with Hisilicon.
Thanks, mayhaps someone can get even a response from Hisilicon, as I've
yet to recieve even that.
I expect that Xu Wei will pick up the patches once they are ready to
go in, but he probably won't have a lot of comments for your patches.
I will once they are ready.
Thanks for your kindly guiding!
Best Regards,
Wei
Hi Arnd, Marty
I will once they are ready.
Thanks for your kindly guiding!
Best Regards,
Wei
Hi Wei,
Do you think you could change the references to the Hi3620 in the code
and dts files from `hi3xxx' to `hi3620'? As it currently stands, the
wildcard matches hi3520 too, but that's not a good idea whit devicetree,
its best to be completely explicit as to which sort of device the
binding is for.
Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160830/ded6f6e0/attachment.sig>
From: Jason Cooper <hidden> Date: 2016-08-30 14:58:43
On Tue, Aug 30, 2016 at 09:43:52AM -0500, Marty Plummer wrote:
Hi Wei,
Do you think you could change the references to the Hi3620 in the code
and dts files from `hi3xxx' to `hi3620'? As it currently stands, the
wildcard matches hi3520 too, but that's not a good idea whit devicetree,
its best to be completely explicit as to which sort of device the
binding is for.
Please submit a patch, there shouldn't be wildcards in devicetree
compatible strings. :-/
thx,
Jason.
Hi Marty,
On 30/08/2016 15:43, Marty Plummer wrote:
On 08/30/2016 03:55 AM, Wei Xu wrote:
quoted
Hi Arnd, Marty
I will once they are ready.
Thanks for your kindly guiding!
Best Regards,
Wei
Hi Wei,
Do you think you could change the references to the Hi3620 in the code
and dts files from `hi3xxx' to `hi3620'? As it currently stands, the
wildcard matches hi3520 too, but that's not a good idea whit devicetree,
its best to be completely explicit as to which sort of device the
binding is for.
Yes, originally it also stands for hi3519 and please send the patch to me.
Please do not add a new DT_MACHINE entry if we could use the general one.
Thanks?
Best Regards,
Wei
On Tue, Aug 30, 2016 at 09:43:52AM -0500, Marty Plummer wrote:
quoted
Hi Wei,
Do you think you could change the references to the Hi3620 in the code
and dts files from `hi3xxx' to `hi3620'? As it currently stands, the
wildcard matches hi3520 too, but that's not a good idea whit devicetree,
its best to be completely explicit as to which sort of device the
binding is for.
Please submit a patch, there shouldn't be wildcards in devicetree
compatible strings. :-/
Fortunately, I don't see wildcards in the dts files, I think we were
careful enough here. The Linux-internal identifiers and file names
are easily renamed, unlike the DT bindings.
Arnd