Re: [U-Boot] [PATCH v2] mx5: Mark lowlevel_init board-specific code
On 05/11/2012 21:07, Benoît Thébaudeau wrote: > The mx5 lowlevel_init.S contains board-specific code based on the reference > design. Let's keep it since it avoids creating new lowlevel_init files and it > may be used by many boards. But add a config to make it optional in order not > to > cause issues on boards not following this part of the reference design. > > Signed-off-by: Benoît Thébaudeau > Cc: Stefano Babic > Cc: Matt Sealey > --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci-mxc: Fix host power mask bit for i.MX35
On 16/11/2012 12:42, Benoît Thébaudeau wrote: > The correct bit for H1_PM is 16, not 8, which is the DP pull-up impedance > selection bit. > > This issue has been reported by Michael Burkey and fixed > by > Christoph Fritz on Linux, from which these > #define-s > had been copied. > > Signed-off-by: Benoît Thébaudeau > Cc: Stefano Babic > Cc: Marek Vasut > --- > .../drivers/usb/host/ehci-mxc.c |2 > +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git u-boot-imx-f22e4fa.orig/drivers/usb/host/ehci-mxc.c > u-boot-imx-f22e4fa/drivers/usb/host/ehci-mxc.c > index 7c5f71c..f2642a0 100644 > --- u-boot-imx-f22e4fa.orig/drivers/usb/host/ehci-mxc.c > +++ u-boot-imx-f22e4fa/drivers/usb/host/ehci-mxc.c > @@ -67,7 +67,7 @@ > #define MX35_H1_SIC_SHIFT21 > #define MX35_H1_SIC_MASK (0x3 << MX35_H1_SIC_SHIFT) > #define MX35_H1_PP_BIT (1 << 18) > -#define MX35_H1_PM_BIT (1 << 8) > +#define MX35_H1_PM_BIT (1 << 16) > #define MX35_H1_IPPUE_UP_BIT (1 << 7) > #define MX35_H1_IPPUE_DOWN_BIT (1 << 6) > #define MX35_H1_TLL_BIT (1 << 5) > Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci-mxc: Fix host power mask bit for i.MX25
On 16/11/2012 17:46, Benoît Thébaudeau wrote: > The correct bit for H1_PM is 16, not 8, which is the DP pull-up impedance > selection bit. > > This issue has been reported by Eric Bénard and fixed by > Christoph Fritz on Linux, from which these > #define-s > had been copied. > > Signed-off-by: Benoît Thébaudeau > Cc: Stefano Babic > Cc: Marek Vasut > --- > .../drivers/usb/host/ehci-mxc.c |2 > +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git u-boot-imx-f22e4fa.orig/drivers/usb/host/ehci-mxc.c > u-boot-imx-f22e4fa/drivers/usb/host/ehci-mxc.c > index 7c5f71c..352ad86 100644 > --- u-boot-imx-f22e4fa.orig/drivers/usb/host/ehci-mxc.c > +++ u-boot-imx-f22e4fa/drivers/usb/host/ehci-mxc.c > @@ -37,7 +37,7 @@ > #define MX25_H1_SIC_SHIFT21 > #define MX25_H1_SIC_MASK (0x3 << MX25_H1_SIC_SHIFT) > #define MX25_H1_PP_BIT (1 << 18) > -#define MX25_H1_PM_BIT (1 << 8) > +#define MX25_H1_PM_BIT (1 << 16) > #define MX25_H1_IPPUE_UP_BIT (1 << 7) > #define MX25_H1_IPPUE_DOWN_BIT (1 << 6) > #define MX25_H1_TLL_BIT (1 << 5) > Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] mx28evk: Configure CONFIG_BOOTDELAY to one second
On 16/11/2012 16:09, Fabio Estevam wrote: > From: Fabio Estevam > > One second is enough time for users to react in case they want to stop the > booting process. > > Signed-off-by: Fabio Estevam > --- > include/configs/mx28evk.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h > index 2916c71..8b89b25 100644 > --- a/include/configs/mx28evk.h > +++ b/include/configs/mx28evk.h > @@ -238,7 +238,7 @@ > */ > #define CONFIG_CMDLINE_TAG > #define CONFIG_SETUP_MEMORY_TAGS > -#define CONFIG_BOOTDELAY 3 > +#define CONFIG_BOOTDELAY 1 > #define CONFIG_BOOTFILE "uImage" > #define CONFIG_LOADADDR 0x4200 > #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR > Applied (whole series) to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mx5: Align SPI CS naming with i.MX53 reference manual
On 15/11/2012 22:23, Fabio Estevam wrote: > From: Fabio Estevam > > Align SPI chip select naming with i.MX53 reference manual. > > Signed-off-by: Fabio Estevam > --- Applied (whole series) to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx5: Mark lowlevel_init board-specific code
On 16/11/2012 23:42, Benoît Thébaudeau wrote: > Hi Stefano, > > On Wednesday, November 7, 2012 3:29:14 PM, Stefano Babic wrote: >> On 05/11/2012 21:07, Benoît Thébaudeau wrote: >>> The mx5 lowlevel_init.S contains board-specific code based on the >>> reference >>> design. Let's keep it since it avoids creating new lowlevel_init >>> files and it >>> may be used by many boards. But add a config to make it optional in >>> order not to >>> cause issues on boards not following this part of the reference >>> design. >> >> Right, and it is correct that this initialisation is not done for all >> boards. >> >> Acked-by: Stefano Babic > > You seem to have forgotten this one in your last couple of application rounds. That's right, I will push it - thanks. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] analyze/change assembly code
Hi Albert, On 11/10/2012 12:25 PM, Albert ARIBAUD wrote: Hi Gerlando, On Tue, 30 Oct 2012 12:08:01 +0100, Gerlando Falauto wrote: Hi all, we recently to had face some nasty issues, where for some reason two (functionally identical) versions of some code behave very differently. Namely, one version works and the other doesn't always work. It was clear from the beginning this was because of HW- (or compiler-) related issues. I thought it would then be useful to have a peek at what the compiler is doing behind the scenes, and possibly make some simple changes to the code. For instance, inserting some nops here and there, or reordering some instructions, may help in tracking down these different behaviors. I know the easiest way to LOOK at the file is simply to use objdump to disassemble an .o file. In the end I somehow managed to tamper with the makefiles so to get what I wanted for a given file, by adding a fake new ".s" target with the recipe to build it, and having the .o file depend on a ".S" file (which would be a manual/changed copy of the generated ".s" file) instead of the original ".c" file. This is however not linear and nice at all. So I was wondering whether there already is a well-established way of having the make process create (and keep) assembly files which can be then manually changed. Does my question make any sense at all? Any ideas? Add -save-temps to the gcc arguments? Watch out for parallel build issues, though. I tried, and it partly does the trick, in that the .s file is created and kept afterwards. Manually changing the .s file though doesn't help, as it gets overwritten by successive invocations... Thanks anyway, Gerlando ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sam9x5 can't find Nand flash
Hi Alex,
On 11/19/2012 13:40, alex wrote:
more information. samba script as below:
## Falshing binaries
puts "-I- === Initialize the NAND access ==="
NANDFLASH::Init
puts "-I- === Enable PMECC OS Parameters ==="
NANDFLASH::NandHeaderValue HEADER 0xc0c00405
puts "-I- === Erase all the NAND flash blocs and test the erasing ==="
NANDFLASH::EraseAllNandFlash
puts "-I- === Load the bootstrap: nandflash_at91sam9-ek in the first
sector ==="
NANDFLASH::SendBootFilePmeccCmd $bootstrapFile
puts "-I- === Load the u-boot image ==="
send_file {NandFlash} "$ubootFile" $ubootAddr 0
puts "-I- === Load the u-boot env image ==="
send_file {NandFlash} "$ubootenvFile" $ubootenvAddr 0
puts "-I- === Load the Kernel image ==="
send_file {NandFlash} "$kernelFile" $kernelAddr 0
puts "-I- === Enable trimffs ==="
NANDFLASH::NandSetTrimffs 1
puts "-I- === Load the linux file system ==="
send_file {NandFlash} "$rootfsFile" $rootfsAddr 0
puts "-I- === DONE. ==="
This is no help. Without any useful information.
At 2012-11-19 13:37:15,alex wrote:
I use u-boot v2010.06 with atmel's patch. I give u-boot 512K size.
U-Boot 2010.06-2-gb006d3d-dirty (Nov 19 2012 - 09:53:38)
DRAM: 128 MiB
NAND: No NAND device found!!!
NAND Flash not found !
No NAND device found!!!
0 MiB
You should also provide bootstrap log info.
I think the code is get from www.at91.com/linux4sam.
Anyway, I assume that you use the source code and package get for the
upper website. If so, the u-boot environment you change is overlap with
u-boot. (If you write the u-boot at offset 0x4, the size is larger
than 256K, that means: u-boot offset + u-boot size > 0x8). So, when
save environment, it will overwrite the u-boot, which cause this issue.
Please check it again. If all thing as I guess, you can change the
u-boot offset to 0x2, or change environment offset to 0xa. you
can choose which you prefer.
Best Regards,
Bo Shen
At 2012-11-19 11:19:25,"Bo Shen" mailto:voice.s...@atmel.com>> wrote:
>Hi Alex,
>
>On 11/19/2012 10:55, alex wrote:
>> Hi MAINTAINER:
>>Now I develop our product based on sam9x25 EVK, and redefine our NAND
>> partitions. I set u-boot environment in flash address0x8.
>> if "saveenv" and "reset", u-boot will print "can't find NAND flash". If
>> I set u-boot environment in the address 0xc as EVK board, it's OK. I
>> cant' know the reason.
>
>Which u-boot version do you use? Please also paste the u-boot boot log
here.
>
>Please also check the u-boot file size, will the env overlap with it?
>
>Best Regards,
>Bo Shen
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sam9x5 can't find Nand flash
more information. samba script as below:
## Falshing binaries
puts "-I- === Initialize the NAND access ==="
NANDFLASH::Init
puts "-I- === Enable PMECC OS Parameters ==="
NANDFLASH::NandHeaderValue HEADER 0xc0c00405
puts "-I- === Erase all the NAND flash blocs and test the erasing ==="
NANDFLASH::EraseAllNandFlash
puts "-I- === Load the bootstrap: nandflash_at91sam9-ek in the first sector ==="
NANDFLASH::SendBootFilePmeccCmd $bootstrapFile
puts "-I- === Load the u-boot image ==="
send_file {NandFlash} "$ubootFile" $ubootAddr 0
puts "-I- === Load the u-boot env image ==="
send_file {NandFlash} "$ubootenvFile" $ubootenvAddr 0
puts "-I- === Load the Kernel image ==="
send_file {NandFlash} "$kernelFile" $kernelAddr 0
puts "-I- === Enable trimffs ==="
NANDFLASH::NandSetTrimffs 1
puts "-I- === Load the linux file system ==="
send_file {NandFlash} "$rootfsFile" $rootfsAddr 0
puts "-I- === DONE. ==="
At 2012-11-19 13:37:15,alex wrote:
I use u-boot v2010.06 with atmel's patch. I give u-boot 512K size.
U-Boot 2010.06-2-gb006d3d-dirty (Nov 19 2012 - 09:53:38)
DRAM: 128 MiB
NAND: No NAND device found!!!
NAND Flash not found !
No NAND device found!!!
0 MiB
At 2012-11-19 11:19:25,"Bo Shen" wrote:
>Hi Alex,
>
>On 11/19/2012 10:55, alex wrote:
>> Hi MAINTAINER:
>>Now I develop our product based on sam9x25 EVK, and redefine our NAND
>> partitions. I set u-boot environment in flash address0x8.
>> if "saveenv" and "reset", u-boot will print "can't find NAND flash". If
>> I set u-boot environment in the address 0xc as EVK board, it's OK. I
>> cant' know the reason.
>
>Which u-boot version do you use? Please also paste the u-boot boot log here.
>
>Please also check the u-boot file size, will the env overlap with it?
>
>Best Regards,
>Bo Shen
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8 v3] Add TMU support for Exynos5250 based SMDK5250
Hello, Any other comments on this series? Can this be merged with the u-boot-samsung? Regards, Hatim Ali On Fri, Nov 9, 2012 at 4:32 AM, Simon Glass wrote: > Hi Hatim, > > On Thu, Nov 8, 2012 at 1:14 AM, Hatim Ali wrote: >> This patch series adds support for TMU driver using device tree for >> Exynos5250 >> based SMDK5250 board. >> This patch series is dependent on the patch series >> "Add DT based ethernet driver for SMDK5250" by Hatim Ali >> >> Changes since v2: >> - Replaced THERMAL with TMU in guards of tmu.h and exynos-tmu.h >> - Updated Monitor Commands in README >> >> Akshay Saraswat (6): >> EXYNOS5: FDT: Add TMU device node values >> EXYNOS5: TMU: Add driver for Thermal Management Unit >> EXYNOS5: Power down API for Thermal Management Unit >> Add a poll function to monitor events >> EXYNOS5: TMU: Add TMU status polling >> EXYNOS5: Config: Enable support for Exynos TMU driver >> >> Alim Akhtar (2): >> TMU: Add u-boot command to read current temp >> EXYNOS5: Config: Enable tmu command > > I have checked this series again and it looks fine to me. You still > have THERMAL_H in one place but it doesn't matter. > > I will not ack each patch again since you already have my ack. I > wonder if you should remove the ack when you update a patch? > > Regards, > Simon > >> >> README|8 + >> arch/arm/cpu/armv7/exynos/power.c | 15 ++ >> arch/arm/dts/exynos5250.dtsi |5 + >> arch/arm/include/asm/arch-exynos/exynos-tmu.h | 58 + >> arch/arm/include/asm/arch-exynos/power.h |8 + >> board/samsung/dts/exynos5250-smdk5250.dts | 13 + >> board/samsung/smdk5250/smdk5250.c | 36 +++ >> common/Makefile |1 + >> common/cmd_tmu.c | 51 + >> common/console.c |5 + >> doc/device-tree-bindings/exynos/tmu.txt | 35 +++ >> drivers/power/Makefile|1 + >> drivers/power/exynos-tmu.c| 297 >> + >> include/common.h |6 + >> include/configs/exynos5250-dt.h |7 + >> include/fdtdec.h |1 + >> include/tmu.h | 46 >> lib/fdtdec.c |1 + >> 18 files changed, 594 insertions(+), 0 deletions(-) >> create mode 100644 arch/arm/include/asm/arch-exynos/exynos-tmu.h >> create mode 100644 common/cmd_tmu.c >> create mode 100644 doc/device-tree-bindings/exynos/tmu.txt >> create mode 100644 drivers/power/exynos-tmu.c >> create mode 100644 include/tmu.h >> >> -- >> 1.7.2.3 >> > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5 v2] Add DT based ethernet driver for SMDK5250
Hello, Are there any other comments on this patch series? Can these be merged with the u-boot-samsung? Regards, Hatim Ali -- Forwarded message -- From: Simon Glass Date: Wed, Nov 7, 2012 at 5:18 AM Subject: Re: [U-Boot] [PATCH 0/5 v2] Add DT based ethernet driver for SMDK5250 To: Hatim Ali Cc: u-boot@lists.denx.de Hi Katin, On Tue, Nov 6, 2012 at 2:13 AM, Hatim Ali wrote: > This patch series enables the DT support on SMDK5250. > Ethernet is the first driver whose discovery is based on DT node. > More DT based drivers to be added subsequently > > Changes since v1: > - Renamed the smdk5250.h file to exynos5250-dt.h to create a common > configuration file which can be used by all the boards based on > exynos5250 using Device Tree. > - Created a new smdk5250.h file specifying the dts file specific to > SMDK5250 > - Incorporated minor nit (removal of blank lines) I went through this series again, and it looks good to me. The series: Acked-by: Simon Glass > > Hatim Ali (5): > EXYNOS5: FDT: add initial dts file for EXYNOS5250, SMDK5250 > fdt: exynos5: Add DT node definition for SROM and SMSC9215 > exynos5: Add DT based driver for SMC911X ethernet > exynos5: config: Rename the smdk5250.h to exynos5250-dt.h > SMDK5250: config: Add configuration file for SMDK5250 board > > arch/arm/dts/exynos5250.dtsi | 31 > arch/arm/include/asm/arch-exynos/sromc.h | 18 ++ > board/samsung/dts/exynos5250-smdk5250.dts | 29 +++ > board/samsung/smdk5250/smdk5250.c | 115 + > include/configs/exynos5250-dt.h | 267 > + > include/configs/smdk5250.h| 245 +- > include/fdtdec.h |2 + > lib/fdtdec.c |2 + > 8 files changed, 442 insertions(+), 267 deletions(-) > create mode 100644 arch/arm/dts/exynos5250.dtsi > create mode 100644 board/samsung/dts/exynos5250-smdk5250.dts > create mode 100644 include/configs/exynos5250-dt.h > > -- > 1.7.2.3 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ping failed; host 192.168.1.101 is not alive
Hi I have submitted the patch http://patchwork.ozlabs.org/patch/199895/ It required little more fixes in OMAP3 SPI code. Now its working like a charm There are no changes need to be done in enc28j60 code. Attach logs for your reference http://old.nabble.com/file/p34695543/working.cap working.cap Ajoy akdas75 wrote: > > Hi Anatolij and Wolfgang Denk > > I will submit the patches soon. > I am reading the links to submit patches. > > The OMAP3 SPI patch is required for proper functioning of that subsytem. > I studied the linux driver and the TRM to arrive at this changes. > > I wonder how these changes were not incorporated by anyone. > > Ajoy > > > akdas75 wrote: >> >> Hi Anatolij and Wolfgang Denk >> >> I have solved the problem. >> There are some "must" changes in omap3_spi.c to make it working. >> Otherwise it will not be >> behave in the expected way. >> There are also few changes in enc28j60.c file to make it more stable. >> I have attached the snapshot of both ping and tftp. >> >> Please let me know if I can submit the changes as patch because they are >> required >> for proper working of the omap3 SPI. >> http://old.nabble.com/file/p34659079/ping_success.cap ping_success.cap >> >> Ajoy >> >> >> >> >> akdas75 wrote: >>> >>> Hi >>> >>> I analyzed the code and put some prints to find the below mentioned >>> behavior. >>> The ARP packet is being received by ENC28J60 but when it reaches the >>> software pkt format is not correct. >>> A 0 is being appended to the packet. >>> >>> After analysis I found this errata mentioned in ENC28J60 errata sheet >>> is not applied for the initial case >>> (for the first packet). Later on it is fine. >>> I have made the changes and I need to test it today night after office. >>> >>> Module: Memory (Ethernet Buffer) The receive hardware may corrupt the >>> circular >>> receive buffer (including the Next Packet Pointer and receive status >>> vector fields) when an even value >>> is programmed into the ERXRDPTH:ERXRDPTL registers. >>> Work around >>> Ensure that only odd addresses are written to the ERXRDPT registers. >>> Assuming that ERXND contains >>> an odd value, many applications can derive a suitable value to write to >>> ERXRDPT by subtracting >>> one from the Next Packet Pointer (a value always ensured to be even >>> because of hardware padding) >>> and then compensating for a potential ERXST to ERXND wraparound. >>> Assuming that the receive >>> buffer area does not span the 1FFFh to h memory boundary, the logic >>> in Example 1 will ensure that >>> ERXRDPT is programmed with an odd value >>> >>> Are you aware of any such change required in the ENC28J60 uboot code. >>> Kindly let me know if anybody has faced such issue >>> >>> >>> akdas75 wrote: Hi As per your suggestion I tried 2012.10 Still the result is same. But it shows receive length is zero. I have attached the logs I have attached the changes to make ethernet work. As I am new to this forum I hope you said me to reply to this mailing list. Ajoy http://old.nabble.com/file/p34620403/uboot.txt uboot.txt http://old.nabble.com/file/p34620403/uboot.patch uboot.patch akdas75 wrote: > > hi > > No I dont have any firewall running. > I have enabled to receive all packets [] > > i am using the uboot version 2011.03 with the following changes. > But i think it will not affect the ping functionality. > > Any help. I will try putting more logs and pointing the issue. > > attached is the patch > > Ajoy > > > > akdas75 wrote: >> >> hi Anatolij >> I tried your suggestion >> I generate a macid from uboot/tools/gen_eth_addr. >> Still the ping says "host not alive" >> >> I have attached the uboot log >> and also the wireshark snapshot on the host >> >> host : 192.168.1.101 >> development board : 192.168.1.100 >> >> Ajoy >> http://old.nabble.com/file/p34610904/uboot_log_1.txt uboot_log_1.txt >> http://old.nabble.com/file/p34610904/snap_wireshark_host.JPG >> snap_wireshark_host.JPG >> >> akdas75 wrote: >>> >>> Hi http://old.nabble.com/file/p34608548/uboot-log.rtf uboot-log.rtf >>> >>> I am using beagle board C4 with zippy expansion board. >>> I am able to do NFS at the kernel level. >>> I want to o tftp at the u-boot level. >>> my beagle board is connected to the host via cross ethernet cable. >>> the phy chip is enc28j60. >>> when i ping the host it says host not alive. >>> >>> i have attached the env variables >>> >>> please help >>> >>> >> >> > http://old.nabble.com/file/p34615656/u-boot.patch u-boot.patch > >>> >>> >> >> > > -- View this message in context: http://old.nabble.com/ping-failed--host-192.168.1.101-
Re: [U-Boot] [PATCH 4/8] mx6qsabre_common: Configure CONFIG_BOOTDELAY to one second
>-Original Message- >From: Fabio Estevam [mailto:feste...@gmail.com] >Sent: Friday, November 16, 2012 11:09 PM >To: sba...@denx.de >Cc: Liu Hui-R64343; u-boot@lists.denx.de; Estevam Fabio-R49496 >Subject: [PATCH 4/8] mx6qsabre_common: Configure CONFIG_BOOTDELAY to >one second > >From: Fabio Estevam > >One second is enough time for users to react in case they want to stop the >booting process. > >Signed-off-by: Fabio Estevam Acked-by: Jason Liu >--- > include/configs/mx6qsabre_common.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/include/configs/mx6qsabre_common.h >b/include/configs/mx6qsabre_common.h >index 50f3b01..b8621b8 100644 >--- a/include/configs/mx6qsabre_common.h >+++ b/include/configs/mx6qsabre_common.h >@@ -76,7 +76,7 @@ > #define CONFIG_CMD_BOOTZ > #undef CONFIG_CMD_IMLS > >-#define CONFIG_BOOTDELAY 3 >+#define CONFIG_BOOTDELAY 1 > > #define CONFIG_LOADADDR0x1080 > #define CONFIG_SYS_TEXT_BASE 0x1780 >-- >1.7.9.5 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] mx6qsabrelite: Configure CONFIG_BOOTDELAY to one second
>-Original Message- >From: Fabio Estevam [mailto:feste...@gmail.com] >Sent: Friday, November 16, 2012 11:09 PM >To: sba...@denx.de >Cc: Liu Hui-R64343; u-boot@lists.denx.de; Estevam Fabio-R49496 >Subject: [PATCH 3/8] mx6qsabrelite: Configure CONFIG_BOOTDELAY to one >second > >From: Fabio Estevam > >One second is enough time for users to react in case they want to stop the >booting process. > >Signed-off-by: Fabio Estevam Acked-by: Jason Liu >--- > include/configs/mx6qsabrelite.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/include/configs/mx6qsabrelite.h >b/include/configs/mx6qsabrelite.h index 318f857..759275a 100644 >--- a/include/configs/mx6qsabrelite.h >+++ b/include/configs/mx6qsabrelite.h >@@ -144,7 +144,7 @@ > > #undef CONFIG_CMD_IMLS > >-#define CONFIG_BOOTDELAY 3 >+#define CONFIG_BOOTDELAY 1 > > #define CONFIG_PREBOOT "" > >-- >1.7.9.5 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sam9x5 can't find Nand flash
Hi Alex, On 11/19/2012 10:55, alex wrote: Hi MAINTAINER: Now I develop our product based on sam9x25 EVK, and redefine our NAND partitions. I set u-boot environment in flash address0x8. if "saveenv" and "reset", u-boot will print "can't find NAND flash". If I set u-boot environment in the address 0xc as EVK board, it's OK. I cant' know the reason. Which u-boot version do you use? Please also paste the u-boot boot log here. Please also check the u-boot file size, will the env overlap with it? Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sam9x5 can't find Nand flash
Hi MAINTAINER: Now I develop our product based on sam9x25 EVK, and redefine our NAND partitions. I set u-boot environment in flash address0x8. if "saveenv" and "reset", u-boot will print "can't find NAND flash". If I set u-boot environment in the address 0xc as EVK board, it's OK. I cant' know the reason. Best Regards, Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] dtc/libfdt: introduce fdt types for annotation by endian checkers
On Wed, Nov 14, 2012 at 11:12:04PM -0600, Kim Phillips wrote:
> On Thu, 15 Nov 2012 15:43:40 +1100
> David Gibson wrote:
>
> > On Wed, Nov 14, 2012 at 06:59:58PM -0600, Kim Phillips wrote:
> > > +#define EXTRACT_BYTE(x, n) ((unsigned long long)((uint8_t *)&x)[n])
> > > +#define __SWAB16(x) ((EXTRACT_BYTE(x, 0) << 8) | EXTRACT_BYTE(x, 1))
> > > +#define __SWAB32(x) ((EXTRACT_BYTE(x, 0) << 24) | (EXTRACT_BYTE(x, 1) <<
> > > 16) | \
> > > + (EXTRACT_BYTE(x, 2) << 8) | EXTRACT_BYTE(x, 3))
> > > +#define __SWAB64(x) ((EXTRACT_BYTE(x, 0) << 56) | (EXTRACT_BYTE(x, 1) <<
> > > 48) | \
> > > + (EXTRACT_BYTE(x, 2) << 40) | (EXTRACT_BYTE(x, 3) << 32) | \
> > > + (EXTRACT_BYTE(x, 4) << 24) | (EXTRACT_BYTE(x, 5) << 16) | \
> > > + (EXTRACT_BYTE(x, 6) << 8) | EXTRACT_BYTE(x, 7))
> >
> > This is not right, or at least very misleading. "swab" usually refers
> > to an unconditional byteswap. But the macros above are nops on a
> > big-endian machine.
>
> but they don't get called on a big endian system.
Yes, which means the nop-on-bigendian is double-implemented which is
also ugly.
> This is the name
> linux uses.
I'm not sure exactly which *swab* functions in Linux you're referring
to, but I'm pretty sure most of those are unconditional swaps.
> If you want them renamed, please suggest names - I
> can't read your mind.
Well, FDT_TO_CPU would do.
> > > -static inline uint32_t fdt32_to_cpu(uint32_t x)
> > > -{
> > > - return (EXTRACT_BYTE(0) << 24) | (EXTRACT_BYTE(1) << 16) |
> > > (EXTRACT_BYTE(2) << 8) | EXTRACT_BYTE(3);
> > > +/*
> > > + * determine host endianness:
> > > + * *__first_byte is 0x11 on big endian systems
> > > + * *__first_byte is 0x44 on little endian systems
> > > + */
> > > +static const uint32_t __native = 0x11223344u;
> > > +static const uint8_t *__first_byte = (const uint8_t *)&__native;
> > > +
> > > +#define DEF_FDT_TO_CPU(bits) \
> > > +static inline uint##bits##_t fdt##bits##_to_cpu(fdt##bits##_t x) \
> > > +{ \
> > > + if (*__first_byte == 0x11) \
> > > + return (__force uint##bits##_t)x; \
> > > + else \
> > > + return (__force uint##bits##_t)__SWAB##bits(x); \
> > > }
> > > -#define cpu_to_fdt32(x) fdt32_to_cpu(x)
> > > +DEF_FDT_TO_CPU(16)
> > > +DEF_FDT_TO_CPU(32)
> > > +DEF_FDT_TO_CPU(64)
> >
> > In fact, I really don't see why you're rewriting the byteswapper
> > functions as part of this patch. The existing versions aren't very
> > nice, but if you want to rewrite those, please do it in a separate
> > patch.
>
> This patchseries is about silencing sparse warnings in linux,
> u-boot, and libfdt. Sparse is intelligent in that if you mismatch a
> native type of value 0 to a bitwise restricted type, it won't call a
> warning. The existing short-circuiting of the byteswapper
> functions, i.e., defining cpu_to_fdt32(x) to fdt32_to_cpu(x) and
> vice versa doesn't allow for correct attribution propagation.
Ah, right, yes that will have to go. You've also added the explicit
endianness test, though, which is a redundant change.
> Therefore I chose to allow sparse to see the actual conversion. If
> you have any other ideas on how to silence sparse in libfdt, let me
> know.
Hrm. So you could either rename the macros, or just duplicate the
code in the to versions of the functions.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3 SPI : Fixed bugs related to SPI transfer
Hi Peter I described the entire patch in small paragraphs so it is better to understand The first paragraph is for posted writes (courtesy linux OMAP3 SPI driver code) The last three paragraphs actually fixes the bug related to the operation of the OMAP3 SPI controller in TX_ONLY and RX_ONLY mode. Only after implementing the those three things 'together' the TX_ONLY and RX_ONLY transfers works perfectly. The problem occurs when the RX transfer is immediately followed by the TX transfer. So shall I divide them in four patches according to the paragraphs Or shall I make two patches according to the functionality getting fixed Please suggest Ajoy From: Peter Korsgaard To: Ajoy Kumar Das Cc: u-boot@lists.denx.de; Tom Rini ; jacopo mondi Sent: Sunday, 18 November 2012 5:23 AM Subject: Re: [U-Boot] [PATCH] OMAP3 SPI : Fixed bugs related to SPI transfer > "Ajoy" == Ajoy Kumar Das writes: Ajoy> From: ajoy Ajoy> Added posted writes (read after writes) to effect the Ajoy> change immediately for channel confiuration and channel Ajoy> enable register Ajoy> Disable the channel to purge receieve data in TX_ONLY Ajoy> mode transfer otherwise rx data will get affected by Ajoy> the next immediate RX_ONLY mode transfer Ajoy> Wait for the EOT bit to be set after last byte has been Ajoy> loaded to TX shift register in the the TX_ONLY mode.This Ajoy> ensures TX data has been completely shifted out Ajoy> Disable the channel in RX_ONLY mode before reading the Ajoy> last data from RXX register to prevent the SPI slave Ajoy> to transmit next word So it is 4 separate fixes? Could you please split it up in 4 separate patches? -- Bye, Peter Korsgaard___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb: ehci: Take advantage of the new multi-controller feature for MXC
Dear Benoît Thébaudeau, > Dear Marek Vasut, > > On Wednesday, November 7, 2012 3:13:51 PM, Marek Vasut wrote: > > Dear Lucas Stach, > > > > > Dear Marek Vasut, > > > > > > Am Mittwoch, den 07.11.2012, 14:25 +0100 schrieb Marek Vasut: > > > Now I would still argue that we should keep the two step init > > > model, > > > first we instantiate the driver with some form of pdata (we can > > > certainly come up with a one-struct-fits-all for this) and later > > > when we > > > are really going to use one specific controller we do the real > > > hardware > > > init. > > > > > > Now we seem to differ about the meaning of the usb stack functions. > > > From > > > your mails I see that you want ehci_hcd_init as the first init step > > > where we instantiate the driver (and therefore need the pdata) > > > > No, I don't care what you do in your ehci_hcd_init. And I don't care > > if you > > instantiate it there. But I suspect I understand your problem. I > > suspect the > > driver shall be instantiated from elsewhere and ehci_hcd_init() call > > shall only > > be used to fine-tune (or work around) controller bugs. > > Not only for controller bugs, but also for related board operations through > board_ehci_hcd_init(), or simply to perform a clean new init following a > stop (e.g. in the case of the "usb reset" command). > > > > where I > > > treated it as the second step, because currently it is the point > > > where > > > the upper USB stack levels indicate that they are going to use a > > > specific controller. > > > > > > We should probably come up with some consensus about this before > > > going > > > forward. Sadly my free time is really limited right now, so it's > > > hard > > > for me to keep up even with things I planned to do in the next few > > > weeks, not to speak about playing around with the driver model. > > > > You're actually free to not work on that. Concensus is, I think the > > multi- > > controller thing is misdesigned and we rather fix it sooner than > > later. > > > > See my comment above about how I'd like to see it. > > If I understand correctly what you said, ehci_hcd_init() can be left > unchanged because you don't care about what it does, so it will keep using > the USB controller index from the command line. And we should add some > "int ehci_hcd_bind(void *pdata)" that would be called by the board init > files to perform the driver instantiation. > > Until the driver model is applied, this instantiation would be an empty > operation except for the drivers like ehci-mxc.c that need some platform > data. Hence, for now, this ehci_hcd_bind() function would have to be > implemented only for such drivers, which would be a small change that can > be done step by step. > > Correct me if I'm wrong above. My goal here is only to find a quick and > simple solution to take advantage of the multi-controller feature on MXC. > I don't have enough time to rework the whole infrastructure, so if this > goal is incompatible with the current infrastructure and how you want to > make it evolve, I'll come back when the infrastructure allows to truly use > this feature. Yes, let's try ehci_hcd_bind(). Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb: ehci: Take advantage of the new multi-controller feature for MXC
Dear Marek Vasut, On Wednesday, November 7, 2012 3:13:51 PM, Marek Vasut wrote: > Dear Lucas Stach, > > > Dear Marek Vasut, > > > > Am Mittwoch, den 07.11.2012, 14:25 +0100 schrieb Marek Vasut: > > Now I would still argue that we should keep the two step init > > model, > > first we instantiate the driver with some form of pdata (we can > > certainly come up with a one-struct-fits-all for this) and later > > when we > > are really going to use one specific controller we do the real > > hardware > > init. > > > > Now we seem to differ about the meaning of the usb stack functions. > > From > > your mails I see that you want ehci_hcd_init as the first init step > > where we instantiate the driver (and therefore need the pdata) > > No, I don't care what you do in your ehci_hcd_init. And I don't care > if you > instantiate it there. But I suspect I understand your problem. I > suspect the > driver shall be instantiated from elsewhere and ehci_hcd_init() call > shall only > be used to fine-tune (or work around) controller bugs. Not only for controller bugs, but also for related board operations through board_ehci_hcd_init(), or simply to perform a clean new init following a stop (e.g. in the case of the "usb reset" command). > > where I > > treated it as the second step, because currently it is the point > > where > > the upper USB stack levels indicate that they are going to use a > > specific controller. > > > > We should probably come up with some consensus about this before > > going > > forward. Sadly my free time is really limited right now, so it's > > hard > > for me to keep up even with things I planned to do in the next few > > weeks, not to speak about playing around with the driver model. > > You're actually free to not work on that. Concensus is, I think the > multi- > controller thing is misdesigned and we rather fix it sooner than > later. > > See my comment above about how I'd like to see it. If I understand correctly what you said, ehci_hcd_init() can be left unchanged because you don't care about what it does, so it will keep using the USB controller index from the command line. And we should add some "int ehci_hcd_bind(void *pdata)" that would be called by the board init files to perform the driver instantiation. Until the driver model is applied, this instantiation would be an empty operation except for the drivers like ehci-mxc.c that need some platform data. Hence, for now, this ehci_hcd_bind() function would have to be implemented only for such drivers, which would be a small change that can be done step by step. Correct me if I'm wrong above. My goal here is only to find a quick and simple solution to take advantage of the multi-controller feature on MXC. I don't have enough time to rework the whole infrastructure, so if this goal is incompatible with the current infrastructure and how you want to make it evolve, I'll come back when the infrastructure allows to truly use this feature. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3 SPI : Fixed bugs related to SPI transfer
> "Ajoy" == Ajoy Kumar Das writes: Ajoy> From: ajoy Ajoy> Added posted writes (read after writes) to effect the Ajoy> change immediately for channel confiuration and channel Ajoy> enable register Ajoy> Disable the channel to purge receieve data in TX_ONLY Ajoy> mode transfer otherwise rx data will get affected by Ajoy> the next immediate RX_ONLY mode transfer Ajoy> Wait for the EOT bit to be set after last byte has been Ajoy> loaded to TX shift register in the the TX_ONLY mode.This Ajoy> ensures TX data has been completely shifted out Ajoy> Disable the channel in RX_ONLY mode before reading the Ajoy> last data from RXX register to prevent the SPI slave Ajoy> to transmit next word So it is 4 seperate fixes? Could you please split it up in 4 seperate patches? -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Moschip ethernet adapter is not seen as ethernet device
Hello,
I tried use my USB ETH adapter. Following README files I addes into
beagle.h file (my board is beagleboard) this:
#define CONFIG_USB_HOST_ETHER/* Enable USB Ethernet adapters */
#define CONFIG_USB_ETHER_ASIX/* Asix, or whatever driver(s) you want */
#define CONFIG_CMD_NET
#define CONFIG_CMD_PING
#define CONFIG_CMD_DHCP
#define CONFIG_BOOTP_SUBNETMASK
#define CONFIG_BOOTP_GATEWAY
#define CONFIG_BOOTP_HOSTNAME
#define CONFIG_BOOTP_BOOTPATH
and into asix.c file this:
{ 0x9710, 0x7830, FLAG_TYPE_AX88172},
I based on what my host Linux showed to me:
Vendor specific, USB Revision 2.0
- Moschip Semiconductor UA0025C 6e003e8f
- Class: Vendor specific
- PacketSize: 64 Configurations: 1
- Vendor: 0x9710 Product 0x7830 Version 1.0
Configuration: 1
- Interfaces: 1 Bus Powered Remote Wakeup 500mA
Interface: 0
- Alternate Setting 0, Endpoints: 3
- Class Vendor specific
- Endpoint 1 In Bulk MaxPacket 512
- Endpoint 2 Out Bulk MaxPacket 512
- Endpoint 3 In Interrupt MaxPacket 16 Interval 1ms
But U-Boot don't see it as Ethernet Device, it only recognize it in tree:
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
OMAP3 beagleboard.org # usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Vendor specific (480 Mb/s, 500mA)
Moschip Semiconductor UA0025C 6e003e8f
Could you help me with this, please?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
