Re: Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
Hello, Am 19.08.20 um 21:54 schrieb Ralph Siemsen: > On Wed, Aug 19, 2020 at 09:28:39PM +0200, Marek Vasut wrote: >> >> Is the F2SDRAM port enabled in your case ? > > Is there a way I can check this via software? Unfortunately I do not > have access to Quartus/Qsys files, nor the person who did the design. Looking to the U-Boot driver "drivers/net/altera_tse.c" tells me, that it maps system memory for the SGDMA controller in its probe function. I found the Altera SoC Triple Speed Ethernet Design Example at [1]. And yes, it seems to use F2SDRAM as well. [1] https://rocketboards.org/foswiki/Projects/AlteraSoCTripleSpeedEthernetDesignExample Wolfgang
socfpga: cyclone5: ums not working without usb start
Hello, I realized, that "ums 0 mmc 0" is not working without executing "usb start" in advance. That's because "ums" does not enable the clock and deassert the USB reset. Is that by purpose? At least "usb start" was not necessary with v2016.11. Wolfgang
[U-Boot] U-Boot for the Socfpga Arria10 board
Hello, I'm trying to understand what is necessary to get mainline U-Boot booting from the eMMC of an Arria10 board, which is significantly different to the Cyclone 5. I'm playing with U-Boot v2019.10! I find some related documentation at [1]. Section "Arria 10 SoC - Boot from SD Card " seems to apply to the mainline U-Boot as well, at a first glance. Is there some similar doc for mainline U-Boot? What are the differences in mainline? Is it working or is something missing? So I need at least three partitions on the eMMC: 1. VFAT partition with u-boot.img and fit_spl_fpga.itb 2. A2 partition with 4x u-boot-spl.sfp (or u-boot-with-spl.sfp) 3. Linux partition Where do I specify the physical number of the partition 1.? Is it still possible to load the secondary bootloader (u-boot.img) from offset 0x800 of the A2 partition? It seems that "SPL_FS_FAT" breaks it. [1] https://rocketboards.org/foswiki/Documentation/BuildingBootloader TIA, Wolfgang ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
This reverts commit c5f4b805755912a3d2fe20f014b6b6ab0473bd73.
Conflicts:
arch/arm/mach-socfpga/misc_gen5.c
Without socfpga_sdram_apply_static_cfg(), the system hangs when Linux
calls altvipfb2_start_hw() of the Intel Video and Image Processing(VIP)
Frame Buffer II driver (drivers/video/fbdev/altvipfb2.c), but only
after a power cycle (cold boot). The issue does not show up after a
soft reset (warm boot) and with v2018.11.
Signed-off-by: Wolfgang Grandegger
CC: Marek Vasut
CC: Simon Goldschmidt
---
arch/arm/mach-socfpga/misc_gen5.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/mach-socfpga/misc_gen5.c
b/arch/arm/mach-socfpga/misc_gen5.c
index 7209e8d..c1ecd92 100644
--- a/arch/arm/mach-socfpga/misc_gen5.c
+++ b/arch/arm/mach-socfpga/misc_gen5.c
@@ -216,6 +216,35 @@ int arch_early_init_r(void)
static struct socfpga_sdr_ctrl *sdr_ctrl =
(struct socfpga_sdr_ctrl *)SDR_CTRLGRP_ADDRESS;
+static void socfpga_sdram_apply_static_cfg(void)
+{
+ const u32 applymask = 0x8;
+ u32 val = readl(&sdr_ctrl->static_cfg) | applymask;
+
+ /*
+* SDRAM staticcfg register specific:
+* When applying the register setting, the CPU must not access
+* SDRAM. Luckily for us, we can abuse i-cache here to help us
+* circumvent the SDRAM access issue. The idea is to make sure
+* that the code is in one full i-cache line by branching past
+* it and back. Once it is in the i-cache, we execute the core
+* of the code and apply the register settings.
+*
+* The code below uses 7 instructions, while the Cortex-A9 has
+* 32-byte cachelines, thus the limit is 8 instructions total.
+*/
+ asm volatile(
+ ".align 5 \n"
+ " b 2f \n"
+ "1: str %0, [%1]\n"
+ " dsb \n"
+ " isb \n"
+ " b 3f \n"
+ "2: b 1b \n"
+ "3: nop \n"
+ : : "r"(val), "r"(&sdr_ctrl->static_cfg) : "memory", "cc");
+}
+
void do_bridge_reset(int enable, unsigned int mask)
{
int i;
@@ -233,6 +262,7 @@ void do_bridge_reset(int enable, unsigned int mask)
writel(iswgrp_handoff[2],
socfpga_get_sysmgr_addr() +
SYSMGR_GEN5_FPGAINFGRP_MODULE);
+ socfpga_sdram_apply_static_cfg();
writel(iswgrp_handoff[3], &sdr_ctrl->fpgaport_rst);
writel(iswgrp_handoff[0],
socfpga_get_rstmgr_addr() + RSTMGR_GEN5_BRGMODRST);
@@ -245,6 +275,7 @@ void do_bridge_reset(int enable, unsigned int mask)
writel(0, socfpga_get_sysmgr_addr() +
SYSMGR_GEN5_FPGAINFGRP_MODULE);
writel(0, &sdr_ctrl->fpgaport_rst);
+ socfpga_sdram_apply_static_cfg();
writel(0x7, socfpga_get_rstmgr_addr() + RSTMGR_GEN5_BRGMODRST);
writel(1, &nic301_regs->remap);
}
--
1.9.1
Re: Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
Am 06.08.20 um 13:04 schrieb Marek Vasut: > On 8/6/20 12:53 PM, Wolfgang Grandegger wrote: >> This reverts commit c5f4b805755912a3d2fe20f014b6b6ab0473bd73. >> >> Conflicts: >> arch/arm/mach-socfpga/misc_gen5.c >> >> Without socfpga_sdram_apply_static_cfg(), the system hangs when Linux >> calls altvipfb2_start_hw() of the Intel Video and Image Processing(VIP) >> Frame Buffer II driver (drivers/video/fbdev/altvipfb2.c) > > There is no such driver in mainline U-Boot or Linux. It's a simple frame buffer driver from linux-socfpga for the IP core Intel Video and Image Processing(VIP) Frame Buffer II. It actually hangs here when the streaming starts: https://github.com/altera-opensource/linux-socfpga/blob/socfpga-5.4.44-lts/drivers/video/fbdev/altvipfb2.c#L69 I can also hang the system if I setup and start the FB with just a few U-Boot commands. I think the system hangs when the IP core starts reading the FB data from the system memory. >> , but only >> after a power cycle (cold boot). The issue does not show up after a >> soft reset (warm boot) and with v2018.11. > > See the commit message of the patch this is reverting, I believe there > is a deeper issue with the static config register. Can you investigate? I read the commit message, but well, I can't follow all the details :(. On the other hand, it seems also not clear why the fix was added. Any idea what to investigate. Wolfgang
Re: Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
Am 06.08.20 um 14:50 schrieb Marek Vasut: > On 8/6/20 2:36 PM, Wolfgang Grandegger wrote: >> Am 06.08.20 um 13:04 schrieb Marek Vasut: >>> On 8/6/20 12:53 PM, Wolfgang Grandegger wrote: >>>> This reverts commit c5f4b805755912a3d2fe20f014b6b6ab0473bd73. >>>> >>>> Conflicts: >>>>arch/arm/mach-socfpga/misc_gen5.c >>>> >>>> Without socfpga_sdram_apply_static_cfg(), the system hangs when Linux >>>> calls altvipfb2_start_hw() of the Intel Video and Image Processing(VIP) >>>> Frame Buffer II driver (drivers/video/fbdev/altvipfb2.c) >>> >>> There is no such driver in mainline U-Boot or Linux. >> >> It's a simple frame buffer driver from linux-socfpga for the IP core >> Intel Video and Image Processing(VIP) Frame Buffer II. It actually >> hangs here when the streaming starts: >> >> https://github.com/altera-opensource/linux-socfpga/blob/socfpga-5.4.44-lts/drivers/video/fbdev/altvipfb2.c#L69 >> >> I can also hang the system if I setup and start the FB with just a >> few U-Boot commands. I think the system hangs when the IP core starts >> reading the FB data from the system memory. > > I am CCing Dinh , I recall there was some discussion about hangs on > CycloneV and it was fixed recently. > >>>> , but only >>>> after a power cycle (cold boot). The issue does not show up after a >>>> soft reset (warm boot) and with v2018.11. >>> >>> See the commit message of the patch this is reverting, I believe there >>> is a deeper issue with the static config register. Can you investigate? >> >> I read the commit message, but well, I can't follow all the details :(. >> On the other hand, it seems also not clear why the fix was added. Any >> idea what to investigate. > > The system was repeatedly rebooted in a loop, the FPGA was loaded before > Linux booted. After hundreds of reboots, the system got stuck on setting > up the static cfg register. I think there was even another email I rebooted Linux on my MCVEVP more than 100 times with and without loading the FPGA in U-Boot. The system never hang! > exchange where the suggestion was to make this apply_static_cfg optional > and only use it when the DRAM port is enabled in the quartus design. > Maybe that is the way out of this ? Yep. Wolfgang
Re: Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
Am 07.08.20 um 13:12 schrieb Marek Vasut: > On 8/7/20 12:58 PM, Wolfgang Grandegger wrote: >> Am 06.08.20 um 14:50 schrieb Marek Vasut: >>> On 8/6/20 2:36 PM, Wolfgang Grandegger wrote: >>>> Am 06.08.20 um 13:04 schrieb Marek Vasut: >>>>> On 8/6/20 12:53 PM, Wolfgang Grandegger wrote: >>>>>> This reverts commit c5f4b805755912a3d2fe20f014b6b6ab0473bd73. >>>>>> >>>>>> Conflicts: >>>>>> arch/arm/mach-socfpga/misc_gen5.c >>>>>> >>>>>> Without socfpga_sdram_apply_static_cfg(), the system hangs when Linux >>>>>> calls altvipfb2_start_hw() of the Intel Video and Image Processing(VIP) >>>>>> Frame Buffer II driver (drivers/video/fbdev/altvipfb2.c) >>>>> >>>>> There is no such driver in mainline U-Boot or Linux. >>>> >>>> It's a simple frame buffer driver from linux-socfpga for the IP core >>>> Intel Video and Image Processing(VIP) Frame Buffer II. It actually >>>> hangs here when the streaming starts: >>>> >>>> https://github.com/altera-opensource/linux-socfpga/blob/socfpga-5.4.44-lts/drivers/video/fbdev/altvipfb2.c#L69 >>>> >>>> I can also hang the system if I setup and start the FB with just a >>>> few U-Boot commands. I think the system hangs when the IP core starts >>>> reading the FB data from the system memory. >>> >>> I am CCing Dinh , I recall there was some discussion about hangs on >>> CycloneV and it was fixed recently. >>> >>>>>> , but only >>>>>> after a power cycle (cold boot). The issue does not show up after a >>>>>> soft reset (warm boot) and with v2018.11. >>>>> >>>>> See the commit message of the patch this is reverting, I believe there >>>>> is a deeper issue with the static config register. Can you investigate? >>>> >>>> I read the commit message, but well, I can't follow all the details :(. >>>> On the other hand, it seems also not clear why the fix was added. Any >>>> idea what to investigate. >>> >>> The system was repeatedly rebooted in a loop, the FPGA was loaded before >>> Linux booted. After hundreds of reboots, the system got stuck on setting >>> up the static cfg register. I think there was even another email >> >> I rebooted Linux on my MCVEVP more than 100 times with and without >> loading the FPGA in U-Boot. The system never hang! > > It could very well be bitstream related, wait for Simon to chime in. > Do you load the bitstream in U-Boot or in Linux ? I load it in U-Boot. And I repeated the test more than 1000 times (100 above is a typo)! OK, let's wait for more input. >>> exchange where the suggestion was to make this apply_static_cfg optional >>> and only use it when the DRAM port is enabled in the quartus design. >>> Maybe that is the way out of this ? >> >> Yep. > > [...] Wolfgang
Re: Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
Am 07.08.20 um 17:05 schrieb Dinh Nguyen: > CC Hean Loong: > > > On 8/6/20 7:36 AM, Wolfgang Grandegger wrote: >> Am 06.08.20 um 13:04 schrieb Marek Vasut: >>> On 8/6/20 12:53 PM, Wolfgang Grandegger wrote: >>>> This reverts commit c5f4b805755912a3d2fe20f014b6b6ab0473bd73. >>>> >>>> Conflicts: >>>>arch/arm/mach-socfpga/misc_gen5.c >>>> >>>> Without socfpga_sdram_apply_static_cfg(), the system hangs when Linux >>>> calls altvipfb2_start_hw() of the Intel Video and Image Processing(VIP) >>>> Frame Buffer II driver (drivers/video/fbdev/altvipfb2.c) >>> >>> There is no such driver in mainline U-Boot or Linux. >> >> It's a simple frame buffer driver from linux-socfpga for the IP core >> Intel Video and Image Processing(VIP) Frame Buffer II. It actually >> hangs here when the streaming starts: >> >> https://github.com/altera-opensource/linux-socfpga/blob/socfpga-5.4.44-lts/drivers/video/fbdev/altvipfb2.c#L69 >> >> I can also hang the system if I setup and start the FB with just a >> few U-Boot commands. I think the system hangs when the IP core starts >> reading the FB data from the system memory. >> > > Can you elaborate what you mean here? You are starting the Frame Buffer > driver with U-Boot? Yes, the FPGA image provides the Intel Video and Image Processing(VIP) Frame Buffer II IP core and it is loaded with "> fpga load ..." in U-Boot before Linux starts. And yes, this IP core does use the DRAM bridge (F2S). The systems hangs, if I start the framebuffer in U-Boot or Linux, but only after a power-cycle. It works fine after a soft-reset. >>>> , but only >>>> after a power cycle (cold boot). The issue does not show up after a >>>> soft reset (warm boot) and with v2018.11. >>> >>> See the commit message of the patch this is reverting, I believe there >>> is a deeper issue with the static config register. Can you investigate? >> >> I read the commit message, but well, I can't follow all the details :(. >> On the other hand, it seems also not clear why the fix was added. Any >> idea what to investigate. >> Wolfgang
Re: Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
Hello,
reading you question again...
Am 07.08.20 um 17:49 schrieb Wolfgang Grandegger:
>
>
> Am 07.08.20 um 17:05 schrieb Dinh Nguyen:
>> CC Hean Loong:
>>
>>
>> On 8/6/20 7:36 AM, Wolfgang Grandegger wrote:
>>> Am 06.08.20 um 13:04 schrieb Marek Vasut:
>>>> On 8/6/20 12:53 PM, Wolfgang Grandegger wrote:
>>>>> This reverts commit c5f4b805755912a3d2fe20f014b6b6ab0473bd73.
>>>>>
>>>>> Conflicts:
>>>>> arch/arm/mach-socfpga/misc_gen5.c
>>>>>
>>>>> Without socfpga_sdram_apply_static_cfg(), the system hangs when Linux
>>>>> calls altvipfb2_start_hw() of the Intel Video and Image Processing(VIP)
>>>>> Frame Buffer II driver (drivers/video/fbdev/altvipfb2.c)
>>>>
>>>> There is no such driver in mainline U-Boot or Linux.
>>>
>>> It's a simple frame buffer driver from linux-socfpga for the IP core
>>> Intel Video and Image Processing(VIP) Frame Buffer II. It actually
>>> hangs here when the streaming starts:
>>>
>>> https://github.com/altera-opensource/linux-socfpga/blob/socfpga-5.4.44-lts/drivers/video/fbdev/altvipfb2.c#L69
>>>
>>> I can also hang the system if I setup and start the FB with just a
>>> few U-Boot commands. I think the system hangs when the IP core starts
>>> reading the FB data from the system memory.
>>>
>>
>> Can you elaborate what you mean here? You are starting the Frame Buffer
>> driver with U-Boot?
You ask how to start the frame-buffer in U-Boot. Here are the commands:
=> fpga load 0 ${loadaddr} ${filesize}
=> bridge enable
=> mw.l 0xffc25080 0x3fff
=> mw.l 0xffc2508c 0x
=> mw.l 0xffc25090 0x
=> mw.b 0xbef0 0xff 0x5dc00
=> mw.b 0xbef5dc00 0x00 0x5dc00
=> mw.b 0xbefbb800 0x80 0x5dc00
=> mw.l 0xff280214 0x006401e0
=> mw.l 0xff280218 0xbef0
=> mw.l 0xff280200 1
It fills the framebuffer at 0xbef0 and starts the streaming with
the last command.
> Yes, the FPGA image provides the Intel Video and Image Processing(VIP)
> Frame Buffer II IP core and it is loaded with "> fpga load ..." in
> U-Boot before Linux starts. And yes, this IP core does use the DRAM
> bridge (F2S).
> The systems hangs, if I start the framebuffer in U-Boot or Linux, but
> only after a power-cycle. It works fine after a soft-reset.
>
>>>>> , but only
>>>>> after a power cycle (cold boot). The issue does not show up after a
>>>>> soft reset (warm boot) and with v2018.11.
>>>>
>>>> See the commit message of the patch this is reverting, I believe there
>>>> is a deeper issue with the static config register. Can you investigate?
>>>
>>> I read the commit message, but well, I can't follow all the details :(.
>>> On the other hand, it seems also not clear why the fix was added. Any
>>> idea what to investigate.
>>>
Wolfgang
Re: Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
Hello Ley Foon, Am 10.08.20 um 10:30 schrieb Tan, Ley Foon: > > >> -Original Message- >> From: Marek Vasut >> Sent: Friday, August 7, 2020 7:53 PM >> To: Wolfgang Grandegger ; U-Boot Mailing List >> >> Cc: Simon Goldschmidt ; Nguyen, Dinh >> ; Tan, Ley Foon >> Subject: Re: Revert "ARM: socfpga: Remove >> socfpga_sdram_apply_static_cfg() >> >> On 8/7/20 1:22 PM, Wolfgang Grandegger wrote: >>> >>> >>> Am 07.08.20 um 13:12 schrieb Marek Vasut: >>>> On 8/7/20 12:58 PM, Wolfgang Grandegger wrote: >>>>> Am 06.08.20 um 14:50 schrieb Marek Vasut: >>>>>> On 8/6/20 2:36 PM, Wolfgang Grandegger wrote: >>>>>>> Am 06.08.20 um 13:04 schrieb Marek Vasut: >>>>>>>> On 8/6/20 12:53 PM, Wolfgang Grandegger wrote: >>>>>>>>> This reverts commit >> c5f4b805755912a3d2fe20f014b6b6ab0473bd73. >>>>>>>>> >>>>>>>>> Conflicts: >>>>>>>>> arch/arm/mach-socfpga/misc_gen5.c >>>>>>>>> >>>>>>>>> Without socfpga_sdram_apply_static_cfg(), the system hangs when >>>>>>>>> Linux calls altvipfb2_start_hw() of the Intel Video and Image >>>>>>>>> Processing(VIP) Frame Buffer II driver >>>>>>>>> (drivers/video/fbdev/altvipfb2.c) >>>>>>>> >>>>>>>> There is no such driver in mainline U-Boot or Linux. >>>>>>> >>>>>>> It's a simple frame buffer driver from linux-socfpga for the IP >>>>>>> core Intel Video and Image Processing(VIP) Frame Buffer II. It >>>>>>> actually hangs here when the streaming starts: >>>>>>> >>>>>>> https://github.com/altera-opensource/linux-socfpga/blob/socfpga-5. >>>>>>> 4.44-lts/drivers/video/fbdev/altvipfb2.c#L69 >>>>>>> >>>>>>> I can also hang the system if I setup and start the FB with just a >>>>>>> few U-Boot commands. I think the system hangs when the IP core >>>>>>> starts reading the FB data from the system memory. >>>>>> >>>>>> I am CCing Dinh , I recall there was some discussion about hangs on >>>>>> CycloneV and it was fixed recently. >>>>>> >>>>>>>>> , but only >>>>>>>>> after a power cycle (cold boot). The issue does not show up >>>>>>>>> after a soft reset (warm boot) and with v2018.11. >>>>>>>> >>>>>>>> See the commit message of the patch this is reverting, I believe >>>>>>>> there is a deeper issue with the static config register. Can you >> investigate? >>>>>>> >>>>>>> I read the commit message, but well, I can't follow all the details :(. >>>>>>> On the other hand, it seems also not clear why the fix was added. >>>>>>> Any idea what to investigate. >>>>>> >>>>>> The system was repeatedly rebooted in a loop, the FPGA was loaded >>>>>> before Linux booted. After hundreds of reboots, the system got >>>>>> stuck on setting up the static cfg register. I think there was even >>>>>> another email >>>>> >>>>> I rebooted Linux on my MCVEVP more than 100 times with and without >>>>> loading the FPGA in U-Boot. The system never hang! >>>> >>>> It could very well be bitstream related, wait for Simon to chime in. >>>> Do you load the bitstream in U-Boot or in Linux ? >>> >>> I load it in U-Boot. And I repeated the test more than 1000 times (100 >>> above is a typo)! OK, let's wait for more input. >> >> Sorry for pushing back on this, the issue keeps coming back and until we get >> to the bottom of this, I don't want to see applying and reverting a patch >> back >> and forth. And getting to the real bottom of this seems to be particularly >> difficult task. >> >> Does your bitstream use the DRAM bridge (F2S) ? I think it does. The one I >> used didn't as far as I remember. So maybe the way forward is to only apply >> static cfg if the bridge is enabled. > > We have another email thread before about restore back > socfpga_sdram_apply_static_cfg() function. > Yes, we talked about only apply static cfg bit if the F2S port is enabled. > But, no final decision previously. > I can re-submit the patches if you are okay with this approach. > > Wolfgang, > I have downstream patches for checking F2S port before apply static cfg bit. > Can you try these 2 patches on your side if they solve your issue? > I can't reproduce the issue on my side. > https://github.com/altera-opensource/u-boot-socfpga/commit/ca64e19e40224091b7f57b63ddd7ea9cdc6e8d44 > https://github.com/altera-opensource/u-boot-socfpga/commit/11ff7b9ce3abc5e61f44997a017b175c3719 > No, this does not fix the problem with my hardware because handoff[3] is zero: do_bridge_reset: handoff[0..5]: 0x0 0x19 0x0 0x0 0xf 0x0 Wolfgang
Re: [U-Boot] U-Boot for the Socfpga Arria10 board
Hello, Am 18.11.19 um 22:15 schrieb Simon Goldschmidt: > Am 18.11.2019 um 19:08 schrieb Wolfgang Grandegger: >> Hello, >> >> I'm trying to understand what is necessary to get mainline U-Boot >> booting from the eMMC of an Arria10 board, which is significantly >> different to the Cyclone 5. > > Unfortunately, my playground here is limited to Cyclone 5, but from the > U-Boot side and from what I know, booting an Arria 10 should be very > similar to Cyclone5 (given that Stratix 10 and Agilex have a very much > different boot flow). > > Do you have vendor U-Boot running? If not, I suggest to first get that > running. The step to mainline U-Boot should then hopefully not be too hard. I trying to get the vendor U-Boot v2019.04 from [1] booting as described in [2]. Unfortunately the SDRAM calibration fails: FPGA: Early Release Succeeded. wait_for_bit_le32: Timeout (reg= mask=1 wait_set=) c2s= s2c=0040 nr0=0620 nr1=4847 nr2= dst=0002 emif_reset interrupt cleared nr0=0620 nr1=4847 nr2= wait_for_bit_le32: Timeout (reg= mask=1 wait_set=) c2s= s2c=0040 nr0=0620 nr1=4847 nr2= dst=0002 emif_reset interrupt cleared nr0=0620 nr1=4847 nr2= ... Error: Could Not Calibrate SDRAM DDRCAL: Failed Trying to boot from MMC1 It seems, that the SDRAM is still not accessible after loading the periph image. Any idea what could cause that issue? It works fine after a soft-reset or if I load the full image via JTAG. [1] https://github.com/altera-opensource/u-boot-socfpga/tree/socfpga_v2019.04 [2] https://rocketboards.org/foswiki/Documentation/BuildingBootloader TIA. Wolfgang
SocFPGA: Arria10: Boot from FPGA
Hello, I want to boot U-Boot on the Arria10 from the FPGA using recent code. In the past I used the U-Boot created by the "bsp-editor" as described at [1], but starting with Quartus 21.3, the so called "old flow" is no longer available. I was able to build mainline U-Boot for our Arria10 board and it boots fine from the eMMC. I wonder if it's also suitable for booting from the FPGA. Is it available? Has this already been done? IIRC, some special hacks are required to support boot from the FPGA. [1] https://rocketboards.org/foswiki/Documentation/UBootA10FPGABoot Wolfgang
Re: [U-Boot] [PATCH] 85xx: Using proper I2C source clock divider for MPC8544
Kumar Gala wrote: > On Oct 10, 2008, at 2:29 AM, Wolfgang Grandegger wrote: > >> Kumar Gala wrote: >>> On Sep 30, 2008, at 3:55 AM, Wolfgang Grandegger wrote: >>> >>>> Measurements with our MPC8544 board showed that the I2C bus >>>> frequency >>>> is wrong by a factor of 1.5. Obviously, the interpretation of the >>>> MPC85xx_PORDEVSR2_SEC_CFG bit of the cfg_sec_freq register is not >>>> correct. There seems to be an error in the 8544 RM. >>>> >>>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> >>>> --- >>>> cpu/mpc85xx/speed.c |4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> can you do me a favor and dump the value of MPC85xx_PORDEVSR2. Also >>> can you tell me what rev 8544 you have. >> See below: >> >> [EMAIL PROTECTED] >> >> CPU: 8544E, Version: 1.1, (0x803c0111) >> Core: E500, Version: 2.2, (0x80210022) >> Clock Configuration: >> CPU: 667 MHz, CCB: 334 MHz, >> DDR: 167 MHz (334 MT/s data rate), LBC: 41 MHz >> L1:D-cache 32 kB enabled >> I-cache 32 kB enabled >> Board: Socrates >> >> Wolfgang. > > thanks. How did you do the measurements that got you this 1.5x factor? This afternoon I re-measured the I2C bus clock frequency with the oscilloscope at the I2C clock line on our Socrates MPC8544 board. With the patch applied, I measured the correct frequency of 100 kHz. Without, it was a factor of 1.5 too high. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Using proper I2C source clock divider for MPC8544
Kumar Gala wrote: > > On Oct 14, 2008, at 2:11 PM, Wolfgang Grandegger wrote: > >> Kumar Gala wrote: >>> On Oct 10, 2008, at 2:29 AM, Wolfgang Grandegger wrote: >>> >>>> Kumar Gala wrote: >>>>> On Sep 30, 2008, at 3:55 AM, Wolfgang Grandegger wrote: >>>>> >>>>>> Measurements with our MPC8544 board showed that the I2C bus >>>>>> frequency >>>>>> is wrong by a factor of 1.5. Obviously, the interpretation of the >>>>>> MPC85xx_PORDEVSR2_SEC_CFG bit of the cfg_sec_freq register is not >>>>>> correct. There seems to be an error in the 8544 RM. >>>>>> >>>>>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> >>>>>> --- >>>>>> cpu/mpc85xx/speed.c |4 ++-- >>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> can you do me a favor and dump the value of MPC85xx_PORDEVSR2. Also >>>>> can you tell me what rev 8544 you have. >>>> See below: >>>> >>>> [EMAIL PROTECTED] >>>> >>>> CPU: 8544E, Version: 1.1, (0x803c0111) >>>> Core: E500, Version: 2.2, (0x80210022) >>>> Clock Configuration: >>>>CPU: 667 MHz, CCB: 334 MHz, >>>>DDR: 167 MHz (334 MT/s data rate), LBC: 41 MHz >>>> L1:D-cache 32 kB enabled >>>>I-cache 32 kB enabled >>>> Board: Socrates >>>> >>>> Wolfgang. >>> >>> thanks. How did you do the measurements that got you this 1.5x factor? >> >> This afternoon I re-measured the I2C bus clock frequency with the >> oscilloscope at the I2C clock line on our Socrates MPC8544 board. With >> the patch applied, I measured the correct frequency of 100 kHz. Without, >> it was a factor of 1.5 too high. > > are you able to change cfg_seq_freq on the board? At least I don't know how. It's defined via hardware strap, I imagine. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Using proper I2C source clock divider for MPC8544
Kumar Gala wrote: > thanks. How did you do the measurements that got you this 1.5x > factor? This afternoon I re-measured the I2C bus clock frequency with the oscilloscope at the I2C clock line on our Socrates MPC8544 board. With the patch applied, I measured the correct frequency of 100 kHz. Without, it was a factor of 1.5 too high. >>> are you able to change cfg_seq_freq on the board? >> At least I don't know how. It's defined via hardware strap, I imagine. > > Its is.. not sure if you have schematics for the board. If you do > look to see if LWE_B is wired to anything. I'm going to ask the customer. But even if it's wired, the bit in the cfg_sec_freq register should reflect properly that case. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2][for v2008.10] 85xx: Using proper I2C source clock divider for MPC8544
Hi Kumar, Kumar Gala wrote: > The MPC8544 RM incorrect shows the SEC_CFG bit in PORDEVSR2 as being > bit 26, instead it should be bit 28. This caused in incorrect > interpretation of the i2c_clk which is the same as the SEC clk on > MPC8544. The SEC clk is controlled by cfg_sec_freq that is reported > in PORDEVSR2. > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> That makes sense now. I just got the confirmation from the customer, that LWE_B[0] is indeed pulled down via FPGA: LWE_B[0] Pulldown SEC Frequency Ratio 2:1 Thanks for your investigations. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PHY lib
Wolfgang Denk wrote: > Dear Ben, > > In message <[EMAIL PROTECTED]> you wrote: >> I'd like to have the PHY library included in the 02.2009 release. One > > v2009.02, that is :-) > >> If we pulled all board info from a device tree, as people were talking >> about a few months ago, this would be easy and scalable. I don't know >> the status of that idea, and am very interested in what you and others >> think. > > I would really appreciate a move into this direction. > > BTW - Wolfgang: do you still plan to rebase & post your "Configure > U-Boot with a Device Tree" patches? They must have grown out of sync > terribly? Well, not really. The patch providing access to the FDT is quite simple, making use of it is another subject and requires a FDT aware device interface, in the first place. Search for "[U-Boot-Users] using a flat device tree to drive u-boot config" to find the last discussion on this topic. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC5121 MSCAN Peripheral in U-Boot
Matteo Canella wrote: > Hi sirs, > > I'm implementing a driver for the MSCAN peripheral of the mpc5121 in Das > U-Boot. > > I'm wondering if there's anyone who has already done some work on it. $ find . -name '*.c'| xargs grep -i MSCAN reports two boards implementing a simple CAN command for loopback testing, I guess. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] I2C source clock frequency on MPC8544
Hello, the I2C source clock frequency for the MPC8544 is determined in cpu/mpc85xx/speed.c: #elif defined(CONFIG_MPC8544) /* * On the 8544, the I2C clock is the same as the SEC clock. This can be * either CCB/2 or CCB/3, depending on the value of cfg_sec_freq. See * 4.4.3.3 of the 8544 RM. Note that this might actually work for all * 85xx, but only the 8544 has cfg_sec_freq, so it's unknown if the * PORDEVSR2_SEC_CFG bit is 0 on all 85xx boards that are not an 8544. */ if (gur->pordevsr2 & MPC85xx_PORDEVSR2_SEC_CFG) gd->i2c1_clk = sys_info.freqSystemBus / 3; else gd->i2c1_clk = sys_info.freqSystemBus / 2; On our MPC8544 the MPC85xx_PORDEVSR2_SEC_CFG is set and the diver 3 therefore used. But that seems to be wrong. Measurements show, that the used divider is 2. Any idea what's going wrong? Is there an errata for the MPC8544? Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 85xx: Using proper I2C source clock divider for MPC8544
Measurements with our MPC8544 board showed that the I2C bus frequency is wrong by a factor of 1.5. Obviously, the interpretation of the MPC85xx_PORDEVSR2_SEC_CFG bit of the cfg_sec_freq register is not correct. There seems to be an error in the 8544 RM. Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> --- cpu/mpc85xx/speed.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: u-boot/cpu/mpc85xx/speed.c === --- u-boot.orig/cpu/mpc85xx/speed.c +++ u-boot/cpu/mpc85xx/speed.c @@ -101,9 +101,9 @@ int get_clocks (void) * PORDEVSR2_SEC_CFG bit is 0 on all 85xx boards that are not an 8544. */ if (gur->pordevsr2 & MPC85xx_PORDEVSR2_SEC_CFG) - gd->i2c1_clk = sys_info.freqSystemBus / 3; - else gd->i2c1_clk = sys_info.freqSystemBus / 2; + else + gd->i2c1_clk = sys_info.freqSystemBus / 3; #else /* Most 85xx SOCs use CCB/2, so this is the default behavior. */ gd->i2c1_clk = sys_info.freqSystemBus / 2; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Using proper I2C source clock divider for MPC8544
Kumar Gala wrote: > On Sep 30, 2008, at 3:55 AM, Wolfgang Grandegger wrote: > >> Measurements with our MPC8544 board showed that the I2C bus frequency >> is wrong by a factor of 1.5. Obviously, the interpretation of the >> MPC85xx_PORDEVSR2_SEC_CFG bit of the cfg_sec_freq register is not >> correct. There seems to be an error in the 8544 RM. >> >> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> >> --- >> cpu/mpc85xx/speed.c |4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > > can you do me a favor and dump the value of MPC85xx_PORDEVSR2. Also > can you tell me what rev 8544 you have. See below: [EMAIL PROTECTED] CPU: 8544E, Version: 1.1, (0x803c0111) Core: E500, Version: 2.2, (0x80210022) Clock Configuration: CPU: 667 MHz, CCB: 334 MHz, DDR: 167 MHz (334 MT/s data rate), LBC: 41 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: Socrates Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Using proper I2C source clock divider for MPC8544
Kumar Gala wrote: > On Oct 10, 2008, at 2:29 AM, Wolfgang Grandegger wrote: > >> Kumar Gala wrote: >>> On Sep 30, 2008, at 3:55 AM, Wolfgang Grandegger wrote: >>> >>>> Measurements with our MPC8544 board showed that the I2C bus >>>> frequency >>>> is wrong by a factor of 1.5. Obviously, the interpretation of the >>>> MPC85xx_PORDEVSR2_SEC_CFG bit of the cfg_sec_freq register is not >>>> correct. There seems to be an error in the 8544 RM. >>>> >>>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> >>>> --- >>>> cpu/mpc85xx/speed.c |4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> can you do me a favor and dump the value of MPC85xx_PORDEVSR2. Also >>> can you tell me what rev 8544 you have. >> See below: >> >> [EMAIL PROTECTED] >> >> CPU: 8544E, Version: 1.1, (0x803c0111) >> Core: E500, Version: 2.2, (0x80210022) >> Clock Configuration: >> CPU: 667 MHz, CCB: 334 MHz, >> DDR: 167 MHz (334 MT/s data rate), LBC: 41 MHz >> L1:D-cache 32 kB enabled >> I-cache 32 kB enabled >> Board: Socrates >> >> Wolfgang. > > thanks. How did you do the measurements that got you this 1.5x factor? Actually, this problem was reported by a customer using the I2C bus on the MPC8544E intensively. I'm going to find out how he did the measurements. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] USB: ehci-mx6: Fix broken IO access
To get USB working again on the i.MX6, this patch fixes a bug introduced
with commit 522b2a0 "Add proper IO accessors for mx6 usb registers.".
At that occasion, I also added the missing __iomem directive.
Cc: Marek Vasut
CC: Fabio Estevam
Signed-off-by: Wolfgang Grandegger
---
drivers/usb/host/ehci-mx6.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 5dec673..42c77fe 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -73,7 +73,8 @@ static void usbh1_internal_phy_clock_gate(int on)
static void usbh1_power_config(void)
{
- struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+ struct anatop_regs __iomem *anatop =
+ (struct anatop_regs __iomem *)ANATOP_BASE_ADDR;
/*
* Some phy and power's special controls for host1
* 1. The external charger detector needs to be disabled
@@ -87,7 +88,7 @@ static void usbh1_power_config(void)
&anatop->usb2_chrg_detect);
__raw_writel(ANADIG_USB2_PLL_480_CTRL_BYPASS,
-&anatop->usb2_pll_480_ctrl);
+&anatop->usb2_pll_480_ctrl_clr);
__raw_writel(ANADIG_USB2_PLL_480_CTRL_ENABLE |
ANADIG_USB2_PLL_480_CTRL_POWER |
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: ehci-mx6: Fix broken IO access
Hi Fabio, On 05/02/2012 05:24 PM, Fabio Estevam wrote: > On Wed, May 2, 2012 at 11:36 AM, Wolfgang Grandegger wrote: >> To get USB working again on the i.MX6, this patch fixes a bug introduced >> with commit 522b2a0 "Add proper IO accessors for mx6 usb registers.". > > Good catch on the usb register name change. > >> At that occasion, I also added the missing __iomem directive. > > Is this really needed? As I see it, __iomem is a dummy function in U-Boot. I just added it for consistency reasons. If we remove it, we should also remove all other __iomem's from that file. Maybe somebody else could clarify if __iomem should be used. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB on mx53loco
On 05/02/2012 08:48 PM, Fabio Estevam wrote: > Hi Wolfgang, > > Have you tested USB host functionality on a mx53loco with a Freescale > MC34708 PMIC ? I have a i.MX53 quick start board, which is named in U-Boot and Linux mx53[_]loco. And yes, USB is working. > I can succesfully detect a USB pen drive on a mx53loco board with a > Dialog PMIC, but not on the FSL PMIC version. I need to check, what PMIC my board uses. > I am going to debug this, but just wondering if you have already seen > this issue. See above. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] net: re-enumerating usb-ethernet devices hangs the system
Hi Vincent, as you already know, the re-enumerating of usb ethernet devices (calling "usb start" twice) hangs the system because eth_register() is called more than once. If have found a related patch from you with the subject "eth: remove usb-ethernet devices before re-enumerating them" in the chromium.org git repos. Could that be pushed mainline. Feel free to add my "Tested-by: Wolfgang Grandegger ". Thanks, Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] eth: remove usb-ethernet devices before re-enumerating them
On 01/09/2012 10:08 PM, Vincent Palatin wrote:
> On Mon, Jan 9, 2012 at 12:57, Marek Vasut wrote:
>>> Fix the crash when running several times usb_init() with a USB ethernet
>>> device plugged.
>>>
>>> Signed-off-by: Vincent Palatin
>>> Tested-by: Wolfgang Grandegger
>>> ---
>>> drivers/usb/eth/usb_ether.c |7 +--
>>> include/net.h |1 +
>>> net/eth.c | 29 +
>>> 3 files changed, 35 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/eth/usb_ether.c b/drivers/usb/eth/usb_ether.c
>>> index 6565ea5..73a0790 100644
>>> --- a/drivers/usb/eth/usb_ether.c
>>> +++ b/drivers/usb/eth/usb_ether.c
>>> @@ -127,8 +127,11 @@ int usb_host_eth_scan(int mode)
>>>
>>> old_async = usb_disable_asynch(1); /* asynch transfer not allowed */
>>>
>>> - for (i = 0; i < USB_MAX_ETH_DEV; i++)
>>> - memset(&usb_eth[i], 0, sizeof(usb_eth[i]));
>>> + /* unregister a previously detected device */
>>> + for (i = 0; i < usb_max_eth_dev; i++)
>>> + eth_unregister(&usb_eth[i].eth_dev);
>>> +
>>> + memset(usb_eth, 0, sizeof(usb_eth));
>>>
>>> for (i = 0; prob_dev[i].probe; i++) {
>>> if (prob_dev[i].before_probe)
>>> diff --git a/include/net.h b/include/net.h
>>> index e4d42c2..1707a7f 100644
>>> --- a/include/net.h
>>> +++ b/include/net.h
>>> @@ -96,6 +96,7 @@ struct eth_device {
>>>
>>> extern int eth_initialize(bd_t *bis);/* Initialize network
>>> subsystem
>> */
>>> extern int eth_register(struct eth_device* dev);/* Register network device
>>> */ +extern int eth_unregister(struct eth_device *dev);/* Remove network
>>> device */ extern void eth_try_another(int first_restart); /* Change the
>>> device */ extern void eth_set_current(void); /* set nterface to
>> ethcur
>>> var */ extern struct eth_device *eth_get_dev(void); /* get the current
>>> device MAC */ diff --git a/net/eth.c b/net/eth.c
>>> index b4b9b43..3fb5fb6 100644
>>> --- a/net/eth.c
>>> +++ b/net/eth.c
>>> @@ -224,6 +224,35 @@ int eth_register(struct eth_device *dev)
>>> return 0;
>>> }
>>>
>>> +int eth_unregister(struct eth_device *dev)
>>> +{
>>> + struct eth_device *cur;
>>> +
>>> + /* No device */
>>> + if (!eth_devices)
>>> + return -1;
>>> +
>>> + for (cur = eth_devices; cur->next != eth_devices && cur->next != dev;
>>> + cur = cur->next)
>>> + ;
>>> +
>>> + /* Device not found */
>>> + if (cur->next != dev)
>>> + return -1;
>>> +
>>> + cur->next = dev->next;
>>> +
>>> + if (eth_devices == dev)
>>> + eth_devices = dev->next == eth_devices ? NULL : dev->next;
>>> +
>>> + if (eth_current == dev) {
>>> + eth_current = eth_devices;
>>> + eth_current_changed();
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> int eth_initialize(bd_t *bis)
>>> {
>>> int num_devices = 0;
>>
>> Looks sane. On what hardware did this happen (just for the record)?
>
> I got it on x86 and ARM (tegra2) platforms (both with an EHCI controller).
> I did most of my testing with ASIX-based USB-ethernet dongle, but the
> issue seems pretty generic.
It happens with *any* hardware calling eth_register() more than once
because "struct eth_device *dev*" is memset 0 before calling
eth_register() resulting in an endless loop when scanning the devices.
Viele Grüße,
Wolfgang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i.mx: i.mx6q: add the initial support for i.mx6q Sabre Lite board
On 12/26/2011 08:34 AM, Dirk Behme wrote: > From: Jason Liu > > Add the initial support for Freescale i.MX6Q Sabre Lite board > > Signed-off-by: Dirk Behme > CC: Jason Liu > CC: Eric Nelson > --- ... > Index: freescale-u-boot-imx.git/doc/README.mx6qsabrelite > === > --- /dev/null > +++ freescale-u-boot-imx.git/doc/README.mx6qsabrelite > @@ -0,0 +1,67 @@ > +U-Boot for the Freescale i.MX6q SabreLite board > + > +This file contains information for the port of U-Boot to the Freescale > +i.MX6q SabreLite board. > + > +1. Boot source, boot from SD card > +- > + > +The recent mainline U-Boot for the Freescale i.MX6q SabreLite board supports > +boot from SD card only. However, by default, the early version of SabreLite > +boards boot from the SPI NOR flash. These boards need to be reflashed with > +a small SD card loader to support boot from SD card. This small SD card > loader > +will be flashed into the SPI NOR. The board will still boot from SPI NOR, but > +the loader will in turn request the BootROM to load the U-Boot from SD card. > +At the moment of writing, please check with Freescale on the availablity of > +this small SD loader binary. > + > +To update the SPI-NOR on the SabreLite board without the Freescale > +manufacturing tool use the following procedure: > + > +1. Write this SD card loader onto a large SD card using: > + > + sudo dd if=MX6_SPI_to_SD_loader.bin of=/dev/sXx > + > +Note: Replace sXx with the device representing the SD card in your system. > + > +Note: This writes SD card loader at address 0 > + > +2. Put this SD card into the slot for the large SD card (SD3 on the bottom of > +the board) > + > +3. Power-up the SabreLite, press 'space' to enter command mode in the U-Boot > +(the default one the board is shipped with, starting from the SPI NOR) and > +enter the following commands: > + > + MX6Q SABRELITE U-Boot > mmc dev 0 > + MX6Q SABRELITE U-Boot > mmc read 0x1080 0 200 > + MX6Q SABRELITE U-Boot > sf probe 1 > + MX6Q SABRELITE U-Boot > sf erase 0 0x4 > + MX6Q SABRELITE U-Boot > sf write 0x1080 0 0x4 > + > +4. done. > + > +In case you somehow do not succeed with this procedure you will have to use > +the Freescale manufacturing tool in order to reflash the SPI-NOR. > + > +Note: The board now boots from full size SD3 on the bottom of the board. NOT > + the micro SD4/BOOT slot on the top of the board. I.e. you have to use > + full size SD cards. > + > +This information is taken from > + > +https://wiki.linaro.org/Boards/MX6QSabreLite Where can I find the "SPI_to_SD_loader.bin" image? What means early version of SabreLite boards? How can I select boot from SD-Card on newer versions? And will the u-boot.imx image also boot when loaded to the SPI-NOR fash? Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx6qsabrelite U-Boot from SPI-NOR
Hi Eric, On 01/20/2012 01:56 AM, Eric Nelson wrote: > Hi Wolfgang, > > On 01/19/2012 03:26 AM, Dirk Behme wrote: >> Dear Wolfgang, >> >> On 19.01.2012 10:58, Wolfgang Grandegger wrote: >>> >>> Where can I find the "SPI_to_SD_loader.bin" image? >> >> Unfortunately, at the moment you have to ask your Freescale contact >> for this. We >> ping Freescale since weeks for this. Last time I heard about this >> Freescale >> planned to release this binary under a BSD license. They are still >> "working >> through the licensing details", though :( >> >>> What means early >>> version of SabreLite boards? >> >> Most probably Eric will be able to better answer this. >> > > At this point **all** versions of SabreLite are configured to boot to SPI > NOR through the fuses. > > As Dirk mentioned, we've had some conversations about booting to SD card, > but once the fuse is blown, it's blown. > >> What I understood: Up to now, the boards boot from SPI NOR by default. >> There was >> some _discussion_ to change this to SD boot. Most probably "early >> version" was >> written while this discussion under the impression that later boards >> might >> switch to SD boot. To my understanding the result of this discussion >> was that >> this change would be difficult, though. >> > > We've discussed, but currently have no plans to support a physical switch > to control this decision. This would involve using the "Internal" boot mode > position of SW1 and then pulling a **bunch** of pins high or low to control > the boot flow. > > Note that all of the pins are available on connector J12 (BOOT/EIM), so it > might be done with a small daughter-board. OK, I see. > >>> How can I select boot from SD-Card on newer versions? >> >> To my understanding there are no "newer versions" yet. >> > > Right. > >>> And will the u-boot.imx image also boot when loaded >>> to the SPI-NOR fash? >> >> Hmm, I'm not sure about this as I haven't tested this. >> >> Eric? >> > > Yes. If you program u-boot.imx to offset 0x400, it will boot. > > I just did so as shown below. > > I started by placing SW1 in the 01 position (boot to USB), and > used imx_usb to dowload u-boot.imx: > > MX6QSABRELITE U-Boot > dhcp 1080 192.168.0.112:u-boot.imx > fec_open:Speed=100 > BOOTP broadcast 1 > BOOTP broadcast 2 > DHCP client bound to address 29.6.1.24 > Using FEC device > TFTP from server 192.168.0.112; our IP address is 29.6.1.24; > sending through gateway 29.6.1.1 > Filename 'u-boot.imx'. > Load address: 0x1080 > Loading: # > done > Bytes transferred = 207112 (32908 hex) > MX6QSABRELITE U-Boot > sf write 0x1080 0x400 $filesize But above you used the network to load u-boot.imx. With imx_usb you loaded and booted an image via USB first, I assume. > > > U-Boot 2011.12-00048-g5c30101 (Jan 19 2012 - 17:14:32) > CPU: Freescale i.MX61 family rev1.0 at 792 MHz > Reset cause: POR > Board: MX6Q-Sabre Lite > DRAM: 1 GiB > WARNING: Caches not enabled > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > MMC init failed > Using default environment > > In:serial > Out: serial > Err: serial > Net: FEC > Hit any key to stop autoboot: 0 > MX6QSABRELITE U-Boot > > MX6QSABRELITE U-Boot > > > The imx_usb utility is available here: > http://boundarydevices.com/git?p=imx_usb_loader.git > > It requires libusb-1.0-0-dev to build, but has few other dependencies. > > Usage is simple: hand it the file you want to execute. It will look > at the header to find out where to place the image. > ~/imx_usb_loader$ sudo sudo ./imx_usb u-boot.imx Nice fallback in case the bootloader does not start. I will give it a try a.s.a.p. We actually plan to use a BDI[23]000 for that purpose. >> Please note that Eric is in the process of mainlining the SPI driver for >> i.MX6, atm. > > If you use my latest patch set, you can place the environment in SPI-NOR as > well by commenting out CONFIG_ENV_IS_IN_MMC, and un-commenting > ..._IN_SPI_FLASH > in include/configs/mx6qsabrelite.h. OK, that's already an excellent starting point. Thanks. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mx6qsabrelite: add and enable USB Host 1 support
Cc: Stefano Babic
Cc: Jason Liu
Signed-off-by: Wolfgang Grandegger
---
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 12
include/configs/mx6qsabrelite.h | 15 +++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 4028789..01ecec4 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -77,6 +77,18 @@ static void setup_iomux_uart(void)
imx_iomux_v3_setup_multiple_pads(uart2_pads, ARRAY_SIZE(uart2_pads));
}
+#ifdef CONFIG_USB_EHCI_MX6
+int board_ehci_hcd_init(int port)
+{
+ imx_iomux_v3_setup_multiple_pads(usb_pads, ARRAY_SIZE(usb_pads));
+
+ /* Reset USB hub */
+ gpio_direction_output(204, 0); /* GPIO 7-12 */
+ mdelay(2);
+ gpio_set_value(204, 1);
+}
+#endif
+
#ifdef CONFIG_FSL_ESDHC
struct fsl_esdhc_cfg usdhc_cfg[2] = {
{USDHC3_BASE_ADDR, 1},
diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h
index 464f0ec..7e69734 100644
--- a/include/configs/mx6qsabrelite.h
+++ b/include/configs/mx6qsabrelite.h
@@ -56,6 +56,21 @@
#define CONFIG_CMD_FAT
#define CONFIG_DOS_PARTITION
+#if 1
+/* USB Configs */
+#define CONFIG_CMD_USB
+#define CONFIG_CMD_FAT
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_MX6
+#define CONFIG_USB_STORAGE
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_ASIX
+#define CONFIG_USB_ETHER_SMSC95XX
+#define CONFIG_MXC_USB_PORT1
+#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW)
+#define CONFIG_MXC_USB_FLAGS 0
+#endif
+
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
#define CONFIG_CONS_INDEX 1
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] usb/mx6q: USB EHCI support for MX6Q boards
Wolfgang Grandegger (2): usb/ehci: Add USB support for the MX6Q mx6qsabrelite: add and enable USB Host 1 support arch/arm/cpu/armv7/mx6/clock.c| 13 ++ arch/arm/include/asm/arch-mx6/imx-regs.h |3 + board/freescale/mx6qsabrelite/mx6qsabrelite.c | 12 ++ drivers/usb/host/Makefile |1 + drivers/usb/host/ehci-mx6.c | 205 + include/configs/mx6qsabrelite.h | 15 ++ 6 files changed, 249 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/host/ehci-mx6.c -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] usb/ehci: Add USB support for the MX6Q
Currently, only USB Host 1 is supported.
Cc: Remy Bohmer
Signed-off-by: Wolfgang Grandegger
---
arch/arm/cpu/armv7/mx6/clock.c | 13 ++
arch/arm/include/asm/arch-mx6/imx-regs.h |3 +
drivers/usb/host/Makefile|1 +
drivers/usb/host/ehci-mx6.c | 205 ++
4 files changed, 222 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/host/ehci-mx6.c
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index fa3a124..ef98563 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -36,6 +36,19 @@ enum pll_clocks {
struct imx_ccm_reg *imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
+void enable_usboh3_clk(unsigned char enable)
+{
+ u32 reg;
+
+ reg = __raw_readl(&imx_ccm->CCGR6);
+ if (enable)
+ reg |= MXC_CCM_CCGR_CG_MASK << MXC_CCM_CCGR0_CG0_OFFSET;
+ else
+ reg &= ~(MXC_CCM_CCGR_CG_MASK << MXC_CCM_CCGR0_CG0_OFFSET);
+ __raw_writel(reg, &imx_ccm->CCGR6);
+
+}
+
static u32 decode_pll(enum pll_clocks pll, u32 infreq)
{
u32 div;
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 5227b44..8a5716a 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -111,6 +111,9 @@
#define KPP_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x38000)
#define WDOG1_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x3C000)
#define WDOG2_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x4)
+#define ANATOP_BASE_ADDR(AIPS1_OFF_BASE_ADDR + 0x48000)
+#define USB_PHY0_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x49000)
+#define USB_PHY1_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x4a000)
#define CCM_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x44000)
#define ANATOP_BASE_ADDR(AIPS1_OFF_BASE_ADDR + 0x48000)
#define SNVS_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x4C000)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 77e217f..1b62cc2 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -43,6 +43,7 @@ endif
COBJS-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
COBJS-$(CONFIG_USB_EHCI_MXS) += ehci-mxs.o
COBJS-$(CONFIG_USB_EHCI_MX5) += ehci-mx5.o
+COBJS-$(CONFIG_USB_EHCI_MX6) += ehci-mx6.o
COBJS-$(CONFIG_USB_EHCI_PPC4XX) += ehci-ppc4xx.o
COBJS-$(CONFIG_USB_EHCI_IXP4XX) += ehci-ixp.o
COBJS-$(CONFIG_USB_EHCI_KIRKWOOD) += ehci-kirkwood.o
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
new file mode 100644
index 000..b7bf49d
--- /dev/null
+++ b/drivers/usb/host/ehci-mx6.c
@@ -0,0 +1,205 @@
+/*
+ * Copyright (c) 2009 Daniel Mack
+ * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ehci.h"
+#include "ehci-core.h"
+
+#define USB_OTGREGS_OFFSET 0x000
+#define USB_H1REGS_OFFSET 0x200
+#define USB_H2REGS_OFFSET 0x400
+#define USB_H3REGS_OFFSET 0x600
+#define USB_OTHERREGS_OFFSET 0x800
+
+#define USB_H1_CTRL_OFFSET 0x04
+
+#define USBPHY_CTRL0x0030
+#define USBPHY_CTRL_SET0x0034
+#define USBPHY_CTRL_CLR0x0038
+#define USBPHY_CTRL_TOG0x003c
+
+#define USBPHY_PWD 0x
+#define USBPHY_CTRL_SFTRST 0x8000
+#define USBPHY_CTRL_CLKGATE0x4000
+#define USBPHY_CTRL_ENUTMILEVEL3 0x8000
+#define USBPHY_CTRL_ENUTMILEVEL2 0x4000
+
+#define ANADIG_USB2_CHRG_DETECT0x0210
+#define ANADIG_USB2_CHRG_DETECT_EN_B 0x0010
+#define ANADIG_USB2_CHRG_DETECT_CHK_CHRG_B 0x0008
+
+#define ANADIG_USB2_PLL_480_CTRL 0x0020
+#define ANADIG_USB2_PLL_480_CTRL_SET 0x0024
+#define ANADIG_USB2_PLL_480_CTRL_CLR 0x0028
+#define ANADIG_USB2_PLL_480_CTRL_BYPASS0x0001
+#define ANADIG_USB2_PLL_480_CTRL_ENABLE0x2000
+#define ANADIG_USB2_PLL_480_CTRL_POWER 0x1000
+#define ANADIG_USB2_PLL_480_CTRL_EN_USB_CLKS 0x0040
+
+
+#define UCTRL_OVER_CUR_POL (1 << 8) /* OTG Polarity o
Re: [U-Boot] [PATCH 2/2] mx6qsabrelite: add and enable USB Host 1 support
Hi Dirk,
On 02/09/2012 08:18 AM, Dirk Behme wrote:
> Hi Wolfgang,
>
> On 08.02.2012 16:23, Wolfgang Grandegger wrote:
>> Cc: Stefano Babic
>> Cc: Jason Liu
>> Signed-off-by: Wolfgang Grandegger
>> ---
>> board/freescale/mx6qsabrelite/mx6qsabrelite.c | 12
>> include/configs/mx6qsabrelite.h | 15 +++
>> 2 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
>> b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
>> index 4028789..01ecec4 100644
>> --- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
>> +++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
>> @@ -77,6 +77,18 @@ static void setup_iomux_uart(void)
>> imx_iomux_v3_setup_multiple_pads(uart2_pads,
>> ARRAY_SIZE(uart2_pads));
>> }
>>
>> +#ifdef CONFIG_USB_EHCI_MX6
>> +int board_ehci_hcd_init(int port)
>> +{
>> +imx_iomux_v3_setup_multiple_pads(usb_pads, ARRAY_SIZE(usb_pads));
>
> Where is the definition of 'usb_pads'?
Oops, that hunk gets lost when rebasing to head of u-boot-imx in a hurry:
@@ -122,6 +122,10 @@ iomux_v3_cfg_t enet_pads2[] = {
MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
};
+iomux_v3_cfg_t usb_pads[] = {
+ MX6Q_PAD_GPIO_17__GPIO_7_12 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
static void setup_iomux_enet(void)
{
gpio_direction_output(87, 0); /* GPIO 3-23 */
Will be fixed in v2.
>
> mx6qsabrelite.c: error: 'usb_pads' undeclared (first use in this function)
>
>> +/* Reset USB hub */
>> +gpio_direction_output(204, 0); /* GPIO 7-12 */
>
> With
>
> http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commitdiff;h=7861b0f3eb638df23b992f89229c3b416634b6fa
>
>
> we might want to use something like
>
> gpio_direction_output(GPIO_NUMBER(7, 12), 0);
OK, unfortunately, that file is full of such calls using the
number directly ==> seperate patch.
> ?
>
> Same below for gpio_set_value() ?
>
>> +mdelay(2);
>> +gpio_set_value(204, 1);
>> +}
>
> mx6qsabrelite.c: warning: no return statement in function returning
> non-void
Puh, v1 is obviously crap... will send v2 in a second, sorry.
Wolfgang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] usb/mx6q: USB EHCI support for MX6Q boards
v1 was bad, sorry. v2 fixes various issues reported by Dirk and Fabio. The patches are based on head of Stefano's "u-boot-imx" tree. Wolfgang Wolfgang Grandegger (2): usb/ehci: Add USB support for the MX6Q mx6qsabrelite: add and enable USB Host 1 support arch/arm/cpu/armv7/mx6/clock.c| 13 ++ arch/arm/include/asm/arch-mx6/clock.h |1 + arch/arm/include/asm/arch-mx6/imx-regs.h |3 + board/freescale/mx6qsabrelite/mx6qsabrelite.c | 18 +++ drivers/usb/host/Makefile |1 + drivers/usb/host/ehci-mx6.c | 205 + include/configs/mx6qsabrelite.h | 13 ++ 7 files changed, 254 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/host/ehci-mx6.c -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] mx6qsabrelite: add and enable USB Host 1 support
Cc: Stefano Babic
Cc: Jason Liu
Signed-off-by: Wolfgang Grandegger
---
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 18 ++
include/configs/mx6qsabrelite.h | 13 +
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 03a088a..67e46d4 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -140,12 +140,30 @@ static void setup_iomux_enet(void)
imx_iomux_v3_setup_multiple_pads(enet_pads2, ARRAY_SIZE(enet_pads2));
}
+iomux_v3_cfg_t usb_pads[] = {
+ MX6Q_PAD_GPIO_17__GPIO_7_12 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
static void setup_iomux_uart(void)
{
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
imx_iomux_v3_setup_multiple_pads(uart2_pads, ARRAY_SIZE(uart2_pads));
}
+#ifdef CONFIG_USB_EHCI_MX6
+int board_ehci_hcd_init(int port)
+{
+ imx_iomux_v3_setup_multiple_pads(usb_pads, ARRAY_SIZE(usb_pads));
+
+ /* Reset USB hub */
+ gpio_direction_output(GPIO_NUMBER(7, 12), 0);
+ mdelay(2);
+ gpio_set_value(GPIO_NUMBER(7, 12), 1);
+
+ return 0;
+}
+#endif
+
#ifdef CONFIG_FSL_ESDHC
struct fsl_esdhc_cfg usdhc_cfg[2] = {
{USDHC3_BASE_ADDR, 1},
diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h
index 8a95af9..bbd6024 100644
--- a/include/configs/mx6qsabrelite.h
+++ b/include/configs/mx6qsabrelite.h
@@ -78,6 +78,19 @@
#define CONFIG_ETHPRIME"FEC"
#define CONFIG_FEC_MXC_PHYADDR 6
+/* USB Configs */
+#define CONFIG_CMD_USB
+#define CONFIG_CMD_FAT
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_MX6
+#define CONFIG_USB_STORAGE
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_ASIX
+#define CONFIG_USB_ETHER_SMSC95XX
+#define CONFIG_MXC_USB_PORT1
+#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW)
+#define CONFIG_MXC_USB_FLAGS 0
+
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
#define CONFIG_CONS_INDEX 1
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] usb/ehci: Add USB support for the MX6Q
Currently, only USB Host 1 is supported.
Cc: Remy Bohmer
Signed-off-by: Wolfgang Grandegger
---
arch/arm/cpu/armv7/mx6/clock.c | 13 ++
arch/arm/include/asm/arch-mx6/clock.h|1 +
arch/arm/include/asm/arch-mx6/imx-regs.h |3 +
drivers/usb/host/Makefile|1 +
drivers/usb/host/ehci-mx6.c | 205 ++
5 files changed, 223 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/host/ehci-mx6.c
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index fa3a124..ef98563 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -36,6 +36,19 @@ enum pll_clocks {
struct imx_ccm_reg *imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
+void enable_usboh3_clk(unsigned char enable)
+{
+ u32 reg;
+
+ reg = __raw_readl(&imx_ccm->CCGR6);
+ if (enable)
+ reg |= MXC_CCM_CCGR_CG_MASK << MXC_CCM_CCGR0_CG0_OFFSET;
+ else
+ reg &= ~(MXC_CCM_CCGR_CG_MASK << MXC_CCM_CCGR0_CG0_OFFSET);
+ __raw_writel(reg, &imx_ccm->CCGR6);
+
+}
+
static u32 decode_pll(enum pll_clocks pll, u32 infreq)
{
u32 div;
diff --git a/arch/arm/include/asm/arch-mx6/clock.h
b/arch/arm/include/asm/arch-mx6/clock.h
index 636458f..613809b 100644
--- a/arch/arm/include/asm/arch-mx6/clock.h
+++ b/arch/arm/include/asm/arch-mx6/clock.h
@@ -46,5 +46,6 @@ enum mxc_clock {
u32 imx_get_uartclk(void);
u32 imx_get_fecclk(void);
unsigned int mxc_get_clock(enum mxc_clock clk);
+void enable_usboh3_clk(unsigned char enable);
#endif /* __ASM_ARCH_CLOCK_H */
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 3b5fd25..2bfe891 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -111,6 +111,9 @@
#define KPP_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x38000)
#define WDOG1_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x3C000)
#define WDOG2_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x4)
+#define ANATOP_BASE_ADDR(AIPS1_OFF_BASE_ADDR + 0x48000)
+#define USB_PHY0_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x49000)
+#define USB_PHY1_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x4a000)
#define CCM_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x44000)
#define ANATOP_BASE_ADDR(AIPS1_OFF_BASE_ADDR + 0x48000)
#define SNVS_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x4C000)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 77e217f..1b62cc2 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -43,6 +43,7 @@ endif
COBJS-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
COBJS-$(CONFIG_USB_EHCI_MXS) += ehci-mxs.o
COBJS-$(CONFIG_USB_EHCI_MX5) += ehci-mx5.o
+COBJS-$(CONFIG_USB_EHCI_MX6) += ehci-mx6.o
COBJS-$(CONFIG_USB_EHCI_PPC4XX) += ehci-ppc4xx.o
COBJS-$(CONFIG_USB_EHCI_IXP4XX) += ehci-ixp.o
COBJS-$(CONFIG_USB_EHCI_KIRKWOOD) += ehci-kirkwood.o
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
new file mode 100644
index 000..b7bf49d
--- /dev/null
+++ b/drivers/usb/host/ehci-mx6.c
@@ -0,0 +1,205 @@
+/*
+ * Copyright (c) 2009 Daniel Mack
+ * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ehci.h"
+#include "ehci-core.h"
+
+#define USB_OTGREGS_OFFSET 0x000
+#define USB_H1REGS_OFFSET 0x200
+#define USB_H2REGS_OFFSET 0x400
+#define USB_H3REGS_OFFSET 0x600
+#define USB_OTHERREGS_OFFSET 0x800
+
+#define USB_H1_CTRL_OFFSET 0x04
+
+#define USBPHY_CTRL0x0030
+#define USBPHY_CTRL_SET0x0034
+#define USBPHY_CTRL_CLR0x0038
+#define USBPHY_CTRL_TOG0x003c
+
+#define USBPHY_PWD 0x
+#define USBPHY_CTRL_SFTRST 0x8000
+#define USBPHY_CTRL_CLKGATE0x4000
+#define USBPHY_CTRL_ENUTMILEVEL3 0x8000
+#define USBPHY_CTRL_ENUTMILEVEL2 0x4000
+
+#define ANADIG_USB2_CHRG_DETECT0x0210
+#define ANADIG_USB2_CHRG_DETECT_EN_B 0x0010
+#define ANADIG_USB2_CHRG_DETECT_CHK_CHRG_B 0x0008
+
+#define ANADIG_U
Re: [U-Boot] [PATCH v2 1/2] usb/ehci: Add USB support for the MX6Q
Hi Marek,
On 02/11/2012 08:12 AM, Marek Vasut wrote:
>> Currently, only USB Host 1 is supported.
>
> Hi,
>
> this resembles mx28 USBH ... or am I wrong? Can't these be coalesced together?
Good point. The MX6Q seems to be some kind of clone of the MX28, indeed.
Not only for USB but also for FEC and likely other interfaces as well.
> btw Fabio, do we support mx6q USB host in mainline Linux ?
>
>>
>> Cc: Remy Bohmer
>> Signed-off-by: Wolfgang Grandegger
>> ---
>> arch/arm/cpu/armv7/mx6/clock.c | 13 ++
>> arch/arm/include/asm/arch-mx6/clock.h|1 +
>> arch/arm/include/asm/arch-mx6/imx-regs.h |3 +
>> drivers/usb/host/Makefile|1 +
>> drivers/usb/host/ehci-mx6.c | 205
>> ++ 5 files changed, 223 insertions(+), 0
>> deletions(-)
>> create mode 100644 drivers/usb/host/ehci-mx6.c
>>
>> diff --git a/arch/arm/cpu/armv7/mx6/clock.c
>> b/arch/arm/cpu/armv7/mx6/clock.c index fa3a124..ef98563 100644
>> --- a/arch/arm/cpu/armv7/mx6/clock.c
>> +++ b/arch/arm/cpu/armv7/mx6/clock.c
>> @@ -36,6 +36,19 @@ enum pll_clocks {
>>
>> struct imx_ccm_reg *imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
>>
>> +void enable_usboh3_clk(unsigned char enable)
>> +{
>> +u32 reg;
>> +
>> +reg = __raw_readl(&imx_ccm->CCGR6);
>> +if (enable)
>> +reg |= MXC_CCM_CCGR_CG_MASK << MXC_CCM_CCGR0_CG0_OFFSET;
>> +else
>> +reg &= ~(MXC_CCM_CCGR_CG_MASK << MXC_CCM_CCGR0_CG0_OFFSET);
>> +__raw_writel(reg, &imx_ccm->CCGR6);
>> +
>> +}
>> +
>> static u32 decode_pll(enum pll_clocks pll, u32 infreq)
>> {
>> u32 div;
>> diff --git a/arch/arm/include/asm/arch-mx6/clock.h
>> b/arch/arm/include/asm/arch-mx6/clock.h index 636458f..613809b 100644
>> --- a/arch/arm/include/asm/arch-mx6/clock.h
>> +++ b/arch/arm/include/asm/arch-mx6/clock.h
>> @@ -46,5 +46,6 @@ enum mxc_clock {
>> u32 imx_get_uartclk(void);
>> u32 imx_get_fecclk(void);
>> unsigned int mxc_get_clock(enum mxc_clock clk);
>> +void enable_usboh3_clk(unsigned char enable);
>>
>> #endif /* __ASM_ARCH_CLOCK_H */
>> diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
>> b/arch/arm/include/asm/arch-mx6/imx-regs.h index 3b5fd25..2bfe891 100644
>> --- a/arch/arm/include/asm/arch-mx6/imx-regs.h
>> +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
>> @@ -111,6 +111,9 @@
>> #define KPP_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x38000)
>> #define WDOG1_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x3C000)
>> #define WDOG2_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x4)
>> +#define ANATOP_BASE_ADDR(AIPS1_OFF_BASE_ADDR + 0x48000)
>> +#define USB_PHY0_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x49000)
>> +#define USB_PHY1_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x4a000)
>> #define CCM_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x44000)
>> #define ANATOP_BASE_ADDR(AIPS1_OFF_BASE_ADDR + 0x48000)
>> #define SNVS_BASE_ADDR (AIPS1_OFF_BASE_ADDR + 0x4C000)
>> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
>> index 77e217f..1b62cc2 100644
>> --- a/drivers/usb/host/Makefile
>> +++ b/drivers/usb/host/Makefile
>> @@ -43,6 +43,7 @@ endif
>> COBJS-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
>> COBJS-$(CONFIG_USB_EHCI_MXS) += ehci-mxs.o
>> COBJS-$(CONFIG_USB_EHCI_MX5) += ehci-mx5.o
>> +COBJS-$(CONFIG_USB_EHCI_MX6) += ehci-mx6.o
>> COBJS-$(CONFIG_USB_EHCI_PPC4XX) += ehci-ppc4xx.o
>> COBJS-$(CONFIG_USB_EHCI_IXP4XX) += ehci-ixp.o
>> COBJS-$(CONFIG_USB_EHCI_KIRKWOOD) += ehci-kirkwood.o
>> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
>> new file mode 100644
>> index 000..b7bf49d
>> --- /dev/null
>> +++ b/drivers/usb/host/ehci-mx6.c
>> @@ -0,0 +1,205 @@
>> +/*
>> + * Copyright (c) 2009 Daniel Mack
>> + * Copyright (C) 2010 Freescale Semiconductor, Inc.
>> + *
>> + * 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
[U-Boot] mx6: consolidating and extending anadig/analog/anatop register defs
Hello, for the USB support on MX6Q, I'm trying to consolidate and extend the register definitions for the ANADIG registers. Unfortunately, three different names are used for the same registers: ANADIG, analog and ANATOP. Any idea what the names do stand for and what would be the most appropriate one. Apart from that, we should have a separate structure and header file for these registers. Currently, they are added to the CCM regs. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx6: consolidating and extending anadig/analog/anatop register defs
Hi Marek, On 02/14/2012 01:37 PM, Marek Vasut wrote: >> Hi, Wolfgang, >> >>> -Original Message- >>> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] >>> On Behalf Of Wolfgang Grandegger >>> Sent: Monday, February 13, 2012 8:08 PM >>> To: U-Boot >>> Subject: [U-Boot] mx6: consolidating and extending anadig/analog/anatop >>> register defs >>> >>> Hello, >>> >>> for the USB support on MX6Q, I'm trying to consolidate and extend the >>> register definitions for the ANADIG registers. Unfortunately, three >>> different names are used for the same registers: ANADIG, analog and >>> ANATOP. Any idea what the names do stand for and what would be the most >>> appropriate one. Apart from that, we should have a separate structure and >>> header file for these registers. Currently, they are added to the CCM >>> regs. >> >> The register definition in the CCM according to the RM as followings: >> Addresses: CCM_analog_PLL_SYS is 0h base + 0h offset = _h >> CCM_analog_PLL_SYS_SET is 0h base + 4h offset = _0004h >> CCM_analog_PLL_SYS_CLR is 0h base + 8h offset = _0008h >> CCM_analog_PLL_SYS_TOG is 0h base + Ch offset = _000Ch >> >> Thus, I put the register definition into the CCM parts. > > This again resembles MX28 ... damn, can't we share some parts of MX28 for > MX6Q ? > > Fabio, I think I'll need one too, this is getting weird ;-) Unfortunately, I did not get hold of a RM yet :(. It's still under NDA, I believe. Therefore I will postpone my "consolidation" activities for the time being. The USB support patch I sent does work, as Dirk confirmed, and therefore I suggest to apply it as intermediate solution. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx6: consolidating and extending anadig/analog/anatop register defs
On 02/14/2012 02:07 PM, Marek Vasut wrote: >> Hi Marek, >> >> On 02/14/2012 01:37 PM, Marek Vasut wrote: >>>> Hi, Wolfgang, >>>> >>>>> -Original Message- >>>>> From: u-boot-boun...@lists.denx.de >>>>> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang >>>>> Grandegger Sent: Monday, February 13, 2012 8:08 PM >>>>> To: U-Boot >>>>> Subject: [U-Boot] mx6: consolidating and extending >>>>> anadig/analog/anatop register defs >>>>> >>>>> Hello, >>>>> >>>>> for the USB support on MX6Q, I'm trying to consolidate and extend >>>>> the register definitions for the ANADIG registers. Unfortunately, >>>>> three different names are used for the same registers: ANADIG, >>>>> analog and ANATOP. Any idea what the names do stand for and what >>>>> would be the most appropriate one. Apart from that, we should have >>>>> a separate structure and header file for these registers. >>>>> Currently, they are added to the CCM regs. >>>> >>>> The register definition in the CCM according to the RM as followings: >>>> Addresses: CCM_analog_PLL_SYS is 0h base + 0h offset = _h >>>> CCM_analog_PLL_SYS_SET is 0h base + 4h offset = _0004h >>>> CCM_analog_PLL_SYS_CLR is 0h base + 8h offset = _0008h >>>> CCM_analog_PLL_SYS_TOG is 0h base + Ch offset = _000Ch >>>> >>>> Thus, I put the register definition into the CCM parts. >>> >>> This again resembles MX28 ... damn, can't we share some parts of MX28 >>> for MX6Q ? >>> >>> Fabio, I think I'll need one too, this is getting weird ;-) >> >> Unfortunately, I did not get hold of a RM yet :(. > > RM? Who's that? Reference Manual! > It's still under NDA, >> I believe. Therefore I will postpone my "consolidation" activities for >> the time being. > > Sorry, I don't intent to hinder your efforts, I'm just seeing a pattern :) > > The USB support patch I sent does work, as Dirk >> confirmed, and therefore I suggest to apply it as intermediate solution. > > Well ... All right then. Though my sense for perfect solution is hurting a > lot ;-) Well, that's OK and I realized some kind of mess as well, which should be fixed sooner than later. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] MX5x USB support
Hi Marek, On 12/07/2011 07:33 PM, Marek Vasut wrote: > This patchset adds the USB support for MX5x. Most of the code is based on work > of Wolfgang Grandegger with modifications done by various other authors. I > also > included version of ULPI support code cleaned up by Igor Grinberg. > > NOTE: I'd really love to get this code into .12 release. Remy, Wolfgang, do > you > think it'd be possible? I'd really help adoption of the MX5x USB code greatly > as > well as cleanup of the ULPI code (which is sadly in a bad shape). I will have time for a review and testing tomorrow. Anyway, we need some feedback from the USB maintainer to get these patches accepted. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci: speed up initialization
On 12/10/2011 05:29 PM, Remy Bohmer wrote: > Hi, > > 2011/12/5 Vincent Palatin : >> According to EHCI specification v1.0, the controller should stabilize >> the power on a port at most 20 ms after the port power bit transition. >> So, we put this setting in the virtual descriptor corresponding field, >> (bPwrOn2PwrGood = 10 => 10 x 2ms = 20ms), this saves about 500ms at each >> controller initialization/enumeration. >> >> Signed-off-by: Vincent Palatin >> --- >> drivers/usb/host/ehci-hcd.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) > > Applied to u-boot-usb. I just realized that this patch breaks "usb start" on my mx53loco board: MX53LOCO U-Boot > usb start (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 1 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 0 Ethernet Device(s) found MX53LOCO U-Boot > usb start (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 1 Ethernet Device(s) found The device is not found at the first attempt. Obviously, a value of 10 for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a resonable compromise? If yes, I could send a patch. Wolfgang. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci: speed up initialization
On 12/19/2011 01:51 PM, Vincent Palatin wrote: > On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger > wrote: >> I just realized that this patch breaks "usb start" on my mx53loco board: >> >> MX53LOCO U-Boot > usb start >> (Re)start USB... >> USB: Register 10011 NbrPorts 1 >> USB EHCI 1.00 >> scanning bus for devices... 1 USB Device(s) found >> scanning bus for storage devices... 0 Storage Device(s) found >> scanning bus for ethernet devices... 0 Ethernet Device(s) found >> >> MX53LOCO U-Boot > usb start >> (Re)start USB... >> USB: Register 10011 NbrPorts 1 >> USB EHCI 1.00 >> scanning bus for devices... 2 USB Device(s) found >> scanning bus for storage devices... 0 Storage Device(s) found >> scanning bus for ethernet devices... 1 Ethernet Device(s) found >> >> The device is not found at the first attempt. Obviously, a value of 10 >> for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a >> resonable compromise? If yes, I could send a patch. > > This doesn't match the EHCI standard which explicity states that the > power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we > should probably find whether we are missing another delay somewhere in > the generic EHCI code (which used to be hidden and should be fixed) or > if i.MX53 is not compliant with the standard and need a special quirk. I'm not an USB expert but if I look into the hub_power_on() function of the Linux kernel it waits at least 100ms (and only once). See: http://lxr.linux.no/#linux+v3.1.5/drivers/usb/core/hub.c#L567 Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci: speed up initialization
On 12/19/2011 05:59 PM, Remy Bohmer wrote: > Hi Wolfgang, > > 2011/12/19 Wolfgang Grandegger : >> On 12/19/2011 01:51 PM, Vincent Palatin wrote: >>> On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger >>> wrote: >>>> I just realized that this patch breaks "usb start" on my mx53loco board: >>>> >>>> The device is not found at the first attempt. Obviously, a value of 10 >>>> for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a >>>> resonable compromise? If yes, I could send a patch. >>> >>> This doesn't match the EHCI standard which explicity states that the >>> power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we >>> should probably find whether we are missing another delay somewhere in >>> the generic EHCI code (which used to be hidden and should be fixed) or >>> if i.MX53 is not compliant with the standard and need a special quirk. >> >> I'm not an USB expert but if I look into the hub_power_on() function of >> the Linux kernel it waits at least 100ms (and only once). See: >> >> http://lxr.linux.no/#linux+v3.1.5/drivers/usb/core/hub.c#L567 > > I would prefer a solution in line with the specification, but what is > the reason why Linux takes 100 msec here? > Is that just chosen randomly , or was there a good reason for it? > If there is a good reason (which I assume) I would prefer to follow > Linux here and go for the 100 msec. > > Can you please provide a patch? OK, should find time tomorrow. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] USB: relax usbcore reset timings
From: Wolfgang Grandegger
Following the corresponding Linux code, this patch relaxes reset timings
waiting at least 100ms after power to the ports. There are some reports
that it helps make enumeration work better on some high speed devices.
Furthermore, the wait is only done once after power has been enabled
on all ports.
CC: Remy Bohmer
CC: Vincent Palatin
Signed-off-by: Wolfgang Grandegger
---
common/usb.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index 63a11c8..d13dab8 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1035,6 +1035,7 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
{
int i;
struct usb_device *dev;
+ unsigned pgood_delay = hub->desc.bPwrOn2PwrGood * 2;
dev = hub->pusb_dev;
/* Enable power to the ports */
@@ -1042,8 +1043,10 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
for (i = 0; i < dev->maxchild; i++) {
usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
USB_HUB_PRINTF("port %d returns %lX\n", i + 1, dev->status);
- wait_ms(hub->desc.bPwrOn2PwrGood * 2);
}
+
+ /* Wait at least 100 msec for power to become stable */
+ wait_ms(max(pgood_delay, (unsigned)100));
}
void usb_hub_reset(void)
--
1.7.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] i.MX6Q SabreLite: Ethernet does not work at Gigabit speed
Hi, I just realized that I cannot download files on a Gitabit Ethernet network. I'm getting timeouts: MX6QSABRELITE U-Boot > boot Using FEC device TFTP from server 172.16.0.1; our IP address is 172.16.0.100 Filename 'wolf/uImage-mx6q-mainline'. Load address: 0x1080 Loading: error frame: 0x4fd76ca0 0x0804 T error frame: 0x4fd77f00 0x0804 Before I start digging, is this a known issue? Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6Q SabreLite: Ethernet does not work at Gigabit speed
Hi Troy, On 06/28/2012 07:48 PM, Troy Kisky wrote: > On 6/28/2012 8:33 AM, Eric Nelson wrote: >> On 06/28/2012 06:50 AM, Wolfgang Grandegger wrote: >>> Hi, >>> >>> I just realized that I cannot download files on a Gitabit Ethernet >>> network. I'm getting timeouts: >>> >>>MX6QSABRELITE U-Boot> boot >>>Using FEC device >>>TFTP from server 172.16.0.1; our IP address is 172.16.0.100 >>>Filename 'wolf/uImage-mx6q-mainline'. >>>Load address: 0x1080 >>>Loading: error frame: 0x4fd76ca0 0x0804 >>>T error frame: 0x4fd77f00 0x0804 >>> >>> >>> Before I start digging, is this a known issue? > Also, I recently posted a patch for mainline u-boot. > I'll repost with you and Joe Hershberger in cc. Thanks for the patch. It help to some extend but I'm still getting timeouts. I need to fix the hardware as well, as Eric suggested. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc52xx/motionpro: fix monitor size and update default environment
Since a while, the size of the u-boot.bin image is larger than
256kB. This requires moving the environment sectors by one. As
we are at it, we also update a few other custom settings.
Signed-off-by: Wolfgang Grandegger
---
include/configs/motionpro.h | 44 +-
1 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/include/configs/motionpro.h b/include/configs/motionpro.h
index f6a4497..1e19ffa 100644
--- a/include/configs/motionpro.h
+++ b/include/configs/motionpro.h
@@ -2,7 +2,7 @@
* (C) Copyright 2003-2007
* Wolfgang Denk, DENX Software Engineering, w...@denx.de.
*
- * Based on PRO Motion board config file by Andy Joseph, a...@promessdev.com
+ * Based on Motion-PRO board config file by Robert McCullough,
r...@promessinc.com
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -100,6 +100,7 @@
#define CONFIG_CMDLINE_EDITING 1 /* add command line history
*/
#defineCONFIG_SYS_HUSH_PARSER 1 /* use "hush" command
parser*/
+#defineCONFIG_SYS_PROMPT_HUSH_PS2 "> "
#define CONFIG_ETHADDR 00:50:C2:40:10:00
#define CONFIG_OVERWRITE_ETHADDR_ONCE 1
@@ -111,21 +112,21 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"netdev=eth0\0" \
"hostname=motionpro\0" \
- "netmask=255.255.0.0\0" \
- "ipaddr=192.168.160.22\0" \
- "serverip=192.168.1.1\0"\
- "gatewayip=192.168.1.1\0" \
+ "netmask=255.255.255.0\0" \
+ "ipaddr=192.168.1.106\0"\
+ "serverip=192.168.1.100\0" \
+ "gatewayip=192.168.1.100\0" \
"console=ttyPSC0,115200\0" \
"u-boot_addr=40\0" \
"kernel_addr=40\0" \
"fdt_addr=70\0" \
"ramdisk_addr=80\0" \
"multi_image_addr=80\0" \
- "rootpath=/opt/eldk/ppc_6xx\0" \
- "u-boot=motionpro/u-boot.bin\0" \
- "bootfile=motionpro/uImage\0" \
- "fdt_file=motionpro/motionpro.dtb\0"\
- "ramdisk_file=motionpro/uRamdisk\0" \
+ "rootpath=/opt/eldk-4.2/ppc_6xx\0" \
+ "u-boot=/tftpboot/motionpro/u-boot.bin\0" \
+ "bootfile=/tftpboot/motionpro/uImage\0" \
+ "fdt_file=/tftpboot/motionpro/motionpro.dtb\0" \
+ "ramdisk_file=/tftpboot/motionpro/uRamdisk\0" \
"multi_image_file=kernel+initrd+dtb.img\0" \
"load=tftp ${u-boot_addr} ${u-boot}\0" \
"update=prot off fff0 +${filesize};"\
@@ -135,25 +136,32 @@
"ramargs=setenv bootargs root=/dev/ram rw\0"\
"nfsargs=setenv bootargs root=/dev/nfs rw " \
"nfsroot=${serverip}:${rootpath}\0" \
- "fat_args=setenv bootargs rw\0" \
- "addmtd=setenv bootargs ${bootargs} ${mtdparts}\0" \
+ "fat_args=setenv bootargs root=/dev/sda rw\0" \
+ "mtdids=nor0=ff00.flash\0" \
+ "mtdparts=ff00.flash:13m(fs),2m(kernel),384k(uboot)," \
+ "128k(env),128k(redund_env)," \
+ "128k(dtb),128k(user_data)\0" \
+ "addcons=setenv bootargs ${bootargs} console=${console}\0" \
+ "addmtd=setenv bootargs ${bootargs} mtdparts=${mtdparts}\0" \
"addip=setenv bootargs ${bootargs} "\
"ip=${ipaddr}:${serverip}:${gatewayip}:"\
Re: [U-Boot] [PATCH] USB: relax usbcore reset timings
On 02/27/2012 12:10 AM, Marek Vasut wrote: >> From: Wolfgang Grandegger >> >> Following the corresponding Linux code, this patch relaxes reset timings >> waiting at least 100ms after power to the ports. There are some reports >> that it helps make enumeration work better on some high speed devices. >> Furthermore, the wait is only done once after power has been enabled >> on all ports. >> >> CC: Remy Bohmer >> CC: Vincent Palatin >> Signed-off-by: Wolfgang Grandegger >> --- > > Hi, > > what's the status of this patch/patchset? Already a while ago Remy wrote "Applied to u-boot-usb" but I can't find it yet in mainline. Remy? Wolfgang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6: mx6q_sabrelite: add SATA bindings
On 03/03/2012 05:09 PM, Eric Nelson wrote: > On 03/03/2012 02:00 AM, Stefano Babic wrote: >> On 03/03/2012 01:46, Eric Nelson wrote: >>> This patch requires Stefano's driver for MX5/MX6. >>> http://lists.denx.de/pipermail/u-boot/2012-February/118530.html >> >> This is helpful, but should be not part of the commit message that is >> stored in git. Move all additional info after the "---" line. >> >>> >>> Signed-off-by: Eric Nelson >>> --- >>> arch/arm/include/asm/arch-mx6/imx-regs.h | 11 + >>> board/freescale/mx6qsabrelite/mx6qsabrelite.c | 54 >>> + >>> include/configs/mx6qsabrelite.h | 13 ++ >>> 3 files changed, 78 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h >>> b/arch/arm/include/asm/arch-mx6/imx-regs.h >>> index 3e5c4c2..2441434 100644 >>> --- a/arch/arm/include/asm/arch-mx6/imx-regs.h >>> +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h >>> @@ -165,6 +165,17 @@ >>> #define IP2APB_USBPHY1_BASE_ADDR(AIPS2_OFF_BASE_ADDR + 0x78000) >>> #define IP2APB_USBPHY2_BASE_ADDR(AIPS2_OFF_BASE_ADDR + 0x7C000) >>> >>> +/* >>> + * ANATOP register definitions >>> + */ >>> +#define ANATOP_PLL_LOCK 0x8000 >>> +#define ANATOP_PLL_ENABLE_MASK 0x2000 >>> +#define ANATOP_PLL_BYPASS_MASK 0x0001 >>> +#define ANATOP_PLL_LOCK 0x8000 >>> +#define ANATOP_PLL_PWDN_MASK0x1000 >>> +#define ANATOP_PLL_HOLD_RING_OFF_MASK 0x0800 >>> +#define ANATOP_SATA_CLK_ENABLE_MASK 0x0010 >> >> There is already a thread initiated by Wolfgang regarding the ANATOP >> registers: >> >> http://lists.denx.de/pipermail/u-boot/2012-February/117942.html >> >> I think we need in any case a way to consolitate this stuff, even if >> decided to postpone this activity >> > > Thanks. I saw that but seem to have forgotten it. Most, if not all, definitions above are already defined in arch/arm/include/asm/arch-mx6/ccm_regs.h including a struct member. Therefore there's also no need for magic offsets. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mx6: Read silicon revision from register
Hi Fabio, On 03/14/2012 11:24 AM, Fabio Estevam wrote: > On Wed, Mar 14, 2012 at 3:09 AM, Liu Hui-R64343 wrote: > >> I'm afraid whether this is correct to add it here since some registers of >> anatop was included into the ccm_reg. >> >> ANATOP is a collection of analog and anadig. So, ANATOP register mostly is >> consist of 4 parts: >> >> ANADIG in CCM: for example: PLL/PFD, >> ANAREG in power: internal analog regulator, power tree. >> ANAUSB in usb: for usb vbus dection, charge, etc. >> ANAMISC: misc feature, only one register now for the Chip Silicon Version >> >> So the siliconid is in the last register. > > In the mx6 reference manual version I have I cannot find all the > fields you mentioned. > > Can you send me offline the anatop register layout so that I can > complete this structure? I think "arch/arm/mach-mx6/regs-anadig.h" from Freescale's 2.6.38 kernel tree does define the register layout. Do you have that file? Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ppc4xx/next
Hi Stefan, Stefan Roese wrote: > Hi Matthias, > > On Wednesday 11 November 2009 22:12:06 Matthias Fuchs wrote: >>> please pull some updates for "next". Thanks. >>> >>> >>> The following changes since commit >>> cd12f615e4dd1dd24caab93f4157894783c6c1c0: Wolfgang Grandegger (1): >>> mpc52xx: add support for the IPEK01 board >>> >>> are available in the git repository at: >>> >>> git://www.denx.de/git/u-boot-ppc4xx.git next >>> >>> Matthias Fuchs (1): >>> ppc4xx: Add UBI support to PLU405 boards >> What happened to the others? ".. init coupler..." etc. > > As you know, these patches depend on the sja1000 CAN header: > > [PATCH 1/2] Add minimal SJA1000 header for basic CAN mode > > And I'm not sure what the current status of this header is. Wolfgang > Grandegger (added to Cc) also introduced some new CAN stuff. We don't want to > add multiple headers of course. My stuff was sent as RFC. It's on hold now as there was little feedback. > So how should we continue here? I understand that your patches depending on > this sja1000 header are bugfixes: > > [PATCH 2/2 V3] ppc4xx: Initialize magnetic couplers in PLU405 > [PATCH] ppc4xx: Initialize magnetic coupler on VOM405 boards > > And you introduced this header on the explicit proposal from Wolfgang Denk. > So > I would vote for adding your bug fix patches with your sja1000 header right > now. We should remove this header again, when the CAN support from Wolfgang > Grandegger hits mainline. Yep. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fsl_i2c: increase I2C timeout values and make them configurable
Detlev Zundel wrote: > Hi Timur, > >> Joakim Tjernlund wrote: >> >>> This will generate the same divisor tables as AN2919, tables 6-9. >>> I do not take condition 2 into consideration as it not clear how to >>> deal with it and it does not seem to have an significant impact. >>> >>> What do you think? >> I really don't have time to deal with it right now. Sorry. > > Wolfgang (I put him on CC) was the last to propose such an algorithm > IIRC. So maybe he has an opinion? I did not follow the thread yet, sorry. I implemented AN2819 for Linux (see http://lxr.linux.no/#linux+v2.6.31/drivers/i2c/busses/i2c-mpc.c) some time ago using Timur's table approach. But there is no difference between the table and the algorithm to calculate the value. The table is actually derived from the same algorithm. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fsl_i2c: increase I2C timeout values and make them configurable
Timur Tabi wrote: > Wolfgang Grandegger wrote: > >> I did not follow the thread yet, sorry. I implemented AN2819 for Linux >> (see http://lxr.linux.no/#linux+v2.6.31/drivers/i2c/busses/i2c-mpc.c) >> some time ago using Timur's table approach. But there is no difference >> between the table and the algorithm to calculate the value. The table is >> actually derived from the same algorithm. > > The problem with the table is that it does not allow for flexibility in > choosing dfsr. When I implemented the table code, I did not think that this > was a problem, but apparently it is. What would be the criteria to choose dfsr, especially for a defined bus frequency. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fsl_i2c: increase I2C timeout values and make them configurable
Joakim Tjernlund wrote: >> Wolfgang Grandegger wrote: >> >>> I did not follow the thread yet, sorry. I implemented AN2819 for Linux >>> (see http://lxr.linux.no/#linux+v2.6.31/drivers/i2c/busses/i2c-mpc.c) >>> some time ago using Timur's table approach. But there is no difference >>> between the table and the algorithm to calculate the value. The table is >>> actually derived from the same algorithm. >> The problem with the table is that it does not allow for flexibility in >> choosing dfsr. When I implemented the table code, I did not think that this >> was a problem, but apparently it is. > > Yes, it is a problem for us as our board is out of spec. The rise time is way > off > spec. By trial and error with the DFSR/FDR I managed to get a stable > connection. > What is less funny though is that I need to program FDR/DFSR differently > in u-boot resp. kernel. to make it work. > I suspect it is due to kernel being IRQ driven and has longer pause > between chars, but it is a guess. > > In any case, the revised AN2819 dictates a different algorithm but I feel > it is a bit incomplete w.r.t Condition 2: > > • Condition 2: B × T ≥ tI2CRM + 3 × C × T. > Given a suitable value of DFSR, chosen to satisfy Condition 1, this > inequality must also be met to guarantee > that the SCL frequency matches the SCL frequency calculated by the divider > equation. It is important to > note that tI2CRM is the measured rise time of the SCL signal, which is > defined as the time for the signal to > rise from 10% to 70% of VCC. > > NOTE >Note that the rise time must not exceed 300 nanoseconds > and that the above >two conditions must both be satisfied to ensure that the > actual SCL >frequency values align with the calculated values. By > meeting these >conditions, the measured SCL frequency will match the > calculated >frequency to within 5 kHz. Ignoring either of these > conditions may result in >larger discrepancies between these frequency values. > > How important is Condition 2 and what to do with rise times > 300 ns? The MAX > rise time > for 100 KHz is 1000 ns so there is a gap here. > > My testing suggests that this is not important. Bigger DFSR, in my case 0x6 > or 0x10, is key > to get a stable I2C bus. > > Jocke > PS. > Wolfgang, I sent a test program to calculate the new DFSR/FDR values in > the thread, you > might find it useful if you are going to try out the new AN2819 Where do I find this test program. I just dig out my program to calculate the table entries for the Linux i2c-mpc.c. It actually reproduced Timur's (old) U-Boot values. Unfortunately, finding *good* dfsr/fdr settings is no trivial and takes time. Till recently, the i2c-mpc driver of Linux did use *fixed* save values as shown here: http://lxr.linux.no/#linux+v2.6.29/drivers/i2c/busses/i2c-mpc.c And also with newer kernels, the table is only used if one of the following I2C DTS properties is defined: - fsl,preserve-clocking; - clock-frequency = <40>; See http://lxr.linux.no/#linux+v2.6.31/Documentation/powerpc/dts-bindings/fsl/i2c.txt Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_DFSR
Joakim Tjernlund wrote: >> Timur Tabi wrote on 15/09/2009 21:04:47: >>> Joakim Tjernlund wrote: >>> No, the impact on speed from DFSR is pretty small so it will be close enough. >>> How small? >> From the app note: >> divisor = B * (A + ((3*C)/B)*2); >> >> C is dfsr and 10 <= A <= 30, 16 <= B <= 2048 >> Considering the actual speed may be way lower the requested speed >> I think this is small enough. > > Once we have the new procedure in place, we can calculate the exact > divisor so the need for extra CONFIG_ options goes away. As Timur pointed out, a new table/algorithm would require some real testing and also some feedback from the users. Who knows if "your" values do not make trouble. Therefore I vote for using custom settings for maximum flexibility: CONFIG_FSL_I2C_CUSTOM_FDR CONFIG_FSL_I2C_CUSTOM_DFSR or CONFIG_FSL_I2C_CUSTOM_DFSR_FDR Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_DFSR
Joakim Tjernlund wrote: > Wolfgang Grandegger wrote on 16/09/2009 12:22:05: >> Joakim Tjernlund wrote: >>>> Timur Tabi wrote on 15/09/2009 21:04:47: >>>>> Joakim Tjernlund wrote: >>>>> >>>>>> No, the impact on speed from DFSR is pretty small so it will >>>>>> be close enough. >>>>> How small? >>>> From the app note: >>>> divisor = B * (A + ((3*C)/B)*2); >>>> >>>> C is dfsr and 10 <= A <= 30, 16 <= B <= 2048 >>>> Considering the actual speed may be way lower the requested speed >>>> I think this is small enough. >>> Once we have the new procedure in place, we can calculate the exact >>> divisor so the need for extra CONFIG_ options goes away. >> As Timur pointed out, a new table/algorithm would require some real >> testing and also some feedback from the users. Who knows if "your" >> values do not make trouble. Therefore I vote for using custom >> settings for maximum flexibility: >> >> CONFIG_FSL_I2C_CUSTOM_FDR >> CONFIG_FSL_I2C_CUSTOM_DFSR > > Oh well, since you both wanted it I added it. > Sent 3 patches, the last patch impl. the latest AN2819 spec. > > Would you mind test it a little? OK, I will do some tests later this week. What CPU do you use and at what I2C bus frequency do you test? Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_DFSR
Joakim Tjernlund wrote: > Wolfgang Grandegger wrote on 16/09/2009 13:45:03: >> Joakim Tjernlund wrote: >>> Wolfgang Grandegger wrote on 16/09/2009 12:22:05: >>>> Joakim Tjernlund wrote: >>>>>> Timur Tabi wrote on 15/09/2009 21:04:47: >>>>>>> Joakim Tjernlund wrote: >>>>>>> >>>>>>>> No, the impact on speed from DFSR is pretty small so it will >>>>>>>> be close enough. >>>>>>> How small? >>>>>> From the app note: >>>>>> divisor = B * (A + ((3*C)/B)*2); >>>>>> >>>>>> C is dfsr and 10 <= A <= 30, 16 <= B <= 2048 >>>>>> Considering the actual speed may be way lower the requested speed >>>>>> I think this is small enough. >>>>> Once we have the new procedure in place, we can calculate the exact >>>>> divisor so the need for extra CONFIG_ options goes away. >>>> As Timur pointed out, a new table/algorithm would require some real >>>> testing and also some feedback from the users. Who knows if "your" >>>> values do not make trouble. Therefore I vote for using custom >>>> settings for maximum flexibility: >>>> >>>> CONFIG_FSL_I2C_CUSTOM_FDR >>>> CONFIG_FSL_I2C_CUSTOM_DFSR >>> Oh well, since you both wanted it I added it. >>> Sent 3 patches, the last patch impl. the latest AN2819 spec. >>> >>> Would you mind test it a little? >> OK, I will do some tests later this week. What CPU do you use and at >> what I2C bus frequency do you test? > > mpc8321, I2C bus is between 34KHz and 100KHz, CSB is 133.332 MHz OK, where can I find the new AN2819? I found Document Number: AN2919, Rev. 5, 12/2008. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] fsl_i2c: Impl. AN2919, rev 5 to calculate FDR/DFSR
Hi Joakim,
Joakim Tjernlund wrote:
> The latest AN2919 has changed the way FDR/DFSR should be calculated.
> Update the driver according to spec. However, Condition 2
> is not accounted for as it is not clear how to do so.
I compared rev. 5 of AN2919 with rev. 3 and, as you pointed out, it puts
additional constraints on how to select dfsr and fdr. Especially dfsr
should not exceed a certain, frequency dependent value: dfsr <= 50 /
period-in-ns. Therefore, I expected problems with divider values from
the table which high dfsr values. I did your "=> date;date;date;date"
test on a MPC8548 board using dfsr=43 and fdr=7 but it did not fail.
According to the rev. 5, dfsr is not allowed to be greater than 8.
Your patch works fine on this board as well. I have no time for a more
thorough testing with different CPUs and frequencies. Anyhow...
> Signed-off-by: Joakim Tjernlund
Acked-by: Wolfgang Grandegger
I realized some minor coding style issues, though. See below.
> ---
> drivers/i2c/fsl_i2c.c | 90
> ++---
> 1 files changed, 55 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
> index 0c5f6be..78f21c7 100644
> --- a/drivers/i2c/fsl_i2c.c
> +++ b/drivers/i2c/fsl_i2c.c
> @@ -100,29 +100,9 @@ static const struct fsl_i2c *i2c_dev[2] = {
> */
> static const struct {
> unsigned short divider;
> -#ifdef __PPC__
> - u8 dfsr;
> -#endif
> u8 fdr;
> } fsl_i2c_speed_map[] = {
> -#ifdef __PPC__
> - {160, 1, 32}, {192, 1, 33}, {224, 1, 34}, {256, 1, 35},
> - {288, 1, 0}, {320, 1, 1}, {352, 6, 1}, {384, 1, 2}, {416, 6, 2},
> - {448, 1, 38}, {480, 1, 3}, {512, 1, 39}, {544, 11, 3}, {576, 1, 4},
> - {608, 22, 3}, {640, 1, 5}, {672, 32, 3}, {704, 11, 5}, {736, 43, 3},
> - {768, 1, 6}, {800, 54, 3}, {832, 11, 6}, {896, 1, 42}, {960, 1, 7},
> - {1024, 1, 43}, {1088, 22, 7}, {1152, 1, 8}, {1216, 43, 7}, {1280, 1, 9},
> - {1408, 22, 9}, {1536, 1, 10}, {1664, 22, 10}, {1792, 1, 46},
> - {1920, 1, 11}, {2048, 1, 47}, {2176, 43, 11}, {2304, 1, 12},
> - {2560, 1, 13}, {2816, 43, 13}, {3072, 1, 14}, {3328, 43, 14},
> - {3584, 1, 50}, {3840, 1, 15}, {4096, 1, 51}, {4608, 1, 16},
> - {5120, 1, 17}, {6144, 1, 18}, {7168, 1, 54}, {7680, 1, 19},
> - {8192, 1, 55}, {9216, 1, 20}, {10240, 1, 21}, {12288, 1, 22},
> - {14336, 1, 58}, {15360, 1, 23}, {16384, 1, 59}, {18432, 1, 24},
> - {20480, 1, 25}, {24576, 1, 26}, {28672, 1, 62}, {30720, 1, 27},
> - {32768, 1, 63}, {36864, 1, 28}, {40960, 1, 29}, {49152, 1, 30},
> - {61440, 1, 31}, {-1, 1, 31}
> -#elif defined(__M68K__)
> +#ifdef __M68K__
> {20, 32}, {22, 33}, {24, 34}, {26, 35},
> {28, 0}, {28, 36}, {30, 1}, {32, 37},
> {34, 2}, {36, 38}, {40, 3}, {40, 39},
> @@ -158,7 +138,6 @@ static unsigned int set_i2c_bus_speed(const struct
> fsl_i2c *dev,
> unsigned int i2c_clk, unsigned int speed)
> {
> unsigned short divider = min(i2c_clk / speed, (unsigned short) -1);
> - unsigned int i;
>
> /*
>* We want to choose an FDR/DFSR that generates an I2C bus speed that
> @@ -166,31 +145,72 @@ static unsigned int set_i2c_bus_speed(const struct
> fsl_i2c *dev,
>* want the first divider that is equal to or greater than the
>* calculated divider.
>*/
> -
> - for (i = 0; i < ARRAY_SIZE(fsl_i2c_speed_map); i++)
> - if (fsl_i2c_speed_map[i].divider >= divider) {
> - u8 fdr;
> #ifdef __PPC__
> - u8 dfsr;
> + u8 dfsr, fdr = 0x31; /* Default if no FDR found */
> + /* a, b and dfsr matches identifiers A,B and C respectively in AN2919 */
> + unsigned short a, b, ga, gb;
> + unsigned long c_div, est_div;
> +
> #ifdef CONFIG_FSL_I2C_CUSTOM_DFSR
> - dfsr = CONFIG_FSL_I2C_CUSTOM_DFSR;
> + dfsr = CONFIG_FSL_I2C_CUSTOM_DFSR;
> #else
> - dfsr = fsl_i2c_speed_map[i].dfsr;
> -#endif
> - writeb(dfsr, &dev->dfsrr); /* set default filter */
> + /* Condition 1: dfsr <= 50/T */
> + dfsr = (5 * (i2c_clk / 1000)) / 10;
> #endif
> #ifdef CONFIG_FSL_I2C_CUSTOM_FDR
> - fdr = CONFIG_FSL_I2C_CUSTOM_FDR;
> - speed = i2c_clk / divider; /* Fake something */
> + fdr = CONFIG_FSL_I2C_CUSTOM_FDR;
> + speed = i2c_clk / divider; /* Fake something */
> #else
> + debug("Requested speed:%d, i2c_clk:%d\n", speed, i2c_clk);
> + if (!dfsr)
> + dfsr = 1;
> +
> + est_div = ~0;
> + for (ga = 0x4, a = 10; a <= 30; ga++, a +=
Re: [U-Boot] [PATCH 3/3] fsl_i2c: Impl. AN2919, rev 5 to calculate FDR/DFSR
Joakim Tjernlund wrote: > Wolfgang Grandegger wrote on 21/09/2009 12:53:36: >> Hi Joakim, >> >> Joakim Tjernlund wrote: >>> The latest AN2919 has changed the way FDR/DFSR should be calculated. >>> Update the driver according to spec. However, Condition 2 >>> is not accounted for as it is not clear how to do so. >> I compared rev. 5 of AN2919 with rev. 3 and, as you pointed out, it puts >> additional constraints on how to select dfsr and fdr. Especially dfsr >> should not exceed a certain, frequency dependent value: dfsr <= 50 / >> period-in-ns. Therefore, I expected problems with divider values from >> the table which high dfsr values. I did your "=> date;date;date;date" >> test on a MPC8548 board using dfsr=43 and fdr=7 but it did not fail. >> According to the rev. 5, dfsr is not allowed to be greater than 8. >> Your patch works fine on this board as well. I have no time for a more >> thorough testing with different CPUs and frequencies. Anyhow... > > Yes, I too notice that higher dfsr values than the spec says works, in > fact my board needs at least dfsr 8 to be 100% stable but the spec says > no more that 6 for my board. I suspect that we should enforce a minimum > value of 8 to be on the safe side, especially as the HW default is 0x10. You say that the new constraints introduced by rev. 5 are not even correct!? Well, these modifications are obscure anyhow. > Anyhow it is better now than before. At least for your board. Let's keep an eye on people reporting I2C problems for these processors on the U-Boot and linuxppc-dev ML. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] video: mb862xx: add option VIDEO_FB_16BPP_WORD_SWAP for IPEK01
In 16 bpp mode, the new IPEK01 board only requires swapping of D16 words for D32 accesses due to the diffferent connecting to the GDC bus. This patch introduces the configuration option VIDEO_FB_16BPP_WORD_SWAP, which should be set for all board using the mb862xx in 16 bpp mode. For the IPEK01, VIDEO_FB_16BPP_PIXEL_SWAP should not be set. Signed-off-by: Wolfgang Grandegger --- drivers/video/cfb_console.c |2 +- include/configs/lwmon5.h|1 + include/configs/socrates.h |1 + 3 files changed, 3 insertions(+), 1 deletion(-) Index: u-boot-mainline/drivers/video/cfb_console.c === --- u-boot-mainline.orig/drivers/video/cfb_console.c2009-10-19 13:17:17.466553428 +0200 +++ u-boot-mainline/drivers/video/cfb_console.c 2009-10-19 13:17:17.495553669 +0200 @@ -321,7 +321,7 @@ #else #define SWAP16(x) (x) #define SWAP32(x) (x) -#if defined(VIDEO_FB_16BPP_PIXEL_SWAP) +#if defined(VIDEO_FB_16BPP_WORD_SWAP) #define SHORTSWAP32(x) ( ((x) >> 16) | ((x) << 16) ) #else #define SHORTSWAP32(x) (x) Index: u-boot-mainline/include/configs/lwmon5.h === --- u-boot-mainline.orig/include/configs/lwmon5.h 2009-10-19 13:17:17.471552467 +0200 +++ u-boot-mainline/include/configs/lwmon5.h2009-10-19 13:17:17.496553812 +0200 @@ -349,6 +349,7 @@ #define CONFIG_VIDEO_LOGO #define CONFIG_CONSOLE_EXTRA_INFO #define VIDEO_FB_16BPP_PIXEL_SWAP +#define VIDEO_FB_16BPP_WORD_SWAP #define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_VIDEO_SW_CURSOR Index: u-boot-mainline/include/configs/socrates.h === --- u-boot-mainline.orig/include/configs/socrates.h 2009-10-19 13:17:17.474552618 +0200 +++ u-boot-mainline/include/configs/socrates.h 2009-10-19 13:17:17.497553676 +0200 @@ -204,6 +204,7 @@ #define CONFIG_VIDEO_BMP_LOGO #define CONFIG_CONSOLE_EXTRA_INFO #define VIDEO_FB_16BPP_PIXEL_SWAP +#define VIDEO_FB_16BPP_WORD_SWAP #define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_SYS_CONSOLE_IS_IN_ENV #define CONFIG_VIDEO_SW_CURSOR ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for X888RGB mode
The new IPEK01 board uses the X888RGB mode for the Lime graphics
controller. For this mode video accelaration does not work. This patch
makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL,
which is enabled for the lwmon5 and the socrates board for backward
compatibility.
Signed-off-by: Anatolij Gustschin
Signed-off-by: Wolfgang Grandegger
---
drivers/video/cfb_console.c |2 ++
drivers/video/mb862xx.c | 16 +++-
include/configs/lwmon5.h|1 +
include/configs/socrates.h |1 +
4 files changed, 19 insertions(+), 1 deletion(-)
Index: u-boot-mainline/drivers/video/cfb_console.c
===
--- u-boot-mainline.orig/drivers/video/cfb_console.c2009-10-19
13:17:14.582303087 +0200
+++ u-boot-mainline/drivers/video/cfb_console.c 2009-10-19 13:17:29.406303158
+0200
@@ -146,9 +146,11 @@
#ifdef CONFIG_VIDEO_CORALP
#define VIDEO_FB_LITTLE_ENDIAN
#endif
+#ifdef CONFIG_VIDEO_MB862xx_ACCEL
#define VIDEO_HW_RECTFILL
#define VIDEO_HW_BITBLT
#endif
+#endif
/*/
/* Include video_fb.h after definitions of VIDEO_HW_RECTFILL etc*/
Index: u-boot-mainline/drivers/video/mb862xx.c
===
--- u-boot-mainline.orig/drivers/video/mb862xx.c2009-10-19
13:17:14.582303087 +0200
+++ u-boot-mainline/drivers/video/mb862xx.c 2009-10-19 13:17:17.467553012
+0200
@@ -89,6 +89,7 @@
(GC_DISP_BASE | GC_L0PAL0) + \
((idx) << 2)), (val))
+#if defined(CONFIG_VIDEO_MB862xx_ACCEL)
static void gdc_sw_reset (void)
{
GraphicDevice *dev = &mb862xx;
@@ -129,6 +130,7 @@
break;
}
}
+#endif
#if !defined(CONFIG_VIDEO_CORALP)
static void board_disp_init (void)
@@ -144,11 +146,13 @@
#endif
/*
- * Init drawing engine
+ * Init drawing engine if accel enabled.
+ * Also clears visible framebuffer.
*/
static void de_init (void)
{
GraphicDevice *dev = &mb862xx;
+#if defined(CONFIG_VIDEO_MB862xx_ACCEL)
int cf = (dev->gdfBytesPP == 1) ? 0x : 0x8000;
dev->dprBase = dev->frameAdrs + GC_DRAW_BASE;
@@ -174,6 +178,14 @@
DE_WR_FIFO (dev->winSizeY << 16 | dev->winSizeX);
/* sync with SW access to framebuffer */
de_wait ();
+#else
+ unsigned int i, *p;
+
+ i = dev->winSizeX * dev->winSizeY;
+ p = (unsigned int *)dev->frameAdrs;
+ while (i--)
+ *p++ = 0;
+#endif
}
#if defined(CONFIG_VIDEO_CORALP)
@@ -389,6 +401,7 @@
L0PAL_WR_REG (index, (r << 16) | (g << 8) | (b));
}
+#if defined(CONFIG_VIDEO_MB862xx_ACCEL)
/*
* Drawing engine Fill and BitBlt screen region
*/
@@ -430,3 +443,4 @@
DE_WR_FIFO ((height << 16) | width);
de_wait (); /* sync */
}
+#endif
Index: u-boot-mainline/include/configs/lwmon5.h
===
--- u-boot-mainline.orig/include/configs/lwmon5.h 2009-10-19
13:17:14.582303087 +0200
+++ u-boot-mainline/include/configs/lwmon5.h2009-10-19 13:17:29.406303158
+0200
@@ -344,6 +344,7 @@
/* Video console */
#define CONFIG_VIDEO
#define CONFIG_VIDEO_MB862xx
+#define CONFIG_VIDEO_MB862xx_ACCEL
#define CONFIG_CFB_CONSOLE
#define CONFIG_VIDEO_LOGO
#define CONFIG_CONSOLE_EXTRA_INFO
Index: u-boot-mainline/include/configs/socrates.h
===
--- u-boot-mainline.orig/include/configs/socrates.h 2009-10-19
13:17:14.583302392 +0200
+++ u-boot-mainline/include/configs/socrates.h 2009-10-19 13:17:29.406303158
+0200
@@ -198,6 +198,7 @@
#define CONFIG_VIDEO
#define CONFIG_VIDEO_MB862xx
+#define CONFIG_VIDEO_MB862xx_ACCEL
#define CONFIG_CFB_CONSOLE
#define CONFIG_VIDEO_LOGO
#define CONFIG_VIDEO_BMP_LOGO
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] mpc52xx: IPEK01 board support
Hello, this patch add support for the IPEK01 MPC5200 based board. It requires two patchs for the Fujitsu MB862xx driver: [PATCH 1/3] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for X888RGB mode [PATCH 2/3] video: mb862xx: add option VIDEO_FB_16BPP_WORD_SWAP for IPEK01 [PATCH 3/3] mpc52xx: add support for the IPEK01 board Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] mpc52xx: add support for the IPEK01 board
This patch adds support for the board IPEK01 based on the MPC5200. The Futjitsu Lime graphics controller is configured in 16 bpp mode. Signed-off-by: Wolfgang Grandegger --- Makefile|3 board/ipek01/Makefile | 50 board/ipek01/config.mk | 30 ++ board/ipek01/ipek01.c | 374 board/ipek01/mt46v16m16-75.h| 37 +++ board/ipek01/mt48lc16m16a2-75.h | 43 board/ipek01/u-boot.lds | 125 include/configs/ipek01.h| 411 8 files changed, 1073 insertions(+) create mode 100644 board/ipek01/Makefile create mode 100644 board/ipek01/config.mk create mode 100644 board/ipek01/ipek01.c create mode 100644 board/ipek01/mt46v16m16-75.h create mode 100644 board/ipek01/mt48lc16m16a2-75.h create mode 100644 board/ipek01/u-boot.lds create mode 100644 include/configs/ipek01.h Index: u-boot-mainline/Makefile === --- u-boot-mainline.orig/Makefile 2009-10-19 13:17:12.185302922 +0200 +++ u-boot-mainline/Makefile2009-10-19 13:17:17.519552635 +0200 @@ -725,6 +725,9 @@ } @$(MKCONFIG) -a PM520 ppc mpc5xxx pm520 +ipek01_config: unconfig + @$(MKCONFIG) -a ipek01 ppc mpc5xxx ipek01 + smmaco4_config: unconfig @$(MKCONFIG) -a smmaco4 ppc mpc5xxx tqm5200 tqc Index: u-boot-mainline/board/ipek01/Makefile === --- /dev/null 1970-01-01 00:00:00.0 + +++ u-boot-mainline/board/ipek01/Makefile 2009-10-19 13:17:17.521552642 +0200 @@ -0,0 +1,50 @@ +# +# (C) Copyright 2003-2006 +# 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).a + +COBJS := $(BOARD).o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# Index: u-boot-mainline/board/ipek01/config.mk === --- /dev/null 1970-01-01 00:00:00.0 + +++ u-boot-mainline/board/ipek01/config.mk 2009-10-19 13:17:17.523553767 +0200 @@ -0,0 +1,30 @@ +# +# (C) Copyright 2003-2004 +# 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 +# + +# +# IPEK01 board +# + +TEXT_BASE = 0xfc00 + +PLATFORM_CPPFLAGS += -DTEXT_BASE=$(TEXT_BASE) -I$(TOPDIR)/board Index: u-boot-mainline/board/ipek01/ipek01.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ u-boot-mainline/board/ipek01/ipek01.c 2009-10-19 13:17:17.527552105 +0200 @@ -0,0 +1,374 @@ +/* + * (C) Copyright 2003-2004 + * Wolfgang Denk, DENX Software Engineering, w...@denx.de. + * + * (C) Copyright 2004 + * Mark Jonas, Freescale Semiconductor, mark.jo...@motorola.com. + * + * (C) Copyright 2006
Re: [U-Boot] [PATCH 1/3] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for X888RGB mode
Wolfgang Denk wrote: > Dear Wolfgang Grandegger, > > In message <20091019111913.427445...@denx.de> you wrote: >> The new IPEK01 board uses the X888RGB mode for the Lime graphics >> controller. For this mode video accelaration does not work. This patch >> makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL, >> which is enabled for the lwmon5 and the socrates board for backward >> compatibility. > > Why would you want to disable it for IPEK01? Accelaration seems to be > a good thing you don't give up if you don't have to, but I > cannot think of reasons why you would have to do without it? Because acceleration does work with 16 bpp but *not* with 32 bpp. That's the reason why we made it configurable. Well, this patch could be dropped, because the BSP for the IPEK01 posted here uses now 16 bpp as well. >> Index: u-boot-mainline/drivers/video/cfb_console.c >> === >> --- u-boot-mainline.orig/drivers/video/cfb_console.c 2009-10-19 >> 13:17:14.582303087 +0200 >> +++ u-boot-mainline/drivers/video/cfb_console.c 2009-10-19 >> 13:17:29.406303158 +0200 > > Please use git-format-patch to create patches. Why? Do you have any problems to apply these patches? I personally (still) prefer using quilt for patch stack management. >> --- u-boot-mainline.orig/drivers/video/mb862xx.c 2009-10-19 >> 13:17:14.582303087 +0200 >> +++ u-boot-mainline/drivers/video/mb862xx.c 2009-10-19 13:17:17.467553012 >> +0200 > ... >> @@ -174,6 +178,14 @@ >> DE_WR_FIFO (dev->winSizeY << 16 | dev->winSizeX); >> /* sync with SW access to framebuffer */ >> de_wait (); >> +#else >> +unsigned int i, *p; >> + >> +i = dev->winSizeX * dev->winSizeY; >> +p = (unsigned int *)dev->frameAdrs; >> +while (i--) >> +*p++ = 0; >> +#endif > > Why don't you use memset() here? Maybe to ensure that D32 accesses are performed. Anatolij might know? Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] video: mb862xx: add option VIDEO_FB_16BPP_WORD_SWAP for IPEK01
Wolfgang Denk wrote: > Dear Wolfgang Grandegger, > > In message <20091019111913.621578...@denx.de> you wrote: >> In 16 bpp mode, the new IPEK01 board only requires swapping of D16 words >> for D32 accesses due to the diffferent connecting to the GDC bus. This >> patch introduces the configuration option VIDEO_FB_16BPP_WORD_SWAP, >> which should be set for all board using the mb862xx in 16 bpp mode. For >> the IPEK01, VIDEO_FB_16BPP_PIXEL_SWAP should not be set. > > I don't see any functional change in this patch - all you do is > renaming VIDEO_FB_16BPP_PIXEL_SWAP into VIDEO_FB_16BPP_WORD_SWAP. > > This makes no sense to me. Please have a look to the patched file. VIDEO_FB_16BPP_PIXEL_SWAP is used in other locations as well. This type of swapping is related to the way the GDC on the Socrates and lwmo5 board is connected. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for X888RGB mode
Wolfgang Denk wrote: > Dear Wolfgang, > > In message <4adc5661.7050...@grandegger.com> you wrote: The new IPEK01 board uses the X888RGB mode for the Lime graphics controller. For this mode video accelaration does not work. This patch makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL, which is enabled for the lwmon5 and the socrates board for backward compatibility. >>> Why would you want to disable it for IPEK01? Accelaration seems to be >>> a good thing you don't give up if you don't have to, but I >>> cannot think of reasons why you would have to do without it? >> Because acceleration does work with 16 bpp but *not* with 32 bpp. That's >> the reason why we made it configurable. Well, this patch could be >> dropped, because the BSP for the IPEK01 posted here uses now 16 bpp as well. > > Then please either mention this fact in the commit message (the > current one does not say anything about 16 versus 32 bit mode), or > realy drop the patch. Well, X888RGB mode is a 32 bpp mode. I leave it up to Anatolij to accept this patch or not (he is actually the original author). --- u-boot-mainline.orig/drivers/video/cfb_console.c 2009-10-19 13:17:14.582303087 +0200 +++ u-boot-mainline/drivers/video/cfb_console.c2009-10-19 13:17:29.406303158 +0200 >>> Please use git-format-patch to create patches. >> Why? Do you have any problems to apply these patches? I personally >> (still) prefer using quilt for patch stack management. > > git-format-patch provides index information, which allows for > intelligent merges (i. e. the merge code can then find the patch base > and do a rebase internally). With your patches this is impossible. > > Fell free to use quilt or any other tools for your own purposes, but > for patch submission please prepare the patches using > git-format-patch OK. +#else + unsigned int i, *p; + + i = dev->winSizeX * dev->winSizeY; + p = (unsigned int *)dev->frameAdrs; + while (i--) + *p++ = 0; +#endif >>> Why don't you use memset() here? >> Maybe to ensure that D32 accesses are performed. Anatolij might know? > > How should Anatolij know? It is you who added this code, right? No, this patch is from Anatolij and he has added his signed-off-by. My signed-off-by is not correct, strictly speaking. I should have just added an acked-by or tested-by line. Will change. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mpc52xx: add support for the IPEK01 board
Wolfgang Denk wrote:
> Dear Wolfgang Grandegger,
>
> In message <20091019111913.802418...@denx.de> you wrote:
>> This patch adds support for the board IPEK01 based on the MPC5200.
>> The Futjitsu Lime graphics controller is configured in 16 bpp mode.
>>
>> Signed-off-by: Wolfgang Grandegger
[...]
>> Index: u-boot-mainline/board/ipek01/ipek01.c
>> ===
>> --- /dev/null1970-01-01 00:00:00.0 +
>> +++ u-boot-mainline/board/ipek01/ipek01.c2009-10-19 13:17:17.527552105
>> +0200
> ...
>> +#ifndef CONFIG_SYS_RAMBOOT
>
> Is RAM-Boot actually a asupported mode of operation on this board, or
> are you just copuy & pasting dead code here?
If it's really dead code I'm going to prepare and send a patch removing
it for all boards. Would that be fine?
>> +static void sdram_start (int hi_addr)
>> +{
>> +long hi_addr_bit = hi_addr ? 0x0100 : 0;
>> +
>> +/* unlock mode register */
>> +*(vu_long *) MPC5XXX_SDRAM_CTRL =
>> +SDRAM_CONTROL | 0x8000 | hi_addr_bit;
>> +__asm__ volatile ("sync");
>
> Please use I/O accessors to write device registers (please fix
> globally).
Well, I borrowed known to work code from other boards. Unfortunately
there are no better examples (yet). Will fix, of course.
> ...
>> +phys_size_t initdram (int board_type)
>> +{
>> +ulong dramsize = 0;
>> +ulong dramsize2 = 0;
>> +uint svr, pvr;
>> +#ifndef CONFIG_SYS_RAMBOOT
>> +ulong test1, test2;
>> +
>> +/* setup SDRAM chip selects */
>> +*(vu_long *) MPC5XXX_SDRAM_CS0CFG = 0x001e; /* 2G at 0x0 */
>> +*(vu_long *) MPC5XXX_SDRAM_CS1CFG = 0x; /* disabled */
>
> It might make sense to #define some constants in the board config
> file.
>
>> +
>> +/* setup config registers */
>> +*(vu_long *) MPC5XXX_SDRAM_CONFIG1 = SDRAM_CONFIG1;
>> +*(vu_long *) MPC5XXX_SDRAM_CONFIG2 = SDRAM_CONFIG2;
>> +__asm__ volatile ("sync");
>> +
>> +#if SDRAM_DDR
>
> I consider this bad style. In U-Boot, we usually use #ifdef, but this
> collides with your #define SDRAM_DDR 0 versus 1 below. I recommend to
> clean this up.
OK.
>> +/*
>> + * On MPC5200B we need to set the special configuration delay in the
>> + * DDR controller. Please refer to Freescale's AN3221 "MPC5200B SDRAM
>> + * Initialization and Configuration", 3.3.1 SDelay--MBAR + 0x0190:
>> + *
>> + * "The SDelay should be written to a value of 0x0004. It is
>> + * required to account for changes caused by normal wafer processing
>> + * parameters."
>> + */
>> +svr = get_svr ();
>> +pvr = get_pvr ();
>> +if ((SVR_MJREV (svr) >= 2) && (PVR_MAJ (pvr) == 1) &&
>> +(PVR_MIN (pvr) == 4)) {
>> +*(vu_long *) MPC5XXX_SDRAM_SDELAY = 0x04;
>> +__asm__ volatile ("sync");
>> +}
>
> Is this test really needed? Are there versions of this board with
> pre-Rev. B silicon?
I would guess no. I have to check with the board provider.
>> +#if defined (CONFIG_CMD_IDE) && defined (CONFIG_IDE_RESET)
>> +
>> +void init_ide_reset (void)
>> +{
>> +debug ("init_ide_reset\n");
>> +}
>> +
>> +void ide_set_reset (int idereset)
>> +{
>> +debug ("ide_reset(%d)\n", idereset);
>> +}
>> +#endif /* defined (CONFIG_SYS_CMD_IDE) && defined (CONFIG_IDE_RESET) */
>
> This is just dead code. Please get rid of it.
>
>> +#ifdef CONFIG_VIDEO
>> +#define DISPLAY_WIDTH 800
>> +#define DISPLAY_HEIGHT 600
>
> This should go to the board config file.
OK.
>> +#define CONFIG_SYS_LIME_SRST(CONFIG_SYS_LIME_BASE + 0x01FC002C)
>> +#define CONFIG_SYS_LIME_CCF (CONFIG_SYS_LIME_BASE + 0x01FC0038)
>> +#define CONFIG_SYS_LIME_MMR (CONFIG_SYS_LIME_BASE + 0x01FCFFFC)
>> +/* Lime clock frequency */
>> +#define CONFIG_SYS_LIME_CLK 0x9 /* geo 166MHz other 133MHz */
>> +/* SDRAM parameter */
>> +#define CONFIG_SYS_LIME_MMR_VALUE 0x41c767e3
>
> Please do not use base register plus offset. Use a proper C struct to
> describe the device registers.
I think this should be done for the mb862xx video driver first, which
does still use base register plus offset. But it would be nice if the
mb862xx video driver would make the register access functions public,
which could then be used here.
>> +#d
Re: [U-Boot] [PATCH 0/4] *** SUBJECT HERE ***
Wolfgang Denk wrote: > Dear Wolfgang Grandegegr, > > In message <1256208516-10637-2-git-send-email...@grandegger.com> you wrote: >> From: Wolfgang Grandegger >> >> *** BLURB HERE *** > > Heh :-) "git send-email" obviously has sent the emacs backup file "-cover-letter.patch~" in my patch directory as well :-(. What's worse is that I mis-spelled my second name. Sorry for the noise. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] mpc52xx: add support for the IPEK01 board
Hi, there was a simple script fine in the patch directory as well, causing "git send-email" to compose and send a crap mail using wired addresses. Sorry again for the noise. Will remember next time. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] mpc52xx: add support for the IPEK01 board
From: Wolfgang Grandegger This patch adds support for the board IPEK01 based on the MPC5200. The Futjitsu Lime graphics controller is configured in 16 bpp mode. Signed-off-by: Wolfgang Grandegger --- MAINTAINERS |2 + MAKEALL |1 + Makefile |3 + board/ipek01/Makefile| 50 ++ board/ipek01/config.mk | 30 board/ipek01/ipek01.c| 282 include/configs/ipek01.h | 408 ++ 7 files changed, 776 insertions(+), 0 deletions(-) create mode 100644 board/ipek01/Makefile create mode 100644 board/ipek01/config.mk create mode 100644 board/ipek01/ipek01.c create mode 100644 include/configs/ipek01.h diff --git a/MAINTAINERS b/MAINTAINERS index 2297651..15d80c3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -201,6 +201,8 @@ Frank Gottschling Wolfgang Grandegger + ipek01 MPC5200 + CCM MPC855 PN62MPC8240 diff --git a/MAKEALL b/MAKEALL index 07d2414..4cac417 100755 --- a/MAKEALL +++ b/MAKEALL @@ -63,6 +63,7 @@ LIST_5xxx=" \ icecube_5100\ icecube_5200\ inka4x0 \ + ipek01 \ lite5200b \ mcc200 \ mecp5200\ diff --git a/Makefile b/Makefile index bed9469..e4cde64 100644 --- a/Makefile +++ b/Makefile @@ -606,6 +606,9 @@ jupiter_config: unconfig inka4x0_config:unconfig @$(MKCONFIG) inka4x0 ppc mpc5xxx inka4x0 +ipek01_config: unconfig + @$(MKCONFIG) -a ipek01 ppc mpc5xxx ipek01 + lite5200b_config \ lite5200b_PM_config\ lite5200b_LOWBOOT_config: unconfig diff --git a/board/ipek01/Makefile b/board/ipek01/Makefile new file mode 100644 index 000..ddfd2ef --- /dev/null +++ b/board/ipek01/Makefile @@ -0,0 +1,50 @@ +# +# (C) Copyright 2003-2006 +# 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).a + +COBJS := $(BOARD).o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/ipek01/config.mk b/board/ipek01/config.mk new file mode 100644 index 000..c8ecb29 --- /dev/null +++ b/board/ipek01/config.mk @@ -0,0 +1,30 @@ +# +# (C) Copyright 2003-2004 +# 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 +# + +# +# IPEK01 board +# + +TEXT_BASE = 0xfc00 + +PLATFORM_CPPFLAGS += -DTEXT_BASE=$(TEXT_BASE) -I$(TOPDIR)/board diff --git a/board/ipek01/ipek01.c b/board/ipek01/ipek01.c new file mode 100644 index 000..463a81b --- /dev/null +++ b/board/ipek01/ipek01.c @@ -0,0 +1,282 @@ +/* + * (C) Copyright 2003-2004 + * Wolfgang Denk, DENX Software Engineering, w...@denx.de. + * + * (C) Copyright 2004 + * Mark Jonas, Freescale Semiconductor, mark.jo...@motorola.com. + * + * (C) Copyright 2006 + * MicroSys GmbH + * +
[U-Boot] [PATCH v2 0/4] mpc52xx: IPEK01 board support
This patch add support for the IPEK01 MPC5200 based board. It requires three patches for the Fujitsu MB862xx driver. Changes since v1: - send patches properly Wolfgang Anatolij Gustschin (1): video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for 32bpp mode Wolfgang Grandegger (3): video: mb862xx: improve board-specific Lime configuration video: mb862xx: add option VIDEO_FB_16BPP_WORD_SWAP for IPEK01 mpc52xx: add support for the IPEK01 board MAINTAINERS |2 + MAKEALL |1 + Makefile|3 + board/ipek01/Makefile | 50 ++ board/ipek01/config.mk | 30 +++ board/ipek01/ipek01.c | 282 + board/lwmon5/lwmon5.c |7 - board/socrates/socrates.c | 46 + drivers/video/cfb_console.c |4 +- drivers/video/mb862xx.c | 50 +- include/configs/ipek01.h| 408 +++ include/configs/lwmon5.h| 12 +- include/configs/socrates.h |7 + include/mb862xx.h |5 + 14 files changed, 852 insertions(+), 55 deletions(-) create mode 100644 board/ipek01/Makefile create mode 100644 board/ipek01/config.mk create mode 100644 board/ipek01/ipek01.c create mode 100644 include/configs/ipek01.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for 32bpp mode
From: Anatolij Gustschin
The new IPEK01 board can use the 32 bpp mode for the Lime graphics
controller. For this mode, video accelaration does not work. This patch
makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL,
which is enabled for the lwmon5 and the socrates board for backward
compatibility.
Signed-off-by: Anatolij Gustschin
Signed-off-by: Wolfgang Grandegger
---
drivers/video/cfb_console.c |2 ++
drivers/video/mb862xx.c | 16 +++-
include/configs/lwmon5.h|1 +
include/configs/socrates.h |1 +
4 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index fbc4df9..0df321c 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -146,9 +146,11 @@ CONFIG_VIDEO_HW_CURSOR: - Uses the hardware cursor
capability of the
#ifdef CONFIG_VIDEO_CORALP
#define VIDEO_FB_LITTLE_ENDIAN
#endif
+#ifdef CONFIG_VIDEO_MB862xx_ACCEL
#define VIDEO_HW_RECTFILL
#define VIDEO_HW_BITBLT
#endif
+#endif
/*/
/* Include video_fb.h after definitions of VIDEO_HW_RECTFILL etc*/
diff --git a/drivers/video/mb862xx.c b/drivers/video/mb862xx.c
index bb212a8..edf34aa 100644
--- a/drivers/video/mb862xx.c
+++ b/drivers/video/mb862xx.c
@@ -89,6 +89,7 @@ unsigned int fr_div[] = { 0x0f00, 0x0900, 0x0500
};
(GC_DISP_BASE | GC_L0PAL0) + \
((idx) << 2)), (val))
+#if defined(CONFIG_VIDEO_MB862xx_ACCEL)
static void gdc_sw_reset (void)
{
GraphicDevice *dev = &mb862xx;
@@ -129,6 +130,7 @@ static void de_wait_slots (int slots)
break;
}
}
+#endif
#if !defined(CONFIG_VIDEO_CORALP)
static void board_disp_init (void)
@@ -144,11 +146,13 @@ static void board_disp_init (void)
#endif
/*
- * Init drawing engine
+ * Init drawing engine if accel enabled.
+ * Also clears visible framebuffer.
*/
static void de_init (void)
{
GraphicDevice *dev = &mb862xx;
+#if defined(CONFIG_VIDEO_MB862xx_ACCEL)
int cf = (dev->gdfBytesPP == 1) ? 0x : 0x8000;
dev->dprBase = dev->frameAdrs + GC_DRAW_BASE;
@@ -174,6 +178,14 @@ static void de_init (void)
DE_WR_FIFO (dev->winSizeY << 16 | dev->winSizeX);
/* sync with SW access to framebuffer */
de_wait ();
+#else
+ unsigned int i, *p;
+
+ i = dev->winSizeX * dev->winSizeY;
+ p = (unsigned int *)dev->frameAdrs;
+ while (i--)
+ *p++ = 0;
+#endif
}
#if defined(CONFIG_VIDEO_CORALP)
@@ -421,6 +433,7 @@ void video_set_lut (unsigned int index, unsigned char r,
L0PAL_WR_REG (index, (r << 16) | (g << 8) | (b));
}
+#if defined(CONFIG_VIDEO_MB862xx_ACCEL)
/*
* Drawing engine Fill and BitBlt screen region
*/
@@ -462,3 +475,4 @@ void video_hw_bitblt (unsigned int bpp, unsigned int src_x,
DE_WR_FIFO ((height << 16) | width);
de_wait (); /* sync */
}
+#endif
diff --git a/include/configs/lwmon5.h b/include/configs/lwmon5.h
index 67434f5..927b80f 100644
--- a/include/configs/lwmon5.h
+++ b/include/configs/lwmon5.h
@@ -344,6 +344,7 @@
/* Video console */
#define CONFIG_VIDEO
#define CONFIG_VIDEO_MB862xx
+#define CONFIG_VIDEO_MB862xx_ACCEL
#define CONFIG_CFB_CONSOLE
#define CONFIG_VIDEO_LOGO
#define CONFIG_CONSOLE_EXTRA_INFO
diff --git a/include/configs/socrates.h b/include/configs/socrates.h
index 3321aa2..59a4b28 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -198,6 +198,7 @@
#define CONFIG_VIDEO
#define CONFIG_VIDEO_MB862xx
+#define CONFIG_VIDEO_MB862xx_ACCEL
#define CONFIG_CFB_CONSOLE
#define CONFIG_VIDEO_LOGO
#define CONFIG_VIDEO_BMP_LOGO
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] video: mb862xx: add option VIDEO_FB_16BPP_WORD_SWAP for IPEK01
From: Wolfgang Grandegger In 16 bpp mode, the new IPEK01 board only requires swapping of D16 words for D32 accesses due to the diffferent connecting to the GDC bus. This patch introduces the configuration option VIDEO_FB_16BPP_WORD_SWAP, which should be set for all board using the mb862xx in 16 bpp mode. For the IPEK01, VIDEO_FB_16BPP_PIXEL_SWAP should not be set. Signed-off-by: Wolfgang Grandegger --- drivers/video/cfb_console.c |2 +- include/configs/lwmon5.h|1 + include/configs/socrates.h |1 + 3 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c index 0df321c..16d6689 100644 --- a/drivers/video/cfb_console.c +++ b/drivers/video/cfb_console.c @@ -321,7 +321,7 @@ voidconsole_cursor (int state); #else #define SWAP16(x) (x) #define SWAP32(x) (x) -#if defined(VIDEO_FB_16BPP_PIXEL_SWAP) +#if defined(VIDEO_FB_16BPP_WORD_SWAP) #define SHORTSWAP32(x) ( ((x) >> 16) | ((x) << 16) ) #else #define SHORTSWAP32(x) (x) diff --git a/include/configs/lwmon5.h b/include/configs/lwmon5.h index 927b80f..011dd5c 100644 --- a/include/configs/lwmon5.h +++ b/include/configs/lwmon5.h @@ -349,6 +349,7 @@ #define CONFIG_VIDEO_LOGO #define CONFIG_CONSOLE_EXTRA_INFO #define VIDEO_FB_16BPP_PIXEL_SWAP +#define VIDEO_FB_16BPP_WORD_SWAP #define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_VIDEO_SW_CURSOR diff --git a/include/configs/socrates.h b/include/configs/socrates.h index 59a4b28..3632b84 100644 --- a/include/configs/socrates.h +++ b/include/configs/socrates.h @@ -204,6 +204,7 @@ #define CONFIG_VIDEO_BMP_LOGO #define CONFIG_CONSOLE_EXTRA_INFO #define VIDEO_FB_16BPP_PIXEL_SWAP +#define VIDEO_FB_16BPP_WORD_SWAP #define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_SYS_CONSOLE_IS_IN_ENV #define CONFIG_VIDEO_SW_CURSOR -- 1.6.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] video: mb862xx: improve board-specific Lime configuration
From: Wolfgang Grandegger
To avoid board-specific code accessing the mb862xx registers directly,
the public function mb862xx_probe() has been introduced. Furthermore,
the "Change of Clock Frequency" and "Set Memory I/F Mode" registers
are now defined by CONFIG_SYS_MB862xx_CCF and CONFIG_SYS_MB862xx__MMR,
respectively. The BSPs for the socrates and lwmon5 boards have been
adapted accordingly.
Signed-off-by: Wolfgang Grandegger
---
board/lwmon5/lwmon5.c |7 --
board/socrates/socrates.c | 46 ++-
drivers/video/mb862xx.c| 34 +++-
include/configs/lwmon5.h | 10 +++-
include/configs/socrates.h |5
include/mb862xx.h |5
6 files changed, 54 insertions(+), 53 deletions(-)
diff --git a/board/lwmon5/lwmon5.c b/board/lwmon5/lwmon5.c
index ef7f2e8..d36ea04 100644
--- a/board/lwmon5/lwmon5.c
+++ b/board/lwmon5/lwmon5.c
@@ -532,13 +532,6 @@ unsigned int board_video_init (void)
udelay(500);
gpio_write_bit(CONFIG_SYS_GPIO_LIME_RST, 1);
- /* Lime memory clock adjusted to 100MHz */
- out_be32((void *)CONFIG_SYS_LIME_SDRAM_CLOCK,
CONFIG_SYS_LIME_CLOCK_100MHZ);
- /* Wait untill time expired. Because of requirements in lime manual */
- udelay(300);
- /* Write lime controller memory parameters */
- out_be32((void *)CONFIG_SYS_LIME_MMR, CONFIG_SYS_LIME_MMR_VALUE);
-
mb862xx.winSizeX = 640;
mb862xx.winSizeY = 480;
mb862xx.gdfBytesPP = 2;
diff --git a/board/socrates/socrates.c b/board/socrates/socrates.c
index 51d66d5..9183c15 100644
--- a/board/socrates/socrates.c
+++ b/board/socrates/socrates.c
@@ -268,17 +268,6 @@ ft_board_setup(void *blob, bd_t *bd)
}
#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
-#define CONFIG_SYS_LIME_SRST ((CONFIG_SYS_LIME_BASE) + 0x01FC002C)
-#define CONFIG_SYS_LIME_CCF((CONFIG_SYS_LIME_BASE) + 0x01FC0038)
-#define CONFIG_SYS_LIME_MMR((CONFIG_SYS_LIME_BASE) + 0x01FCFFFC)
-/* Lime clock frequency */
-#define CONFIG_SYS_LIME_CLK_100MHZ 0x0
-#define CONFIG_SYS_LIME_CLK_133MHZ 0x1
-/* SDRAM parameter */
-#define CONFIG_SYS_LIME_MMR_VALUE 0x4157BA63
-
-#define DISPLAY_WIDTH 800
-#define DISPLAY_HEIGHT 480
#define DEFAULT_BRIGHTNESS 25
#define BACKLIGHT_ENABLE (1 << 31)
@@ -308,14 +297,12 @@ const gdc_regs *board_get_regs (void)
return init_regs;
}
-#define CONFIG_SYS_LIME_CID((CONFIG_SYS_LIME_BASE) + 0x01FC00F0)
-#define CONFIG_SYS_LIME_REV((CONFIG_SYS_LIME_BASE) + 0x01FF8084)
int lime_probe(void)
{
volatile ccsr_lbc_t *memctl = (void *)(CONFIG_SYS_MPC85xx_LBC_ADDR);
uint cfg_br2;
uint cfg_or2;
- uint reg;
+ int type;
cfg_br2 = memctl->br2;
cfg_or2 = memctl->or2;
@@ -325,21 +312,15 @@ int lime_probe(void)
memctl->or2 = 0xfc000410;
memctl->br2 = (CONFIG_SYS_LIME_BASE) | 0x1901;
- /* Try to access GDC ID/Revision registers */
- reg = in_be32((void *)CONFIG_SYS_LIME_CID);
- reg = in_be32((void *)CONFIG_SYS_LIME_CID);
- if (reg == 0x303) {
- reg = in_be32((void *)CONFIG_SYS_LIME_REV);
- reg = in_be32((void *)CONFIG_SYS_LIME_REV);
- reg = ((reg & ~0xff) == 0x20050100) ? 1 : 0;
- } else
- reg = 0;
+ /* Get controller type */
+ type = mb862xx_probe(CONFIG_SYS_LIME_BASE);
/* Restore previous CS2 configuration */
memctl->br2 = 0;
memctl->or2 = cfg_or2;
memctl->br2 = cfg_br2;
- return reg;
+
+ return (type == MB862XX_TYPE_LIME) ? 1 : 0;
}
/* Returns Lime base address */
@@ -348,21 +329,8 @@ unsigned int board_video_init (void)
if (!lime_probe())
return 0;
- /*
-* Reset Lime controller
-*/
- out_be32((void *)CONFIG_SYS_LIME_SRST, 0x1);
- udelay(200);
-
- /* Set Lime clock to 133MHz */
- out_be32((void *)CONFIG_SYS_LIME_CCF, CONFIG_SYS_LIME_CLK_133MHZ);
- /* Delay required */
- udelay(300);
- /* Set memory parameters */
- out_be32((void *)CONFIG_SYS_LIME_MMR, CONFIG_SYS_LIME_MMR_VALUE);
-
- mb862xx.winSizeX = DISPLAY_WIDTH;
- mb862xx.winSizeY = DISPLAY_HEIGHT;
+ mb862xx.winSizeX = 800;
+ mb862xx.winSizeY = 480;
mb862xx.gdfIndex = GDF_15BIT_555RGB;
mb862xx.gdfBytesPP = 2;
diff --git a/drivers/video/mb862xx.c b/drivers/video/mb862xx.c
index a8676cc..bb212a8 100644
--- a/drivers/video/mb862xx.c
+++ b/drivers/video/mb862xx.c
@@ -340,6 +340,30 @@ unsigned int card_init (void)
}
#endif
+
+#if !defined(CONFIG_VIDEO_CORALP)
+int mb862xx_probe(unsigned int addr)
+{
+ GraphicDevice *dev = &mb862xx;
+ unsigned int reg;
+
+ dev->fram
Re: [U-Boot] [PATCH] add u-boot sja1000/can support
Hello, miaofng wrote: >>From 1f6aaba856fbf484c442eb33cf220774d57fba8d Mon Sep 17 00:00:00 2001 > From: miaofng > Date: Fri, 23 Oct 2009 17:06:50 +0800 > Subject: [PATCH] [can] add u-boot sja1000/can support There are already CAN controllers supported for some board, e.g. ./tqm5200/cmd_stk52xx.c, and a generic CAN device drive interface would be nice to have, indeed. At a first glance I find your Socket-CAN based approach to heavy. Could you please elaborate on the use cases you have in mind. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CAN console
Mike Frysinger wrote: > On Monday 26 October 2009 07:09:03 Matthias Weißer wrote: >> Mike Frysinger schrieb: >>> On Monday 26 October 2009 04:20:02 Matthias Weißer wrote: I have a device here which has only a CAN interface to the outside world. I am currently thinking about implementing a "serial" driver using the CAN controller. Is there any chance to get this accepted in the public u-boot tree? >>> someone just posted a port of the Linux CAN framework. if your driver >>> used that to implement a serial layer, i dont see why it wouldnt be >>> accepted. >> Well, that means that I have to implement a full functional CAN driver >> and then additionally add a serial driver using the (completely new) CAN >> framework. My idea was that I just add a serial_ccan.c to drivers/serial. > > you would rather write a driver that is specific to one CAN hardware ? > writing it to a common framework would allow every one with a CAN driver to > use it ... There are many simple USB CAN devices which are operated through the tty interface. See http://prdownload.berlios.de/socketcan/SLCAN-API.pdf Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fw: Re: Re: [PATCH] add u-boot sja1000/can support
miaofng wrote: > Hi mike, > It seems there's a big difference between my current project > and u-boot common usage. I can only enjoy the patch myself now Yes, can you describe your use-case. CAN in U-BOOT, so far, was just used to send or receive one or a few messages, mainly for testing purposes. > > i want to get a packet from usb/network, then redirect it to can bus. > So blocked write/read of can is not allowed. You have that working? Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CAN console
Matthias Weißer wrote: > Hi > > I have a device here which has only a CAN interface to the > outside world. I am currently thinking about implementing > a "serial" driver using the CAN controller. OK, a dedicated CAN driver would make more sense. > Is there any chance to get this accepted in the public u-boot > tree? I think yes, if it does not mis-use U-BOOT > A special program on the PC side would be needed to translate > the CAN messages back to a serial stream and vice versa and > make it available to a terminal program. But thats another story. Netconsole could do the job, but that would require to run IP over CAN. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fw: Re: Re: [PATCH] add u-boot sja1000/can support
miaofng wrote: > Wolfgang Grandegger wrote: >> miaofng wrote: >> >>> Hi mike, >>> It seems there's a big difference between my current project >>> and u-boot common usage. I can only enjoy the patch myself now >>> >> Yes, can you describe your use-case. CAN in U-BOOT, so far, was just >> used to send or receive one or a few messages, mainly for testing purposes. >> >> > what i want to do is something like a protocol gateway. It converts the > data from one type to another. > u-boot has support so many cpu/board/, i thinks it can do much more > tasks than just for testing purposes. > It could be a non-OS based software plaform :) Well, U-Boot is a bootloader and I strongly suggest to use Linux for that purpose. Nevertheless, maybe a simple generic CAN framework could be useful for both, normal testing purposes and your special app. Some time ago I wrote a simple framework supporting the SJA100 and the i82527. I will try to find it now. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 0/5] CAN framework for U-Boot
From: Wolfgang Grandegger This patch series adds a simple CAN framework for U-Boot. The main purpose is to do simple RX/TX testing when the device boots up but the interface functions could also be used for more complex tasks. This is just a RFC and a few more features need to be added or issues to be fixed, like using a generic device interface, if it already exists, and board specific device configuration, e.g. via i82527_register(addr, cfg-params). The sources are based on GPL v2+ code to be compatible with future U-Boot licence requirement. Please comment. Wolfgang Wolfgang Grandegger (5): CAN interface library CAN device test command CAN device driver for the SJA1000 CAN device driver for the Intel 82527 CAN interface support for the TQM855L module Makefile |1 + board/tqc/tqm8xx/tqm8xx.c | 17 ++ common/Makefile |1 + common/cmd_can.c | 119 +++ drivers/can/Makefile | 49 ++ drivers/can/can.c | 88 +++ drivers/can/i82527.c | 366 + drivers/can/sja1000.c | 223 +++ include/can.h | 70 + include/configs/TQM855L.h |8 +- include/i82527.h | 201 + include/sja1000.h | 159 12 files changed, 1301 insertions(+), 1 deletions(-) create mode 100644 common/cmd_can.c create mode 100644 drivers/can/Makefile create mode 100644 drivers/can/can.c create mode 100644 drivers/can/i82527.c create mode 100644 drivers/can/sja1000.c create mode 100644 include/can.h create mode 100644 include/i82527.h create mode 100644 include/sja1000.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 1/5] CAN interface library
From: Wolfgang Grandegger
Signed-off-by: Wolfgang Grandegger
---
Makefile |1 +
drivers/can/Makefile | 47 ++
drivers/can/can.c| 88 ++
include/can.h| 70 +++
4 files changed, 206 insertions(+), 0 deletions(-)
create mode 100644 drivers/can/Makefile
create mode 100644 drivers/can/can.c
create mode 100644 include/can.h
diff --git a/Makefile b/Makefile
index bcb3fe9..dca15e0 100644
--- a/Makefile
+++ b/Makefile
@@ -203,6 +203,7 @@ LIBS += net/libnet.a
LIBS += disk/libdisk.a
LIBS += drivers/bios_emulator/libatibiosemu.a
LIBS += drivers/block/libblock.a
+LIBS += drivers/can/libcan.a
LIBS += drivers/dma/libdma.a
LIBS += drivers/fpga/libfpga.a
LIBS += drivers/gpio/libgpio.a
diff --git a/drivers/can/Makefile b/drivers/can/Makefile
new file mode 100644
index 000..74d2ff5
--- /dev/null
+++ b/drivers/can/Makefile
@@ -0,0 +1,47 @@
+#
+# Copyright 2000-2008
+# 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)libcan.a
+
+COBJS-$(CONFIG_CAN)+= can.o
+
+COBJS := $(COBJS-y)
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+all: $(LIB)
+
+$(LIB):$(obj).depend $(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+
diff --git a/drivers/can/can.c b/drivers/can/can.c
new file mode 100644
index 000..c09bccf
--- /dev/null
+++ b/drivers/can/can.c
@@ -0,0 +1,88 @@
+/*
+ * (C) Copyright 2007-2009, Wolfgang Grandegger
+ *
+ * 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
+ */
+
+/*
+ * CAN device interface library
+ */
+#include
+#include
+#include
+
+static struct can_dev *can_devs;
+
+static char *baudrates[] = { "125K", "250K", "500K" };
+
+int can_register (struct can_dev* can_dev)
+{
+ struct can_dev* dev;
+
+ can_dev->next = NULL;
+ if (!can_devs)
+ can_devs = can_dev;
+ else {
+ for (dev = can_devs; dev->next; dev = dev->next)
+ ;
+ dev->next = can_dev;
+ }
+
+ printf ("CAN: %s at %lx registered\n", can_dev->name, can_dev->base);
+
+ return 0;
+}
+
+struct can_dev *can_init (int dev_num, int ibaud)
+{
+ struct can_dev *dev;
+ int i;
+
+ if (!can_devs) {
+ puts ("No CAN devices registered\n");
+ return NULL;
+ }
+
+ /* Advance to selected device */
+ for (i = 0, dev = can_devs; dev; i++, dev = dev->next) {
+ if (i == dev_num)
+ break;
+ }
+
+ if (!dev) {
+ printf ("CAN device %d does not exist\n", dev_num);
+ return NULL;
+ }
+
+ printf ("Initializing CAN%d at 0x%08x with baudrate %s\n",
+ i, dev->base, baudrates[ibaud]);
+
+ dev->init (dev, ibaud);
+
+ return dev;
+}
+
+void can_list (void)
+{
+ struct can_dev *dev;
+ int i;
+
+ for (i = 0, dev = can_devs; dev; i++, dev = dev->next)
+ printf ("CA
[U-Boot] [RFC 2/5] CAN device test command
From: Wolfgang Grandegger
Signed-off-by: Wolfgang Grandegger
---
common/Makefile |1 +
common/cmd_can.c | 119 ++
2 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_can.c
diff --git a/common/Makefile b/common/Makefile
index 3781738..b7f4c22 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -72,6 +72,7 @@ COBJS-$(CONFIG_CMD_BEDBUG) += bedbug.o cmd_bedbug.o
COBJS-$(CONFIG_CMD_BMP) += cmd_bmp.o
COBJS-$(CONFIG_CMD_BOOTLDR) += cmd_bootldr.o
COBJS-$(CONFIG_CMD_CACHE) += cmd_cache.o
+COBJS-$(CONFIG_CMD_CAN) += cmd_can.o
COBJS-$(CONFIG_CMD_CONSOLE) += cmd_console.o
COBJS-$(CONFIG_CMD_CPLBINFO) += cmd_cplbinfo.o
COBJS-$(CONFIG_DATAFLASH_MMC_SELECT) += cmd_dataflash_mmc_mux.o
diff --git a/common/cmd_can.c b/common/cmd_can.c
new file mode 100644
index 000..af7bf34
--- /dev/null
+++ b/common/cmd_can.c
@@ -0,0 +1,119 @@
+/*
+ * (C) Copyright 2007-2009, Wolfgang Grandegger
+ *
+ * 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
+ */
+
+/*
+ * CAN device test command
+ */
+#include
+#include
+#include
+
+static struct can_dev *can_dev;
+
+int do_can (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ struct can_msg msg;
+ char op;
+ int i;
+
+ op = argv[1][0];
+
+ if (argc < 2) {
+ can_list ();
+ return 0;
+ }
+
+ if (!can_dev && op != 'i') {
+ can_dev = can_init (0, 0);
+ if (!can_dev)
+ return 1;
+ }
+
+ if (op == 's') {
+ unsigned int level = 0;
+ if (argc > 2)
+ level = simple_strtoul (argv[2], NULL, 10);
+ can_status (can_dev, level);
+ }
+
+ else if (op == 'i') {
+ unsigned int dev_num = 0, ibaud = 0;
+ struct can_dev *dev;
+
+ if (argc > 2)
+ dev_num = simple_strtoul (argv[2], NULL, 10);
+ if (argc > 3) {
+ ibaud = simple_strtoul (argv[3], NULL, 10);
+ if (ibaud > 2)
+ ibaud = 2;
+ }
+ dev = can_init (dev_num, ibaud);
+ if (!dev)
+ return 1;
+ can_dev = dev;
+ }
+
+ else if (op == 'r') {
+ while (!can_recv (can_dev, &msg)) {
+ printf ("<0x%03x>", msg.id & CAN_SFF_MASK);
+
+ printf (" [%d]", msg.dlc);
+ if (msg.id & CAN_RTR_FLAG)
+ puts (" rtr");
+ else {
+ for (i = 0; i < msg.dlc; i++)
+ printf (" %02x", msg.data[i]);
+ }
+ puts ("\n");
+ }
+ } else if (op == 'x') {
+ memset (&msg, 0, sizeof (msg));
+ msg.id = 0x123;
+ if (argc > 2)
+ msg.id = simple_strtoul (argv[2], NULL, 16);
+ for (i = 0; argc > (3 + i); i++, msg.dlc++) {
+ msg.data[i] = simple_strtoul (argv[3 + i], NULL, 16);
+ }
+ if (argc == 2)
+ printf ("Transmitting id %#x dlc %d\n",
+ msg.id, msg.dlc);
+
+ if (can_xmit (can_dev, &msg))
+ puts("FAILED\n");
+ else
+ puts("OK\n");
+ } else {
+ printf ("Usage:\n%s\n", cmdtp->usage);
+ return 1;
+ }
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ can, 3, 1, do_can,
+ "can - CAN bus commands\n",
+ "can status [level]\n"
+ "can init [dev] [baud-index]\n"
+ "can xmit [id] [d0] [d1] ... [d7]\n"
+ "can recv, abort with CTRL-C\n"
+);
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 3/5] CAN device driver for the SJA1000
From: Wolfgang Grandegger
Signed-off-by: Wolfgang Grandegger
---
drivers/can/Makefile |3 +-
drivers/can/sja1000.c | 223 +
include/sja1000.h | 159 +++
3 files changed, 384 insertions(+), 1 deletions(-)
create mode 100644 drivers/can/sja1000.c
create mode 100644 include/sja1000.h
diff --git a/drivers/can/Makefile b/drivers/can/Makefile
index 74d2ff5..e2b6bd6 100644
--- a/drivers/can/Makefile
+++ b/drivers/can/Makefile
@@ -25,7 +25,8 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libcan.a
-COBJS-$(CONFIG_CAN)+= can.o
+COBJS-$(CONFIG_CAN)+= can.o
+COBJS-$(CONFIG_CAN_SJA1000)+= sja1000.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/can/sja1000.c b/drivers/can/sja1000.c
new file mode 100644
index 000..b75f01c
--- /dev/null
+++ b/drivers/can/sja1000.c
@@ -0,0 +1,223 @@
+/*
+ * (C) Copyright 2007-2009, Wolfgang Grandegger
+ *
+ * Derived from Xenomai's RT-Socket-CAN driver for SJA1000:
+ *
+ * Copyright (C) 2005,2006 Sebastian Smolorz
+ *
+ *
+ * Copyright (C) 2005, Sascha Hauer, Pengutronix
+ *
+ * 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
+#include
+
+#include
+#include
+
+#define SJA1000_OCR(SJA_OCR_MODE_NORMAL | SJA_OCR_TX0_PUSHPULL)
+#define SJA1000_CDRSJA_CDR_CAN_MODE
+
+/*
+ * Basic functions to access registers
+ */
+#define sja1000_read_reg(dev, reg) \
+ in_8 ((volatile u8 *)((dev)->base + (reg)))
+
+#define sja1000_write_reg(dev, reg, value) \
+ out_8 ((volatile u8 *)((dev)->base + (reg)), value)
+
+/*
+ * Baudrate table
+ */
+
+static u16 sja1000_btr0btr1[] = {
+ 0x031c, /* 125K */
+ 0x011c, /* 250K */
+ 0x001c, /* 500K */
+};
+
+int sja1000_init (struct can_dev *dev, unsigned int ibaud)
+{
+ int i, wait = 1000;
+ u16 btr0btr1;
+
+ /* Disable the controller's interrupts */
+ sja1000_write_reg (dev, SJA_IER, 0x00);
+
+ /* Set reset mode bit */
+ sja1000_write_reg (dev, SJA_MOD, SJA_MOD_RM);
+
+ /* Read reset mode bit, multiple tests */
+ do {
+ udelay (100);
+ if (sja1000_read_reg (dev, SJA_MOD) & SJA_MOD_RM)
+ break;
+ } while (--wait);
+
+ sja1000_write_reg (dev, SJA_CDR, SJA1000_CDR);
+ sja1000_write_reg (dev, SJA_OCR, SJA1000_OCR);
+
+ sja1000_write_reg (dev, SJA_AMR0, 0xFF);
+ sja1000_write_reg (dev, SJA_AMR1, 0xFF);
+ sja1000_write_reg (dev, SJA_AMR2, 0xFF);
+ sja1000_write_reg (dev, SJA_AMR3, 0xFF);
+
+ sja1000_write_reg (dev, SJA_RXERR, 0);
+ sja1000_write_reg (dev, SJA_TXERR, 0);
+
+ i = sizeof (sja1000_btr0btr1) / sizeof (u16);
+ if (ibaud >= i)
+ ibaud = i - 1;
+ btr0btr1 = sja1000_btr0btr1[ibaud];
+ sja1000_write_reg (dev, SJA_BTR0, (btr0btr1 >> 8) & 0xff);
+ sja1000_write_reg (dev, SJA_BTR1, (btr0btr1 & 0xff));
+
+ /* Clear error code capture (i.e. read it) */
+ sja1000_read_reg (dev, SJA_ECC);
+
+ /* Clear reset mode bit in SJA1000 */
+ sja1000_write_reg (dev, SJA_MOD, 0);
+
+ return 0;
+}
+
+int sja1000_xmit (struct can_dev *dev, struct can_msg *msg)
+{
+ int i;
+ u8 fir;
+
+ if (msg->dlc > 8)
+ msg->dlc = 8;
+ fir = msg->dlc;
+
+ sja1000_write_reg (dev, SJA_ID1, msg->id >> 3);
+ sja1000_write_reg (dev, SJA_ID2, msg->id << 5);
+ for (i = 0; i < msg->dlc; i++)
+ sja1000_write_reg (dev, SJA_DATA_SFF (i), msg->data[i]);
+
+ /* Write frame information register */
+ sja1000_write_reg (dev, SJA_FIR, fir);
+
+ /* Push the 'send' button */
+ sja1000_write_reg (dev, SJA_CMR, SJA_CMR_TR);
+
+ /* Wait some time */
+ for (i = 0; i < CAN_XMIT_TIMEOUT_US; i += 1) {
+ if (sja1000_read_reg (dev, SJA_SR) & SJA_SR_TCS)
+ return 0;
+ if (ctrlc ())
+
[U-Boot] [RFC 4/5] CAN device driver for the Intel 82527
From: Wolfgang Grandegger
Signed-off-by: Wolfgang Grandegger
---
drivers/can/Makefile |1 +
drivers/can/i82527.c | 366 ++
include/i82527.h | 201 +++
3 files changed, 568 insertions(+), 0 deletions(-)
create mode 100644 drivers/can/i82527.c
create mode 100644 include/i82527.h
diff --git a/drivers/can/Makefile b/drivers/can/Makefile
index e2b6bd6..d550a45 100644
--- a/drivers/can/Makefile
+++ b/drivers/can/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libcan.a
COBJS-$(CONFIG_CAN)+= can.o
+COBJS-$(CONFIG_CAN_I82527) += i82527.o
COBJS-$(CONFIG_CAN_SJA1000)+= sja1000.o
COBJS := $(COBJS-y)
diff --git a/drivers/can/i82527.c b/drivers/can/i82527.c
new file mode 100644
index 000..b3eacd6
--- /dev/null
+++ b/drivers/can/i82527.c
@@ -0,0 +1,366 @@
+/*
+ * (C) Copyright 2007-2009, Wolfgang Grandegger
+ *
+ * Derived from OCAN driver:
+ *
+ * Copyright (C) 2002 Alessandro Rubini
+ * Copyright (C) 2002 System SpA
+ *
+ * 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
+#include
+
+#include
+#include
+
+#define I82527_TX_OBJ 1
+#define I82527_RX_OBJ 15
+
+/*
+ * Basic functions to access registers
+ */
+#define i82527_read_reg(dev, reg) \
+ in_8 ((volatile u8 *)((dev)->base + (reg)))
+
+#define i82527_write_reg(dev, reg, value) \
+ out_8 ((volatile u8 *)((dev)->base + (reg)), value)
+
+/*
+ * Higher level functions
+ */
+static inline int i82527_read_msgcfg (struct can_dev *dev, int iobj)
+{
+ return i82527_read_reg (dev, (iobj * I82527_MSG_OFF) + I82527_MSG_CFG);
+}
+
+static inline void i82527_write_msgcfg (struct can_dev *dev, int iobj, int val)
+{
+ i82527_write_reg (dev, (iobj * I82527_MSG_OFF) + I82527_MSG_CFG, val);
+}
+
+static inline void i82527_write_std_mask (struct can_dev *dev, u16 val)
+{
+ /* errors are ignored, hmm... */
+ i82527_write_reg (dev, I82527_GMASK_STD, val >> 8);
+ i82527_write_reg (dev, I82527_GMASK_STD + 1, val & 0xff);
+}
+
+static inline void i82527_write_x_mask (struct can_dev *dev, u32 val)
+{
+ /* errors are ignored, hmm... */
+ i82527_write_reg (dev, I82527_GMASK_XTD, val >> 24);
+ i82527_write_reg (dev, I82527_GMASK_XTD + 1, (val >> 16) & 0xff);
+ i82527_write_reg (dev, I82527_GMASK_XTD + 2, (val >> 8) & 0xff);
+ i82527_write_reg (dev, I82527_GMASK_XTD + 3, (val >> 0) & 0xff);
+}
+
+static inline void i82527_write_15_mask (struct can_dev *dev, u32 val)
+{
+ /* errors are ignored, hmm... */
+ i82527_write_reg (dev, I82527_MSG15_MASK, val >> 24);
+ i82527_write_reg (dev, I82527_MSG15_MASK + 1, (val >> 16) & 0xff);
+ i82527_write_reg (dev, I82527_MSG15_MASK + 2, (val >> 8) & 0xff);
+ i82527_write_reg (dev, I82527_MSG15_MASK + 3, (val >> 0) & 0xff);
+}
+
+static inline void i82527_write_msgctrl (struct can_dev *dev, int iobj, u16
val)
+{
+ /* FIXME: this is used little-endian, but doesn't need to be 16b */
+
+ /* errors are ignored, hmm... */
+ i82527_write_reg (dev, (iobj * I82527_MSG_OFF) +
+ I82527_MSG_CTRL, val & 0xff);
+ i82527_write_reg (dev, (iobj * I82527_MSG_OFF) +
+ I82527_MSG_CTRL + 1, val >> 8);
+}
+
+/* write a single byte of msgctrl, twice as fast as the function above */
+static inline void i82527_msgflag (struct can_dev *dev, int iobj, u16 act)
+{
+ if ((act & 0xff) == 0xff)
+ i82527_write_reg (dev, (iobj * I82527_MSG_OFF) +
+ I82527_MSG_CTRL + 1, act >> 8);
+ else
+ i82527_write_reg (dev, (iobj * I82527_MSG_OFF) +
+ I82527_MSG_CTRL, act & 0xff);
+}
+
+static inline u32 i82527_read_msgarb (struct can_dev *dev, int iobj)
+{
+ int port = (iobj * I82527_MSG_OFF) + I82527_MSG_ARBIT;
+
+ u32 ret = (i82527_read_reg (dev, port) << 24 |
+ i82527_read_reg (dev, port + 1) << 16 |
+
[U-Boot] [RFC 5/5] CAN interface support for the TQM855L module
From: Wolfgang Grandegger
Signed-off-by: Wolfgang Grandegger
---
board/tqc/tqm8xx/tqm8xx.c | 17 +
include/configs/TQM855L.h |8 +++-
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/board/tqc/tqm8xx/tqm8xx.c b/board/tqc/tqm8xx/tqm8xx.c
index f92c598..f1aab43 100644
--- a/board/tqc/tqm8xx/tqm8xx.c
+++ b/board/tqc/tqm8xx/tqm8xx.c
@@ -26,6 +26,10 @@
#ifdef CONFIG_PS2MULT
#include
#endif
+#ifdef CONFIG_CAN
+#include
+#include
+#endif
extern flash_info_t flash_info[]; /* FLASH chips info */
@@ -447,6 +451,19 @@ int board_early_init_r (void)
#endif /* CONFIG_PS2MULT */
+#if defined(CONFIG_CAN_DRIVER) && defined(CONFIG_CAN)
+static struct can_dev tqm8xx_can[2];
+
+#ifdef CONFIG_BOARD_EARLY_INIT_R
+int board_early_init_r (void)
+{
+ i82527_register (&tqm8xx_can[0], CONFIG_SYS_CAN_BASE);
+ i82527_register( &tqm8xx_can[1], CONFIG_SYS_CAN_BASE + 0x100);
+
+ return (0);
+}
+#endif
+#endif
#ifdef CONFIG_MISC_INIT_R
extern void load_sernum_ethaddr(void);
diff --git a/include/configs/TQM855L.h b/include/configs/TQM855L.h
index 1255928..1603d30 100644
--- a/include/configs/TQM855L.h
+++ b/include/configs/TQM855L.h
@@ -88,7 +88,13 @@
#defineCONFIG_STATUS_LED 1 /* Status LED enabled
*/
-#undef CONFIG_CAN_DRIVER /* CAN Driver support disabled */
+#defineCONFIG_CAN_DRIVER /* CAN Driver support
enabled */
+#ifdef CONFIG_CAN_DRIVER
+#define CONFIG_CAN
+#define CONFIG_CAN_I82527
+#define CONFIG_CMD_CAN
+#define CONFIG_BOARD_EARLY_INIT_R
+#endif
/*
* BOOTP options
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 1/5] CAN interface library
Mike Frysinger wrote:
> On Sunday 01 November 2009 06:33:33 Wolfgang Grandegger wrote:
[snip]
>> --- /dev/null
>> +++ b/drivers/can/can.c
>>
>> +static char *baudrates[] = { "125K", "250K", "500K" };
>
> so we're restricting ourselves to these three speeds ? i have passing
> familiarity with CAN, but i didnt think the protocol was restricted to
> specific speeds.
Well, this is an RFC and as I wrote in the introduction some features
need to be added or extended, especially for CAN device configuration.
My idea is to have a more complete default bit-timing table, which board
specific code may overwrite using, for example:
sja1000_register(&my_sja1000, &my_config_opts);
This would also allow to set the CAN clock, cdr and ocr registers.
>> +int can_register (struct can_dev* can_dev)
>
> no space before the paren, and the * is cuddled on the wrong side of the
> space. seems like a lot of this code suffers from these two issues.
U-Boot coding style requires a space after the function name and before
"(". But the "*" is misplaced, of course.
>> +{
>> +struct can_dev* dev;
>> +
>> +can_dev->next = NULL;
>> +if (!can_devs)
>> +can_devs = can_dev;
>> +else {
>> +for (dev = can_devs; dev->next; dev = dev->next)
>> +;
>> +dev->next = can_dev;
>> +}
>
> invert the if logic and i think the code would look "nicer" -- use braces on
> the first branch instead of the second.
OK.
>> +struct can_dev *can_init (int dev_num, int ibaud)
>> +{
>> +struct can_dev *dev;
>> +int i;
>> +
>> +if (!can_devs) {
>> +puts ("No CAN devices registered\n");
>> +return NULL;
>> +}
>> +
>> +/* Advance to selected device */
>> +for (i = 0, dev = can_devs; dev; i++, dev = dev->next) {
>> +if (i == dev_num)
>> +break;
>> +}
>> +
>> +if (!dev) {
>> +printf ("CAN device %d does not exist\n", dev_num);
>> +return NULL;
>> +}
>> +
>> +printf ("Initializing CAN%d at 0x%08x with baudrate %s\n",
>> + i, dev->base, baudrates[ibaud]);
>> +
>> +dev->init (dev, ibaud);
>> +
>> +return dev;
>> +}
>
> wonder if we should have a generic device list code base since this looks
> similar to a lot of other u-boot device lists ...
Do we already have a generic interface?
>> --- /dev/null
>> +++ b/include/can.h
>> @@ -0,0 +1,70 @@
>> +/*
>> + * (C) Copyright 2007-2009, Wolfgang Grandegger
>
> have you really been working on this stuff since 2007 ?
The code was written in 2007. "2007, 2009" is more appropriate.
>> +struct can_dev {
>> +char *name;
>
> const ?
OK.
Wolfgang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 2/5] CAN device test command
Mike Frysinger wrote:
> On Sunday 01 November 2009 06:33:34 Wolfgang Grandegger wrote:
>> +if (op == 's') {
>> +else if (op == 'i') {
>> +else if (op == 'r') {
>> +} else if (op == 'x') {
>> +} else {
>
> your if style here is inconsistent, but ignoring that, shouldnt this really
> be
> a switch() ? although, by only checking the first char, you allow people to
> encode typos into their commands and not realize it until some point in the
> future where things get stricter. i.e. people can do `can ilovecandy ...`
Will fix.
>> +unsigned int dev_num = 0, ibaud = 0;
>> +struct can_dev *dev;
>> +
>> +if (argc > 2)
>> +dev_num = simple_strtoul (argv[2], NULL, 10);
>> +if (argc > 3) {
>> +ibaud = simple_strtoul (argv[3], NULL, 10);
>> +if (ibaud > 2)
>> +ibaud = 2;
>> +}
>> +dev = can_init (dev_num, ibaud);
>> +if (!dev)
>> +return 1;
>> +can_dev = dev;
>
> if i told CAN to init an unknown device, i would expect to get an error and
> the command state to remain in said error state until i selected a proper CAN
> device. otherwise, a script that didnt check the can init status would
> incorrectly operate on the previously selected can device.
can_init will already print an error message. But that might be changed.
> how do other commands work ? am i complaining about common convention here ?
>
>> +printf ("Usage:\n%s\n", cmdtp->usage);
>
> cmd_usage() ?
OK.
>> +can, 3, 1, do_can,
>> +"can - CAN bus commands\n",
>> +"can status [level]\n"
>> +"can init [dev] [baud-index]\n"
>> +"can xmit [id] [d0] [d1] ... [d7]\n"
>> +"can recv, abort with CTRL-C\n"
>
> does the help really display correctly here ? i think the "can status" line
> will have too many "can"'s ?
I think the output was OK. But I will check later next week.
Note that this is a RFC trying to discuss the real requirements of a CAN
interface in U-Boot. I think it would also be nice to have can_xmit()
and can_recv() with a timeout parameter, e.g.:
can_xmit(struct can_dev *dev, int timeout_us);
And maybe also a can_xmit_done() function.
Wolfgang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 1/5] CAN interface library
Mike Frysinger wrote:
> On Sunday 01 November 2009 11:16:59 Wolfgang Grandegger wrote:
>> Mike Frysinger wrote:
>>> On Sunday 01 November 2009 06:33:33 Wolfgang Grandegger wrote:
>>>> --- /dev/null
>>>> +++ b/drivers/can/can.c
>>>>
>>>> +static char *baudrates[] = { "125K", "250K", "500K" };
>>> so we're restricting ourselves to these three speeds ? i have passing
>>> familiarity with CAN, but i didnt think the protocol was restricted to
>>> specific speeds.
>> Well, this is an RFC and as I wrote in the introduction some features
>> need to be added or extended, especially for CAN device configuration.
>> My idea is to have a more complete default bit-timing table, which board
>> specific code may overwrite using, for example:
>>
>>sja1000_register(&my_sja1000, &my_config_opts);
>>
>> This would also allow to set the CAN clock, cdr and ocr registers.
>
> this makes sense if the device supports a limited number of baud rates. but
> what if the baud rate is arbitrary (between two limits) ?
Board specific code can define what ever table it likes, including
non-standard bit-rate and bit-timings. Nevertheless, for most CAN
controllers the default bit-timing parameters are just fine.
>>>> +int can_register (struct can_dev* can_dev)
>>> no space before the paren, and the * is cuddled on the wrong side of the
>>> space. seems like a lot of this code suffers from these two issues.
>> U-Boot coding style requires a space after the function name and before
>> "(". But the "*" is misplaced, of course.
>
> it's (thankfully) been changing to Linux kernel style
I really appreciate that.
>>>> +struct can_dev *can_init (int dev_num, int ibaud)
>>> wonder if we should have a generic device list code base since this looks
>>> similar to a lot of other u-boot device lists ...
>> Do we already have a generic interface?
>
> i dont think so
Nor do I.
Wolfgang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 3/5] CAN device driver for the SJA1000
Matthias Fuchs wrote: > Hi Wolfgang, > > this patch conflicts with my simple SJA header posted some days ago > > http://lists.denx.de/pipermail/u-boot/2009-October/063097.html > > together with a fix for two of our boards - which has not much > to do with CAN. WD asked me to use a C struct to access the SJA1000. > > http://lists.denx.de/pipermail/u-boot/2009-October/062902.html > > So where does this bring us? Either we want to use C structs for everything > or decide it from patch to patch :-( Then it should be changed, of course. This patch is far from being accepted and for the moment it's an implementation detail. I'm especially interested to hear if such a generic CAN interface would serve your purposes as well, as you require access to the SJA1000 somehow. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 3/5] CAN device driver for the SJA1000
Matthias Fuchs wrote: > Hi Wolfgang, > > of course I can think of situations where some simple CAN mechanism > might be helpful (e.g. simple hardware testing). > > But do we really need this inside a bootloader? Surely not > for a production build. But please keep on hacking! > > On Monday 02 November 2009 13:50, Wolfgang Grandegger wrote: >> Matthias Fuchs wrote: >>> Hi Wolfgang, >>> >>> this patch conflicts with my simple SJA header posted some days ago >>> >>> http://lists.denx.de/pipermail/u-boot/2009-October/063097.html >>> >>> together with a fix for two of our boards - which has not much >>> to do with CAN. WD asked me to use a C struct to access the SJA1000. >>> >>> http://lists.denx.de/pipermail/u-boot/2009-October/062902.html >>> >>> So where does this bring us? Either we want to use C structs for everything >>> or decide it from patch to patch :-( >> Then it should be changed, of course. This patch is far from being >> accepted and for the moment it's an implementation detail. I'm >> especially interested to hear if such a generic CAN interface would >> serve your purposes as well, as you require access to the SJA1000 somehow. > > I just need to bit bang around in the OCR register. So no need for a full > blown > and flash consuming CAN implementation. Of course I could life with your > register access style. Especially because it makes the code more common with > Socket-CAN files which prevents us from rewriting fully functional code ;-) Well, I think Wolfgang will tell me to use structs sooner than later. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND on mpc8360erdk
Renaud barbier wrote: > I am in the middle of NAND debugging on a MPC8544 based system. BTW: also the TQM8548 module uses FSL UPM NAND. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 4/4] usb: add USB support for Efika
On 11/02/2011 05:16 PM, Stefano Babic wrote:
> On 11/02/2011 05:03 PM, Jana Rapava wrote:
>>
>> Ok, so non-board-specific parts should go into ./arch/arm/cpu/armv7/mx5/
>> and board-specific callbacks should stay here? Do I understand you well?
>
> Yes, I think so
>
>>
>>>
>>> I don't want to block on that issue, so if it simplifies you a
>>> further ULPI patches submission - I don't care if you leave it here
>>> and in the next patch set move to a common location.
>>>
>>>
>> Thanks.
>
> Anyway, as we agree, it is really better to do now the right thing as to
> postpone.
I'm want to provide USB support for mx53loco and maybe mx51evk,
similar to what Jana is doing. Following the "drivers/usb/host/ehci mxc.c"
example, I tried to do it the generic way by implementing
"drivers/usb/host/ehci-mx5.c". Not sure if it's the better approach as
a board specific initialization/reset might be required for some boards.
Therefore board specific callbacks would make sense. I have attached my
patch below for review and comments.
Thanks,
Wolfgang,
>From b88a75699646583fa368cc40eb000b773bea9e1d Mon Sep 17 00:00:00 2001
From: Wolfgang Grandegger
Date: Mon, 7 Nov 2011 15:48:00 +0100
Subject: [PATCH] mx53loco: USB EHCI for MX5
Signed-off-by: Wolfgang Grandegger
---
arch/arm/cpu/armv7/mx5/clock.c| 72
arch/arm/include/asm/arch-mx5/clock.h |5 +
arch/arm/include/asm/arch-mx5/crm_regs.h |3 +
arch/arm/include/asm/arch-mx5/imx-regs.h | 33 ++
arch/arm/include/asm/arch-mx5/mx5x_pins.h |4 +
board/freescale/mx53loco/mx53loco.c | 11 ++
drivers/usb/host/Makefile |1 +
drivers/usb/host/ehci-mx5.c | 174 +
include/configs/mx53loco.h| 13 ++
9 files changed, 316 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/host/ehci-mx5.c
diff --git a/arch/arm/cpu/armv7/mx5/clock.c b/arch/arm/cpu/armv7/mx5/clock.c
index 0769a64..c8dad17 100644
--- a/arch/arm/cpu/armv7/mx5/clock.c
+++ b/arch/arm/cpu/armv7/mx5/clock.c
@@ -50,6 +50,78 @@ struct mxc_pll_reg *mxc_plls[PLL_CLOCKS] = {
struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)MXC_CCM_BASE;
+void set_usboh3_clk(void)
+{
+ unsigned int reg;
+
+ reg = readl(&mxc_ccm->cscmr1) &
+~MXC_CCM_CSCMR1_USBOH3_CLK_SEL_MASK;
+ reg |= 1 << MXC_CCM_CSCMR1_USBOH3_CLK_SEL_OFFSET;
+ writel(reg, &mxc_ccm->cscmr1);
+
+ reg = readl(&mxc_ccm->cscdr1);
+ reg &= ~MXC_CCM_CSCDR1_USBOH3_CLK_PODF_MASK;
+ reg &= ~MXC_CCM_CSCDR1_USBOH3_CLK_PRED_MASK;
+ reg |= 4 << MXC_CCM_CSCDR1_USBOH3_CLK_PRED_OFFSET;
+ reg |= 1 << MXC_CCM_CSCDR1_USBOH3_CLK_PODF_OFFSET;
+
+ writel(reg, &mxc_ccm->cscdr1);
+}
+
+void enable_usboh3_clk(unsigned char enable)
+{
+ unsigned int reg;
+
+ reg = readl(&mxc_ccm->CCGR2);
+ if (enable)
+ reg |= 1 << MXC_CCM_CCGR2_CG14_OFFSET;
+ else
+ reg &= ~(1 << MXC_CCM_CCGR2_CG14_OFFSET);
+ writel(reg, &mxc_ccm->CCGR2);
+}
+
+void set_usb_phy1_clk(void)
+{
+ unsigned int reg;
+
+ reg = readl(&mxc_ccm->cscmr1);
+ reg &= ~MXC_CCM_CSCMR1_USB_PHY_CLK_SEL;
+ writel(reg, &mxc_ccm->cscmr1);
+}
+
+void enable_usb_phy1_clk(unsigned char enable)
+{
+ unsigned int reg;
+
+ reg = readl(&mxc_ccm->CCGR4);
+ if (enable)
+ reg |= 1 << MXC_CCM_CCGR4_CG5_OFFSET;
+ else
+ reg &= ~(1 << MXC_CCM_CCGR4_CG5_OFFSET);
+ writel(reg, &mxc_ccm->CCGR4);
+}
+
+void set_usb_phy2_clk(void)
+{
+ unsigned int reg;
+
+ reg = readl(&mxc_ccm->cscmr1);
+ reg &= ~MXC_CCM_CSCMR1_USB_PHY_CLK_SEL;
+ writel(reg, &mxc_ccm->cscmr1);
+}
+
+void enable_usb_phy2_clk(unsigned char enable)
+{
+ unsigned int reg;
+
+ reg = readl(&mxc_ccm->CCGR4);
+ if (enable)
+ reg |= 1 << MXC_CCM_CCGR4_CG6_OFFSET;
+ else
+ reg &= ~(1 << MXC_CCM_CCGR4_CG6_OFFSET);
+ writel(reg, &mxc_ccm->CCGR4);
+}
+
/*
* Calculate the frequency of PLLn.
*/
diff --git a/arch/arm/include/asm/arch-mx5/clock.h
b/arch/arm/include/asm/arch-mx5/clock.h
index 1f8a537..ea972a3 100644
--- a/arch/arm/include/asm/arch-mx5/clock.h
+++ b/arch/arm/include/asm/arch-mx5/clock.h
@@ -40,4 +40,9 @@ u32 imx_get_uartclk(void);
u32 imx_get_fecclk(void);
unsigned int mxc_get_clock(enum mxc_clock clk);
+void set_usb_phy2_clk(void);
+void enable_usb_phy2_clk(unsigned char enable);
+void set_usboh3_clk(void);
+void enable_usboh3_clk(unsigned char enable);
+
#endif /* __ASM_ARCH_CLOCK_H */
diff --git a/arch/arm/include/as
[U-Boot] [PATCH] arm: add __aeabi_unwind_cpp_pr1() function to avoid linker complaints
With the ELDK 5.1 (beta) "armv7a" toolchain I'm get the following
build failure:
$ ./MAKEALL mx51evk
...
/opt/eldk-5.1/armv7a/sysroots/arm-linux-gnueabi/usr/lib/arm-linux-
gnueabi/4.6.1/libgcc.a(bpabi.o):(.ARM.exidx+0x0): undefined
reference to `__aeabi_unwind_cpp_pr1'
make: *** [u-boot] Error 1
This patch fixes the issue similar to commit
d442b6e7ad6a86e2fd0e6297291fe8872ff26fc6 but I don't know if it's
general enough or if it does harm when using other toolchains.
Signed-off-by: Wolfgang Grandegger
---
arch/arm/lib/eabi_compat.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c
index eb3e26d..2207c88 100644
--- a/arch/arm/lib/eabi_compat.c
+++ b/arch/arm/lib/eabi_compat.c
@@ -21,3 +21,8 @@ int raise (int signum)
void __aeabi_unwind_cpp_pr0(void)
{
};
+
+void __aeabi_unwind_cpp_pr1(void)
+{
+};
+
--
1.7.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] smsc95xx: in smsc95xx_set_multicast write to reg
The write to the mac_cr register was missing. This usually not
cause an issue before, since the next function writing the
register's shadow copy into the register would do it as a side
effect.
Signed-off-by: Wolfgang Grandegger
Cc: Simon Glass
---
drivers/usb/eth/smsc95xx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
index eb529f1..16e24bd 100644
--- a/drivers/usb/eth/smsc95xx.c
+++ b/drivers/usb/eth/smsc95xx.c
@@ -428,6 +428,8 @@ static void smsc95xx_set_multicast(struct ueth_data *dev)
{
/* No multicast in u-boot */
dev->mac_cr &= ~(MAC_CR_PRMS_ | MAC_CR_MCPAS_ | MAC_CR_HPFILT_);
+
+ smsc95xx_write_reg(dev, MAC_CR, dev->mac_cr);
}
/* starts the TX path */
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] smsc95xx: Fix MAC address programming and some minor issues
Wolfgang Grandegger (3): smsc95xx: Fix MAC address programming smsc95xx: in smsc95xx_set_multicast write to reg smsc95xx: remove an unecessary debug messages drivers/usb/eth/smsc95xx.c | 16 +--- 1 files changed, 9 insertions(+), 7 deletions(-) -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] smsc95xx: Fix MAC address programming
Commit 79ad54400932d6484178a372fb3b659e3437473b broke the MAC
address programming. Fix this by using the method from Linux'
smsc95xx_set_mac_address().
Signed-off-by: Wolfgang Grandegger
Cc: Marek Vasut
Cc: Simon Glass
---
drivers/usb/eth/smsc95xx.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
index 7ee4f87..eb529f1 100644
--- a/drivers/usb/eth/smsc95xx.c
+++ b/drivers/usb/eth/smsc95xx.c
@@ -372,13 +372,14 @@ static int smsc95xx_init_mac_address(struct eth_device
*eth,
static int smsc95xx_write_hwaddr(struct eth_device *eth)
{
struct ueth_data *dev = (struct ueth_data *)eth->priv;
- u32 addr_lo, addr_hi;
+ u32 addr_lo = eth->enetaddr[0] | eth->enetaddr[1] << 8 |
+ eth->enetaddr[2] << 16 | eth->enetaddr[3] << 24;
+ u32 addr_hi = eth->enetaddr[4] | eth->enetaddr[5] << 8;
int ret;
/* set hardware address */
debug("** %s()\n", __func__);
- addr_lo = cpu_to_le32(*eth->enetaddr);
- addr_hi = cpu_to_le16(*((u16 *)(eth->enetaddr + 4)));
+
ret = smsc95xx_write_reg(dev, ADDRL, addr_lo);
if (ret < 0) {
debug("Failed to write ADDRL: %d\n", ret);
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] smsc95xx: remove an unecessary debug messages
Signed-off-by: Wolfgang Grandegger
Cc: Simon Glass
---
drivers/usb/eth/smsc95xx.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
index 16e24bd..40f7f5b 100644
--- a/drivers/usb/eth/smsc95xx.c
+++ b/drivers/usb/eth/smsc95xx.c
@@ -380,15 +380,14 @@ static int smsc95xx_write_hwaddr(struct eth_device *eth)
/* set hardware address */
debug("** %s()\n", __func__);
- ret = smsc95xx_write_reg(dev, ADDRL, addr_lo);
- if (ret < 0) {
- debug("Failed to write ADDRL: %d\n", ret);
+ ret = smsc95xx_write_reg(dev, ADDRL, adddr_lo);
+ if (ret < 0)
return ret;
- }
ret = smsc95xx_write_reg(dev, ADDRH, addr_hi);
if (ret < 0)
return ret;
+
debug("MAC %02x:%02x:%02x:%02x:%02x:%02x\n",
eth->enetaddr[0], eth->enetaddr[1],
eth->enetaddr[2], eth->enetaddr[3],
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] smsc95xx: Fix MAC address programming
On 11/11/2011 12:04 PM, Marek Vasut wrote:
>> Commit 79ad54400932d6484178a372fb3b659e3437473b broke the MAC
>> address programming. Fix this by using the method from Linux'
>> smsc95xx_set_mac_address().
>>
>> Signed-off-by: Wolfgang Grandegger
>> Cc: Marek Vasut
>> Cc: Simon Glass
>> ---
>> drivers/usb/eth/smsc95xx.c |7 ---
>> 1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
>> index 7ee4f87..eb529f1 100644
>> --- a/drivers/usb/eth/smsc95xx.c
>> +++ b/drivers/usb/eth/smsc95xx.c
>> @@ -372,13 +372,14 @@ static int smsc95xx_init_mac_address(struct
>> eth_device *eth, static int smsc95xx_write_hwaddr(struct eth_device *eth)
>> {
>> struct ueth_data *dev = (struct ueth_data *)eth->priv;
>> -u32 addr_lo, addr_hi;
>> +u32 addr_lo = eth->enetaddr[0] | eth->enetaddr[1] << 8 |
>> +eth->enetaddr[2] << 16 | eth->enetaddr[3] << 24;
>> +u32 addr_hi = eth->enetaddr[4] | eth->enetaddr[5] << 8;
>> int ret;
>>
>> /* set hardware address */
>> debug("** %s()\n", __func__);
>> -addr_lo = cpu_to_le32(*eth->enetaddr);
>> -addr_hi = cpu_to_le16(*((u16 *)(eth->enetaddr + 4)));
>> +
>> ret = smsc95xx_write_reg(dev, ADDRL, addr_lo);
>> if (ret < 0) {
>> debug("Failed to write ADDRL: %d\n", ret);
>
> Hey,
>
> didn't Mike Frysinger send similar patch yesterday? Also, do you have the
Ah, I obviously missed that.
> hardware? If so, that's good, we know you can provide tested fix.
Well, yes, I know somebody who has smsc95xx hardware ;-).
> Mike, are you good with using this fix instead or can you two negotiate?
Let's await Mike's answer (now on CC as well). I need to re-send the
series anyway due to a stupid typo.
Wolfgang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] mx53loco: add end enable USB host support on port 1
Signed-off-by: Wolfgang Grandegger
CC: Jason Liu
---
board/freescale/mx53loco/mx53loco.c | 10 ++
include/configs/mx53loco.h | 13 +
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/board/freescale/mx53loco/mx53loco.c
b/board/freescale/mx53loco/mx53loco.c
index b4c7f33..7bccfa9 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -78,6 +78,16 @@ static void setup_iomux_uart(void)
PAD_CTL_ODE_OPENDRAIN_ENABLE);
}
+#ifdef CONFIG_USB_EHCI_MX5
+void board_ehci_hcd_init(int port)
+{
+ /* request VBUS power enable pin, GPIO[8}, gpio7 */
+ mxc_request_iomux(MX53_PIN_ATA_DA_2, IOMUX_CONFIG_ALT1);
+ gpio_direction_output(IMX_GPIO_NR(7, 8), 0);
+ gpio_set_value(IMX_GPIO_NR(7, 8), 1);
+}
+#endif
+
static void setup_iomux_fec(void)
{
/*FEC_MDIO*/
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index d699010..9ce43d7 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -72,6 +72,19 @@
#define CONFIG_CMD_MII
#define CONFIG_CMD_NET
+/* USB Configs */
+#define CONFIG_CMD_USB
+#define CONFIG_CMD_FAT
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_MX5
+#define CONFIG_USB_STORAGE
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_ASIX
+#define CONFIG_USB_ETHER_SMSC95XX
+#define CONFIG_MXC_USB_PORT1
+#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW)
+#define CONFIG_MXC_USB_FLAGS 0
+
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
#define CONFIG_CONS_INDEX 1
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
