Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Sricharan, On 15/05/13 08:11, Sricharan R wrote: Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Yes, you are right in respect to fluent software integration and consistency with current implementation. My only concern is that from architectural point of view the SCRM, although related to the PRCM, is a separate module (described correspondingly as such in the TRM). If we go this way, the SCRM regs shall have to be referenced via the prcm pointer: (*prcm)-x, and this might be confusing. I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) to the prcm_regs declaration in omap_common.h, and the required init to the appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h, start with a scrm_ prefix. Alternatively, a new scrm_regs struct could be declared in omap_common.h, along with the appropriate pointers, and the
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi, On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: Hi Sricharan, On 15/05/13 08:11, Sricharan R wrote: Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Yes, you are right in respect to fluent software integration and consistency with current implementation. My only concern is that from architectural point of view the SCRM, although related to the PRCM, is a separate module (described correspondingly as such in the TRM). If we go this way, the SCRM regs shall have to be referenced via the prcm pointer: (*prcm)-x, and this might be confusing. I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) to the prcm_regs declaration in omap_common.h, and the required init to the appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h, start with a scrm_ prefix. Alternatively, a new scrm_regs struct could be
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Sricharan, On 15/05/13 12:04, Sricharan R wrote: Hi, On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: Hi Sricharan, On 15/05/13 08:11, Sricharan R wrote: Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] +* TODO: Replace this ugly hardcoding with proper defines + */ +writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Yes, you are right in respect to fluent software integration and consistency with current implementation. My only concern is that from architectural point of view the SCRM, although related to the PRCM, is a separate module (described correspondingly as such in the TRM). If we go this way, the SCRM regs shall have to be referenced via the prcm pointer: (*prcm)-x, and this might be confusing. I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) to the prcm_regs declaration in omap_common.h, and the required init to the appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h,
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
On Wednesday 15 May 2013 04:16 PM, Lubomir Popov wrote: Hi Sricharan, On 15/05/13 12:04, Sricharan R wrote: Hi, On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: Hi Sricharan, On 15/05/13 08:11, Sricharan R wrote: Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Yes, you are right in respect to fluent software integration and consistency with current implementation. My only concern is that from architectural point of view the SCRM, although related to the PRCM, is a separate module (described correspondingly as such in the TRM). If we go this way, the SCRM regs shall have to be referenced via the prcm pointer: (*prcm)-x, and this might be confusing. I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) to the prcm_regs declaration in omap_common.h, and the required init to the appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved clarity the SCRM
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Sricharan, Tom, On 15/05/13 14:25, Sricharan R wrote: On Wednesday 15 May 2013 04:16 PM, Lubomir Popov wrote: Hi Sricharan, On 15/05/13 12:04, Sricharan R wrote: Hi, On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: Hi Sricharan, On 15/05/13 08:11, Sricharan R wrote: Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Yes, you are right in respect to fluent software integration and consistency with current implementation. My only concern is that from architectural point of view the SCRM, although related to the PRCM, is a separate module (described correspondingly as such in the TRM). If we go this way, the SCRM regs shall have to be referenced via the prcm pointer: (*prcm)-x, and this might be confusing. I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) to the prcm_regs declaration in omap_common.h, and the required init to the appropriate omap5_esx_prcm in
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
On Wed, May 15, 2013 at 04:10:46PM +0300, Lubomir Popov wrote: Hi Sricharan, Tom, [snip] Now on USB in general: u-boot-ti master lags behind mainline master in respect to drivers/usb/host/ehci-hcd.c (the other TI-specific files are OK). My old .../patch/232742 applies to u-boot-ti correctly. Should we keep it (and then Tom does the merge of ehci-hcd.c), or I rebase on mainline with a V2? Tom? The patch still git am's fine on master (just checked), so it's OK as-is. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
OK, thanks. On 15/05/13 16:43, Tom Rini wrote: On Wed, May 15, 2013 at 04:10:46PM +0300, Lubomir Popov wrote: Hi Sricharan, Tom, [snip] Now on USB in general: u-boot-ti master lags behind mainline master in respect to drivers/usb/host/ehci-hcd.c (the other TI-specific files are OK). My old .../patch/232742 applies to u-boot-ti correctly. Should we keep it (and then Tom does the merge of ehci-hcd.c), or I rebase on mainline with a V2? Tom? The patch still git am's fine on master (just checked), so it's OK as-is. Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. Please see some more comments inline below. On 13/05/13 22:37, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/26/2013 11:59 AM, Lubomir Popov wrote: Hi Tom, On 25/04/13 22:01, Tom Rini wrote: On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote: Signed-off-by: Lubomir Popov lpo...@mm-sol.com Thought I had reviewed this already, sorry. Thanks for your review. During the past month U-Boot has changed; I have tried to follow as well (although I'm engaged with other stuff) and some of your remarks have been already fixed. Please see my comments inline below. Anyway, I guess that a V2 patch shall have to be referenced against the current master. Or against u-boot-ti/next? OK, sorry for the late reply again. Now that u-boot-arm has resynced with master, I've also resynced and gotten a pull done. You can use either u-boot-arm/master or u-boot-ti/master. Please note that for this board to work with the defined configuration, the following patches are also required (unfortunately some are already quite old and might cause conflicts): - Power: http://patchwork.ozlabs.org/patch/232732/. Potential conflict with Nishanth Menon's series of March 26, applied to u-boot-ti/next. - For I2C support: * The patch series of Apr. 8 that enables I2C4 and I2C5 (applied to u-boot-ti/next; affects all OMAP5 boards). * The modified i2c driver: http://patchwork.ozlabs.org/patch/233823/ (useful for all OMAP3/4/5 boards). - For USB support: * http://patchwork.ozlabs.org/patch/235684/ (affects all OMAP5 boards) * http://patchwork.ozlabs.org/patch/232742/ (affects all OMAP5 boards) OK. Please make sure these still apply and if not update and re-send. I think I've already grabbed a few of these. [snip] +#define USB_HOST_HS_CLKCTRL_MASK 0x0100D7C0 /* CM_L3INIT_USB_HOST_HS_CLKCTRL */ +#define USB_TLL_HS_CLKCTRL_MASK0x0700 /* CM_L3INIT_USB_TLL_HS_CLKCTRL */ Some header please. Currently moved to board header. I wondered if a common OMAP header wouldn't be more suitable, but having in mind that the utilized USB ports (and thus the clocks that should be enabled) vary from board to board, perhaps this (i.e. board header) is the best place. The masks won't change tho, yes? Common header somewhere. These are in fact not masks, but enable bits (sort of confusing terminology found throughout TI headers). Now renamed to ..._CLKCTRL_EN; staying in board header. + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. [snip] Ah, since you do have this part already, just update the rest as I had said. /* Machine type for Linux */ #ifndef MACH_TYPE_SOM5_EVB #define MACH_TYPE_SOM5_EVB 4545 #endif #define CONFIG_MACH_TYPE MACH_TYPE_SOM5_EVB Is this OK? I think we'd decided in general to not do ifndef and just always define it. +/* Enable all clocks: */ +/*#define CONFIG_SYS_CLOCKS_ENABLE_ALL*/ + +#define CONFIG_SYS_ENABLE_PADS_ALL /* Enable all PADS for now */ Not allowed. Shall see to it. What if one needs to test pins and connections during board bring-up, e.g. via gpio commands? Then code in what you need at the time, drop later. [snip] This is a little un-clear. If MMC will be in mmc like the uEVM, just do so, and if no storage of env, leave it as NOWHERE. Cerrently looks like this: /* MMC ENV related defines */ #undef CONFIG_ENV_IS_IN_MMC #undef CONFIG_SYS_MMC_ENV_DEV #undef CONFIG_ENV_OFFSET #define CONFIG_ENV_IS_NOWHERE Shouldn't need that now, omap5_common is common and the env bits got moved to omap5_uevm.h [snip] +/* + * memtest setup +
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Otherwise (a struct in omap_common.h) we shall need new scrm-regs.c files for every OMAP flavor. Which way to go? Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Tom, Just a couple of things to clarify below. On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. OK, shall do it. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. Just to avoid confusion: I applied it and tested on a locally cloned version of u-boot-ti, not upstream (don't laugh please; just want to clarify for those who don't know that it is your job). [snip] Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. Who is starting off, me or you? ;) -- Tom BR, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/14/2013 03:42 PM, Lubomir Popov wrote: Hi Tom, Just a couple of things to clarify below. On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. OK, shall do it. Thanks! [snip] [snip] Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. Who is starting off, me or you? ;) Since your series needs it (so we aren't writing to magic locations which isn't allowed), you please. Thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkqBgAAoJENk4IS6UOR1WFVcQAIo9DgrABUaAwOTfYFXVlGQ6 /MFyQvtwFYtEwW1xtDZ8RWuv1zGI26IIw4XH+xhspj50w7ma9lji575U/tyQCtrN G6xMW8bH/8Cxj+kFUcgeNXSqAF0OLOz8Rvow9dSW2RpnOu3yOPKnvgxjV974x595 IfBK26Xo5ldR6qX12EIwAfHZVRow97Kk25LOBoqR+qxTBrtKPWzywXyvTi94qY/b jcy9L17AQQvNWQofps7noDsFM+acWlQxsTkjbdkynDu8gIQC0JZ8cEUPZ9XsYg+D 8SvXeY5ntCEOwxvB2TZ2GNC9/J5fVXMmewrexH1AdjsO1d0529ZjCX0995whV2pJ xCYi0FAtXKW0fm1gitMXZ0J/pHzNdsr1s+rV0iUtppbhh9mQ+NQplXVPevB0UrWH 1UHHxe1Hsc5ZJHJRvvFyVAo9ySdZ85zrS6+TlMwfjK1LWtQmPJ0DA1Cddz8m/BI+ 6ebQ36qgJuO990YhQ9GlfOV1rjp3RhrCmb+JKwjMN0OahnfAEvp4osCvbMClDXqT VL83+gP1lKJ47B2VfuyqXW+ETBV6hhLprItj8wx+0sJx0rNKc98Q61pO8XSPZwoE 8hWzqeY7Dmlp2QxQ3ZyD5w5+DECGbj7ihCICkjquwHSB5v1R4R1XIwlV/3cd/Mm4 SMnFtv8rUQsfzi48bGt4 =lJAv -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/26/2013 11:59 AM, Lubomir Popov wrote: Hi Tom, On 25/04/13 22:01, Tom Rini wrote: On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote: Signed-off-by: Lubomir Popov lpo...@mm-sol.com Thought I had reviewed this already, sorry. Thanks for your review. During the past month U-Boot has changed; I have tried to follow as well (although I'm engaged with other stuff) and some of your remarks have been already fixed. Please see my comments inline below. Anyway, I guess that a V2 patch shall have to be referenced against the current master. Or against u-boot-ti/next? OK, sorry for the late reply again. Now that u-boot-arm has resynced with master, I've also resynced and gotten a pull done. You can use either u-boot-arm/master or u-boot-ti/master. Please note that for this board to work with the defined configuration, the following patches are also required (unfortunately some are already quite old and might cause conflicts): - Power: http://patchwork.ozlabs.org/patch/232732/. Potential conflict with Nishanth Menon's series of March 26, applied to u-boot-ti/next. - For I2C support: * The patch series of Apr. 8 that enables I2C4 and I2C5 (applied to u-boot-ti/next; affects all OMAP5 boards). * The modified i2c driver: http://patchwork.ozlabs.org/patch/233823/ (useful for all OMAP3/4/5 boards). - For USB support: * http://patchwork.ozlabs.org/patch/235684/ (affects all OMAP5 boards) * http://patchwork.ozlabs.org/patch/232742/ (affects all OMAP5 boards) OK. Please make sure these still apply and if not update and re-send. I think I've already grabbed a few of these. [snip] +#define USB_HOST_HS_CLKCTRL_MASK 0x0100D7C0 /* CM_L3INIT_USB_HOST_HS_CLKCTRL */ +#define USB_TLL_HS_CLKCTRL_MASK 0x0700 /* CM_L3INIT_USB_TLL_HS_CLKCTRL */ Some header please. Currently moved to board header. I wondered if a common OMAP header wouldn't be more suitable, but having in mind that the utilized USB ports (and thus the clocks that should be enabled) vary from board to board, perhaps this (i.e. board header) is the best place. The masks won't change tho, yes? Common header somewhere. +* TODO: Replace this ugly hardcoding with proper defines + */ +writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. [snip] Ah, since you do have this part already, just update the rest as I had said. /* Machine type for Linux */ #ifndef MACH_TYPE_SOM5_EVB #define MACH_TYPE_SOM5_EVB4545 #endif #define CONFIG_MACH_TYPE MACH_TYPE_SOM5_EVB Is this OK? I think we'd decided in general to not do ifndef and just always define it. +/* Enable all clocks: */ +/*#define CONFIG_SYS_CLOCKS_ENABLE_ALL*/ + +#define CONFIG_SYS_ENABLE_PADS_ALL /* Enable all PADS for now */ Not allowed. Shall see to it. What if one needs to test pins and connections during board bring-up, e.g. via gpio commands? Then code in what you need at the time, drop later. [snip] This is a little un-clear. If MMC will be in mmc like the uEVM, just do so, and if no storage of env, leave it as NOWHERE. Cerrently looks like this: /* MMC ENV related defines */ #undef CONFIG_ENV_IS_IN_MMC #undef CONFIG_SYS_MMC_ENV_DEV #undef CONFIG_ENV_OFFSET #define CONFIG_ENV_IS_NOWHERE Shouldn't need that now, omap5_common is common and the env bits got moved to omap5_uevm.h [snip] +/* + * memtest setup + */ +#define CONFIG_SYS_MEMTEST_START 0xb800 +#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + (256 20)) +/* Undef following two for simple mtest */ +#define CONFIG_SYS_ALT_MEMTEST +#define CONFIG_SYS_MEMTEST_SCRATCH 0x8100 Please see doc/README.memory-test and update as mtest is no longer a default command. Now the config tail looks like this: /* Undef/remove after bring-up: */ #define CONFIG_CMD_MEMTEST /* Disabled commands */ #undef CONFIG_CMD_SAVEENV /* Prompt */ #define CONFIG_SYS_PROMPTSOM5_EVB # #ifdef CONFIG_CMD_MEMTEST /* Undef following two for simple mtest */ #define CONFIG_SYS_ALT_MEMTEST #define CONFIG_SYS_MEMTEST_SCRATCH0xb7f0 #ifdef CONFIG_SYS_ALT_MEMTEST #undef CONFIG_SYS_MEMTEST_START #define CONFIG_SYS_MEMTEST_START 0xb800 #undef CONFIG_SYS_MEMTEST_END #define CONFIG_SYS_MEMTEST_END(CONFIG_SYS_MEMTEST_START + (256 20)) #endif #endif /* CONFIG_CMD_MEMTEST */ OK. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkUEQAAoJENk4IS6UOR1WtscP/0RApAXEgttNem+eho1kFJMZ FSi3UgiO0+XqGbETTyYuG/r6RTz9grDcbtSs9np6/9H3wrc2FjCtlqXygJmQgbmr
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Tom,
On 25/04/13 22:01, Tom Rini wrote:
On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote:
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
Thought I had reviewed this already, sorry.
Thanks for your review. During the past month U-Boot has changed; I have tried
to
follow as well (although I'm engaged with other stuff) and some of your remarks
have been already fixed. Please see my comments inline below.
Anyway, I guess that a V2 patch shall have to be referenced against the current
master.
Or against u-boot-ti/next?
Please note that for this board to work with the defined configuration, the
following
patches are also required (unfortunately some are already quite old and might
cause
conflicts):
- Power: http://patchwork.ozlabs.org/patch/232732/. Potential conflict with
Nishanth
Menon's series of March 26, applied to u-boot-ti/next.
- For I2C support:
* The patch series of Apr. 8 that enables I2C4 and I2C5 (applied to
u-boot-ti/next;
affects all OMAP5 boards).
* The modified i2c driver: http://patchwork.ozlabs.org/patch/233823/ (useful
for all
OMAP3/4/5 boards).
- For USB support:
* http://patchwork.ozlabs.org/patch/235684/ (affects all OMAP5 boards)
* http://patchwork.ozlabs.org/patch/232742/ (affects all OMAP5 boards)
---
The som5_evb is an evaluation board for the APM-5 - a OMAP5430-based SOM
(system
On a Module) designed by MMS and manufactured under license by Jorjin
Technologies.
Above the '---' so it's in the changelog.
OK, sure, my fault
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/include/asm/mach-types.h
index a676b6d..236fa17 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type;
#define MACH_TYPE_OMAP5_SEVM 3777
#define MACH_TYPE_ARMADILLO_800EVA 3863
#define MACH_TYPE_KZM9G4140
+#define MACH_TYPE_SOM5_EVB 4545
Don't touch this file and instead add just this define to your config,
and then #define CONFIG_MACH_TYPE MACH_... If you can't just support
DT-only.
OK
[snip]
+const struct pad_conf_entry core_padconf_array_non_essential[] = {
+#if 0
Remove #if 0'd code.
Done
+gd-bd-bi_arch_number = MACH_TYPE_SOM5_EVB;
CONFIG_MACH_TYPE in your config and you don't need this line
All OMAP boards currently have it. Stay as is.
+#ifdef CONFIG_TWL6035_AUDPWR
+/* Useful for measuring voltages around the codec.
+ * Works with a TWL604x only.
+ */
/*
* Like this
*/
Fixed
+#ifdef CONFIG_I2C_INTERNAL_PULLUPS
+/* Enable internal I2C-compatible pullups on all buses
+ * TODO: Replace this ugly hardcoding with proper defines (omap.h)
+ * control_smart3io_padconf_0, control_i2c_0
Do please, thanks.
Was already done.
+#define USB_HOST_HS_CLKCTRL_MASK0x0100D7C0 /*
CM_L3INIT_USB_HOST_HS_CLKCTRL */
+#define USB_TLL_HS_CLKCTRL_MASK 0x0700 /*
CM_L3INIT_USB_TLL_HS_CLKCTRL */
Some header please.
Currently moved to board header. I wondered if a common OMAP header wouldn't be
more suitable, but having in mind that the utilized USB ports (and thus the
clocks
that should be enabled) vary from board to board, perhaps this (i.e. board
header)
is the best place.
+ * TODO: Replace this ugly hardcoding with proper defines
+ */
+writel(0x0100, 0x4ae0a310);
Again, do please.
This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct
(holding the auxclk0 member) has to be defined somewhere in the common OMAP5
headers. Sricharan? Or should I hack around?
+#define CONFIG_OMAP5430 /* which is in a 5430 */
+#define CONFIG_SOM5EVB /* working with the SOM5 EVB */
Unused.
Long gone. BTW, board config now includes omap5_common.h.
+/* Machine type for Linux */
+#define CONFIG_MACH_TYPEMACH_TYPE_SOM5_EVB
Ah, since you do have this part already, just update the rest as I had
said.
/* Machine type for Linux */
#ifndef MACH_TYPE_SOM5_EVB
#define MACH_TYPE_SOM5_EVB 4545
#endif
#define CONFIG_MACH_TYPEMACH_TYPE_SOM5_EVB
Is this OK?
+/* Enable all clocks: */
+/*#define CONFIG_SYS_CLOCKS_ENABLE_ALL*/
+
+#define CONFIG_SYS_ENABLE_PADS_ALL /* Enable all PADS for now */
Not allowed.
Shall see to it. What if one needs to test pins and connections during
board bring-up, e.g. via gpio commands?
+#define CONFIG_SYS_CA15_VECTOR_BASE SRAM_ROM_VECT_BASE
Introduced in the USB patches?
Not used and removed a while ago.
+#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, \
+57600, 115200}
Please use the fallback table.
Already done.
+/* MMC ENV related defines */
+#define CONFIG_ENV_IS_NOWHERE
+#ifdef CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */
+#define
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote:
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
Thought I had reviewed this already, sorry.
---
The som5_evb is an evaluation board for the APM-5 - a OMAP5430-based SOM
(system
On a Module) designed by MMS and manufactured under license by Jorjin
Technologies.
Above the '---' so it's in the changelog.
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/include/asm/mach-types.h
index a676b6d..236fa17 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type;
#define MACH_TYPE_OMAP5_SEVM 3777
#define MACH_TYPE_ARMADILLO_800EVA 3863
#define MACH_TYPE_KZM9G4140
+#define MACH_TYPE_SOM5_EVB 4545
Don't touch this file and instead add just this define to your config,
and then #define CONFIG_MACH_TYPE MACH_... If you can't just support
DT-only.
[snip]
+const struct pad_conf_entry core_padconf_array_non_essential[] = {
+#if 0
Remove #if 0'd code.
+ gd-bd-bi_arch_number = MACH_TYPE_SOM5_EVB;
CONFIG_MACH_TYPE in your config and you don't need this line
+#ifdef CONFIG_TWL6035_AUDPWR
+ /* Useful for measuring voltages around the codec.
+ * Works with a TWL604x only.
+ */
/*
* Like this
*/
+#ifdef CONFIG_I2C_INTERNAL_PULLUPS
+ /* Enable internal I2C-compatible pullups on all buses
+ * TODO: Replace this ugly hardcoding with proper defines (omap.h)
+ * control_smart3io_padconf_0, control_i2c_0
Do please, thanks.
+#define USB_HOST_HS_CLKCTRL_MASK 0x0100D7C0 /*
CM_L3INIT_USB_HOST_HS_CLKCTRL */
+#define USB_TLL_HS_CLKCTRL_MASK 0x0700 /*
CM_L3INIT_USB_TLL_HS_CLKCTRL */
Some header please.
+ * TODO: Replace this ugly hardcoding with proper defines
+ */
+ writel(0x0100, 0x4ae0a310);
Again, do please.
+#define CONFIG_OMAP5430 /* which is in a 5430 */
+#define CONFIG_SOM5EVB /* working with the SOM5 EVB */
Unused.
+/* Machine type for Linux */
+#define CONFIG_MACH_TYPE MACH_TYPE_SOM5_EVB
Ah, since you do have this part already, just update the rest as I had
said.
+/* Enable all clocks: */
+/*#define CONFIG_SYS_CLOCKS_ENABLE_ALL*/
+
+#define CONFIG_SYS_ENABLE_PADS_ALL /* Enable all PADS for now */
Not allowed.
+#define CONFIG_SYS_CA15_VECTOR_BASE SRAM_ROM_VECT_BASE
Introduced in the USB patches?
+#define CONFIG_SYS_BAUDRATE_TABLE{4800, 9600, 19200, 38400, \
+ 57600, 115200}
Please use the fallback table.
+/* MMC ENV related defines */
+#define CONFIG_ENV_IS_NOWHERE
+#ifdef CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */
+#define CONFIG_ENV_OFFSET0xE
+#define CONFIG_CMD_SAVEENV
+#endif
This is a little un-clear. If MMC will be in mmc like the uEVM, just do
so, and if no storage of env, leave it as NOWHERE.
+#define CONFIG_CMD_PING /* PING support */
space not tab, fix globally.
+#define CONFIG_NET_MULTI
Unused.
+ usbethaddr=9e:77:39:1b:c4:2d\0 \
Not allowed.
+/*
+ * memtest setup
+ */
+#define CONFIG_SYS_MEMTEST_START 0xb800
+#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START +
(256 20))
+/* Undef following two for simple mtest */
+#define CONFIG_SYS_ALT_MEMTEST
+#define CONFIG_SYS_MEMTEST_SCRATCH 0x8100
Please see doc/README.memory-test and update as mtest is no longer a
default command.
Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
The som5_evb is an evaluation board for the APM-5 - a OMAP5430-based SOM (system
On a Module) designed by MMS and manufactured under license by Jorjin
Technologies.
arch/arm/include/asm/mach-types.h | 13 ++
board/mms/som5_evb/Makefile | 49 +
board/mms/som5_evb/s5evb_mux_data.h | 376 +++
board/mms/som5_evb/som5_evb.c | 200 +++
boards.cfg |1 +
include/configs/omap5_som5_evb.h| 336 +++
6 files changed, 975 insertions(+)
create mode 100644 board/mms/som5_evb/Makefile
create mode 100644 board/mms/som5_evb/s5evb_mux_data.h
create mode 100644 board/mms/som5_evb/som5_evb.c
create mode 100644 include/configs/omap5_som5_evb.h
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/include/asm/mach-types.h
index a676b6d..236fa17 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type;
#define MACH_TYPE_OMAP5_SEVM 3777
#define MACH_TYPE_ARMADILLO_800EVA 3863
#define MACH_TYPE_KZM9G4140
+#define MACH_TYPE_SOM5_EVB 4545
#ifdef CONFIG_ARCH_EBSA110
# ifdef machine_arch_type
@@ -14248,6 +14249,18 @@ extern unsigned int __machine_arch_type;
# define machine_is_kzm9g()(0)
#endif
+#ifdef CONFIG_MACH_SOM5_EVB
+# ifdef machine_arch_type
+# undef machine_arch_type
+# define machine_arch_type __machine_arch_type
+# else
+# define machine_arch_type MACH_TYPE_SOM5_EVB
+# endif
+# define machine_is_som5_evb() (machine_arch_type == MACH_TYPE_SOM5_EVB)
+#else
+# define machine_is_som5_evb() (0)
+#endif
+
/*
* These have not yet been registered
*/
diff --git a/board/mms/som5_evb/Makefile b/board/mms/som5_evb/Makefile
new file mode 100644
index 000..248e5cc
--- /dev/null
+++ b/board/mms/som5_evb/Makefile
@@ -0,0 +1,49 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := som5_evb.o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+clean:
+ rm -f $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/mms/som5_evb/s5evb_mux_data.h
b/board/mms/som5_evb/s5evb_mux_data.h
new file mode 100644
index 000..791a4ad
--- /dev/null
+++ b/board/mms/som5_evb/s5evb_mux_data.h
@@ -0,0 +1,376 @@
+/*
+ * Copyright (C) 2013 MM Solutions AD, www.mm-sol.com
+ *
+ * Lubomir Popov lpo...@mm-sol.com l-po...@ti.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#ifndef _SOM5_EVB_MUX_DATA_H
+#define _SOM5_EVB_MUX_DATA_H
+
+#include asm/arch/mux_omap5.h
+
+const struct pad_conf_entry core_padconf_array_essential[] = {
+
+ {EMMC_CLK, (PTU | IEN | M0)}, /* EMMC_CLK */
+ {EMMC_CMD, (PTU | IEN | M0)}, /* EMMC_CMD */
+ {EMMC_DATA0, (PTU | IEN | M0)}, /* EMMC_DATA0*/
+ {EMMC_DATA1, (PTU | IEN | M0)},
