Re: [U-Boot] calling pci_init before relocation?
On 01/31/2011 09:45 AM, Heiko Schocher wrote: I think, on arm plattforms we should move the pci_init as it is done on powerpc plattforms, to board_init_r. It seems to me, that this is a leftover from introducing relocation to arm. I also just could think of using a PCI console before relocation... and if I looked right, this is not used on any arm plattform ... Fine. I'll include that change with the other changes needed to get PCI up again on IXP425. cu Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Dear Albert ARIBAUD, In message 4d47b20b.5040...@free.fr you wrote: variables occupy space in the U-Boot binary? If they do, then *that* must be fixed rather than allocating a fixed address for them. In ARM achitectures, the linker file makes sure the BSS is at the end of the image and is not loadable, so the ELF to bin conversion just skips them. Maybe the linker file you're using here does not do this? Answering myself: after reading Vaibhav's answer, I should amend my question aboce. Seems like the issue is the SPL has a BSS in IRAM, or in whatever memory it lands in. In that case, there's indeed no fix except putting the buffers in DRAM. well, there _is_ an obvious fix: put the BSS inS DRAM where we have sufficient room for it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The idea of male and female are universal constants. -- Kirk, Metamorphosis, stardate 3219.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] calling pci_init before relocation?
Hello Michael, Michael Schwingen wrote: On 01/31/2011 09:45 AM, Heiko Schocher wrote: I think, on arm plattforms we should move the pci_init as it is done on powerpc plattforms, to board_init_r. It seems to me, that this is a leftover from introducing relocation to arm. I also just could think of using a PCI console before relocation... and if I looked right, this is not used on any arm plattform ... Fine. I'll include that change with the other changes needed to get PCI up again on IXP425. Ok, thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Dear Wolfgang, On Tuesday 01 February 2011 01:25 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4d4798e2.3050...@ti.com you wrote: I had been working on creating an MMC SPL for OMAP4. OMAP boards typically support booting from the FAT partition of a removable SD/MMC card. So, we need to have FAT support in the SPL. But I am having some difficulties in adding FAT support to SPL. BSS footprint of fat.c is very high. It has three buffers each of size 64KB. To workaround this problem I have done something like below(The way x-loader works around this problem today). CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok? Why would that be necessary? Just put the BSS segment in SDRAM, and everything is fine, isn't it? SDRAM is initialized by the SPL. So, bss can not be initialized and used until SDRAM initialization is complete. I would prefer to have rest of the bss in internal RAM so that it's available as soon as we enter C code. Also, I was wondering why we need 3 such scratch buffers in this implementation. I do not understand this code. But I was wondering if we could work with just one 64K buffer? I have no idea. I am not familiar with that code either. Probably I will give it a try once I solve some other issues I am facing in getting FAT to work. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Hi Vaibhav, On Tuesday 01 February 2011 12:22 PM, Bedia, Vaibhav wrote: Hi Aneesh, On Tuesday, February 01, 2011 10:54 AM, Aneesh V wrote: Dear Wolfgang, I had been working on creating an MMC SPL for OMAP4. OMAP boards typically support booting from the FAT partition of a removable SD/MMC card. So, we need to have FAT support in the SPL. But I am having some difficulties in adding FAT support to SPL. BSS footprint of fat.c is very high. It has three buffers each of size 64KB. To workaround this problem I have done something like below(The way x-loader works around this problem today). CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok? [...] I guess you will hit a similar issue with the networking related code is used (I am not sure if SPL uses it). That also requires a decent size of bss. Luckily we don't need networking related code in SPL. Is having a config option to specify the location of bss (like CONFIG_SYS_BSS_ADDR) better/acceptable? I would prefer to have rest of the BSS in internal RAM itself. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] mtd: add writebufsize field to mtd_info struct
Hi Detlev, Detlev Zundel wrote: Hi Stefan, do you have any comment on this series? I delegated the patches to you in patchwork already :) No seriously, the patches look sane and are in accordance to what is done in Linux This field will be used to indicate the write buffer size of the MTD device. UBI will set it's minimal I/O unit size (min_io_size) to the indicated write buffer size. By this change we intend to fix failed recovery of UBIFS partitions we currently observe on NOR flash when mounting the partition after unclean unmount. Currently the min_io_size is set to mtd-writesize (which is 1 byte for NOR flash). But flash programming is often done from prepared write buffer containing multiple bytes and is performed in one programming operation which could be interrupted by a power cut or a system reset causing corrupted (partially written) areas in a flash sector. Knowing the size of potentially corrupted areas UBIFS scanning and recovery algorithms are able to perform successful recovery. Signed-off-by: Holger Brunck holger.bru...@keymile.com as I told in another mail, the min I/O size adaption patch leads to incompatibilites for the UBIFS and therefore the similar patch in linux kernel was reverted. But anyway the first five patches in the patch serie are already part of the mtd layer of the linux kernel. So the patches 1-5 of this series can also be committed to u-boot. Whats your opinion? Regards Holger Brunck ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Hi Albert, On Tuesday 01 February 2011 12:41 PM, Albert ARIBAUD wrote: Le 01/02/2011 08:04, Albert ARIBAUD a écrit : I'd like to make sure I understand the issue. Do these three BSS variables occupy space in the U-Boot binary? If they do, then *that* must be fixed rather than allocating a fixed address for them. In ARM achitectures, the linker file makes sure the BSS is at the end of the image and is not loadable, so the ELF to bin conversion just skips them. Maybe the linker file you're using here does not do this? Answering myself: after reading Vaibhav's answer, I should amend my question aboce. Seems like the issue is the SPL has a BSS in IRAM, or in whatever memory it lands in. In that case, there's indeed no fix except putting the buffers in DRAM. Yes, that's right. SPL has code, data and bss in internal RAM. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PING] Re: [PATCH] add print_cpuinfo to s3c24x0
Hello Any news? http://lists.denx.de/pipermail/u-boot/2010-December/083032.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PING] Re: [PATCH V3] update VCMA9 port
Hello Any news? http://lists.denx.de/pipermail/u-boot/2011-January/085072.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
On Tuesday, February 01, 2011 1:57 PM, V, Aneesh wrote: Hi Vaibhav, [...] I guess you will hit a similar issue with the networking related code is used (I am not sure if SPL uses it). That also requires a decent size of bss. Luckily we don't need networking related code in SPL. It might be required later on :) Is having a config option to specify the location of bss (like CONFIG_SYS_BSS_ADDR) better/acceptable? I would prefer to have rest of the BSS in internal RAM itself. Instead of adding workarounds for each driver I think putting BSS in SDRAM as pointed out by Wolfgang is better. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
On Tuesday, February 01, 2011 1:48 PM, Aneesh V wrote: Dear Wolfgang, On Tuesday 01 February 2011 01:25 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4d4798e2.3050...@ti.com you wrote: I had been working on creating an MMC SPL for OMAP4. OMAP boards typically support booting from the FAT partition of a removable SD/MMC card. So, we need to have FAT support in the SPL. But I am having some difficulties in adding FAT support to SPL. BSS footprint of fat.c is very high. It has three buffers each of size 64KB. To workaround this problem I have done something like below(The way x-loader works around this problem today). CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok? Why would that be necessary? Just put the BSS segment in SDRAM, and everything is fine, isn't it? SDRAM is initialized by the SPL. So, bss can not be initialized and used until SDRAM initialization is complete. I would prefer to have rest of the bss in internal RAM so that it's available as soon as we enter C code. This approach looks very messy to me. I would rather revisit the init sequence to see if things can be fixed there. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI flash protection
Hi Reinhard, On Mon, Jan 31, 2011 at 08:17:36AM +0100, Reinhard Meyer wrote: Dear Albert ARIBAUD, Simon Guinot, Here is the protect area map for a MX25L4005A 4Mb flash: bit 2 1 0 | protect level |___ 0 0 0 | none 0 0 1 | block 7 0 1 0 | block 6-7 0 1 1 | block 4-7 1 * * | all Block size is 64KB. The compiled U-Boot image is about 220KB and environment is 4KB. So, 4 blocks are required for U-Boot. I don't know your particular hardware, but is not u-boot (or the initial bootloader if there is any) fetched from the *beginning* of the flash? If so, you would have to *hardware* protect the *entire* flash. Yes you are right. Moreover the protected blocks (for a same register value) _could_ be different on an another Macronix device. For example, larger flash use 4 bits instead of 3 for block protection. In this case, a *software* protection mechanism like for NOR flash would be a better choice. Or no protection at all. After all, there is no such mechanism implemented for u-boot and Linux... Best regards, Simon signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand commands missing wtchdog reset
thanks for your reply. You are right, the format was totally wrong; I apologize! Concerning the patch itself: I agree: low-level hangups should trigger the watchdog although in this specific case the hangups will not occur due to a timeout construction surrounding it. Unfortunately I'm not able to investigate this any further To get this fix done: hopefully some u-boot-guru will do the dirty work... Jaap On 01/31/2011 08:25 PM, Scott Wood wrote: On Mon, 31 Jan 2011 13:16:59 -0600 Scott Woodscottw...@freescale.com wrote: On Mon, 31 Jan 2011 09:05:55 +0100 Jaap de Jongjaap.dej...@nedap.com wrote: Hi all, On my board (at91sam9263ek) I have enabled the watchdog. It will reset the processor after about 16 seconds. It looks like it is working but if I'm writing a large file into nand it seems that the watchdog is not reset and finally my processor resets. I've patched it, but I'm not sure if it is the right way to do it this way... So far we've been putting the watchdog resets in higher-level functions. It looks like the block-skipping versions have them, but the non-block-skipping versions don't (and the former will call the latter if it doesn't see any bad blocks). So I think this should go in nand_read() and nand_write(). If things hang up inside the low-level wait that should trigger the watchdog. Oh, and all patches require a sign-off, and the text above the patch should be what is intended to go in the git changelog, with any additional comments/greetings/etc below a --- line. See http://www.denx.de/wiki/U-Boot/Patches and also the Developer's Certificate of Origin in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=HEAD -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Dear Aneesh V, In message 4d47c1c9.1020...@ti.com you wrote: Why would that be necessary? Just put the BSS segment in SDRAM, and everything is fine, isn't it? SDRAM is initialized by the SPL. So, bss can not be initialized and used until SDRAM initialization is complete. I would prefer to have Yes, this is normal. rest of the bss in internal RAM so that it's available as soon as we enter C code. Well, you probably have to decide if you want an easy solution with the restictions of the internal RAM size, or a somewhat more complex solution with much more powerful resources. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's like deja vu all over again. - Yogi Berra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Dear Bedia, Vaibhav, In message fccfb4cdc6e5564b9182f639fc356087035fb31...@dbde02.ent.ti.com you wrote: Luckily we don't need networking related code in SPL. It might be required later on :) It makes no sense. Load and start U-Boot if you need more fancy features. If you need even more complex ones (say, TCP/IP and Java support) then boot and OS. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A witty saying proves nothing, but saying something pointless gets people's attention. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
On Tuesday, February 01, 2011 3:35 PM, Wolfgang Denk wrote: Dear Bedia, Vaibhav, In message fccfb4cdc6e5564b9182f639fc356087035fb31...@dbde02.ent.ti.com you wrote: Luckily we don't need networking related code in SPL. It might be required later on :) It makes no sense. Load and start U-Boot if you need more fancy features. If you need even more complex ones (say, TCP/IP and Java support) then boot and OS. I was thinking of a scenario where we have SPL being loaded over ethernet and the SPL stage then trying to load the 2nd stage using TFTP. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT PROBLEM] RAM loading RAMdisk addresses
Dear GRACE, ERWAN (ERWAN)** CTR **, please make sure to keep the mailing list on Cc: Also, please restrict your line length to some 70 characters or so. In message f427b25935cd0742ba694c0b6918f5701b70632...@frmrssxchmbse2.dc-m.alcatel-lucent.com you wrote: Thank you for your answer. I'd like to precise that the 2 RAMdisks weren't built from exactly the same set of files. There's a small difference between these RAMdisks as one of them was generated after replacing only one filewith another file which is supposed to be exactly the same as the first one. So, at the end of the day, these RAMdisks should have the same size but that isn't the case. I No, they should not. They should probably have the same content on a file system level, but when erasing a file and replacing it by another one (or even an identical copy) you will have other file system blocks used, other inode and free block lists, etc. In other words, the binary images of the file systems will be different. They will most probably also compress to different sizes, then. precise that I'm not the person who generated these RAMdisks, that's why I try to understand why there's such a difference betw een them. Moreover, in the messages displayed on the screen when the They are different images, with different sizes. board is booting, we can see that the addresses shown in the line Loading RAMdisk to ..., end ... OK are different. I'd like to know where these addressesare defined (in a configuration file? In They are computed based on the ramdisk sizes (plus some rounding). Given different ramdisk sizes you end up with different load addresses. There is no magic anywhere here. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Emotions are alien to me. I'm a scientist. -- Spock, This Side of Paradise, stardate 3417.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Le 01/02/2011 11:18, Bedia, Vaibhav a écrit : On Tuesday, February 01, 2011 3:35 PM, Wolfgang Denk wrote: Dear Bedia, Vaibhav, In message fccfb4cdc6e5564b9182f639fc356087035fb31...@dbde02.ent.ti.com you wrote: Luckily we don't need networking related code in SPL. It might be required later on :) It makes no sense. Load and start U-Boot if you need more fancy features. If you need even more complex ones (say, TCP/IP and Java support) then boot and OS. I was thinking of a scenario where we have SPL being loaded over ethernet and the SPL stage then trying to load the 2nd stage using TFTP. That would be way outside of how U-Boot is supposed to work: the assumption is that the SPL and U-Boot itself are present on-board anyway -- the rationale being that the board should be able to get to the U-Boot prompt with only the console attached. Regards, Vaibhav Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again
Le 01/02/2011 11:45, Michael Trimarchi a écrit : Hi /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld -pie -r -o libat91.o lowlevel_init.o clock.o cpu.o reset.o timer.o /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld: -r and -shared may not be used together I have tried this patch but this a problem releated to linking option. Do you have this problem? Michael Read up recent posts on the list: this was detected and is fixed in the master branch of the u-boot-arm repository. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] mtd: add writebufsize field to mtd_info struct
Hi Stefan, Stefan Roese wrote: as I told in another mail, the min I/O size adaption patch leads to incompatibilites for the UBIFS and therefore the similar patch in linux kernel was reverted. But anyway the first five patches in the patch serie are already part of the mtd layer of the linux kernel. So the patches 1-5 of this series can also be committed to u-boot. Whats your opinion? I have no problems with applying patches 1-5. But they have been submitted after the merge window was closed, so they will not make it into the next release. I'm volunteering to push those patches into next (once its available) via one of my git repositories (UBI/UBIFS or CFI) if nobody else objects. Ok, thanks. Regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI flash protection
Le 01/02/2011 10:09, Simon Guinot a écrit : In this case, a *software* protection mechanism like for NOR flash would be a better choice. Or no protection at all. After all, there is no such mechanism implemented for u-boot and Linux... Actually yes, there is, for NOR at least: in U-boot, sectors of NOR containing U-Boot and the environment are marked protected and thus trying to erase them will fail if you don't unprotect them first. As for Linux, you can define this when declaring the NOR device in the machine specific code. Best regards, Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v4] iMX5: EfikaMX: Preliminary board support
Le 01/02/2011 08:57, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4d47ad9a.3060...@free.fr you wrote: Wolfgang, do we: - wait for Prafulla's pull, or - just take Stefano's and move ahead with this release, and Prafulla stacks the current changes onto his 'next' branch until the MW opens again, or - something else yet? Let's please thake what we have so far and get some -rc1 out ASAP. When Prafulla's pull request comes, we can still decide if we pull this into mainline (I tend to do so if it's really a few days) or push into next. All right. Stefano, please provide a new pull request (with fixed modes); I'll take it then send out my own pull request. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Flashing ubinize image under U-Boot
Hi, I would like to support UBI under U-Boot. I could successfully flash a raw UBIFS image with the ubi write command, and also a UBI (ubinize) image with the nand write command. So it's working well. But in the second case, I will loose all existing information (e.g. the erase counters). Under Linux, there's the ubiformat application, which can flash this image, while preserves the existing informations. Does the U-Boot support flashing UBI (ubinize) images on the same way (preserving partition informations)? Or if not, then is there any plan to extend the ubi write to support the ubinize images? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
On Tuesday, February 01, 2011 4:19 PM, Albert ARIBAUD wrote: [...] That would be way outside of how U-Boot is supposed to work: the assumption is that the SPL and U-Boot itself are present on-board anyway -- the rationale being that the board should be able to get to the U-Boot prompt with only the console attached. Ok. Thanks for the clarification. In that case how can network boot be supported in U-Boot? Is the expectation that the SPL image which gets downloaded to internal RAM inits SDRAM, relocates to it and then download any other image like a larger U-Boot or the OS image? Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8xx malloc failing
Hi I have moved onto 2009.11, though more new versions are available but still .. I am using a MPC8XX based board( as earlier), but now the code is crashing in env_relocate() function. On applying debug prints I found that the code was failing in malloc with a Bus Fault with the following dump - Bus Fault @ 0x00fc9988, fixup 0x Machine check in kernel mode. Caused by (from msr): regs 00f42e20 Unknown values in msr NIP: 00FC9988 XER: 20002D10 LR: 00FC9988 REGS: 00f42e20 TRAP: 0200 DAR: 7D8C6218 MSR: 1002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 00FC9988 00F42F10 00F42F90 00FEC4AC 00F42B10 GPR08: 0020 02202800 B060C000 0020 82C00428 090700D8 00FFE400 FDFC7000 GPR16: 00019040 000448D1 045744A8 02420830 01A400E2 0001 0074832A GPR24: 00F42F90 00F42F78 4008 0072 00FF81E4 B0610008 00FFE424 7D8C6214 Call backtrace: 00FC9988 00FDCD34 00FCCD60 00FC93B8 machine check ### ERROR ### Please RESET the board ### Help Required. Thanks Saugat. On Mon, Jan 24, 2011 at 6:16 PM, Stefano Babic sba...@denx.de wrote: On 01/24/2011 01:12 PM, saugat mitra wrote: Hi Hi, I am trying to boot a MPC8XXX based board using uboot version 1.1.3. I am able to get the serial console up. But when I try to ping it gives me a time out error. On trying mii info and enabling debug messages I see that all the mii read messages are returning 0x. Could any one please suggest me steps to debug. make yourself a favour and upgrade to last U-Boot version. Your version is so ancient that is impossible to find which is the fix for you. And on current release, ethernet works well on mpc8xx (tested on a TQ tqm860L board). 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Dear Bedia, Vaibhav, In message fccfb4cdc6e5564b9182f639fc356087035fbed...@dbde02.ent.ti.com you wrote: In that case how can network boot be supported in U-Boot? Is the expectation that the SPL image which gets downloaded to internal RAM inits SDRAM, relocates to it and then download any other image like a larger U-Boot or the OS image? Can you please restrict your line length to some 70 or so characters? At the moment, U-Boot it self assumes that it somehow got started as a whole - either executing from reset (like when booting from NOR flash or similar bootable memory regions), or by being loaded by some secondary loader. So far, we support NAND and OneNAND in such a mode. Especially with NAND the restrictions may be severe - quite often the SPL code has to fit in as little as 4 KiB, sometimes even in 2 KiB. If you want SPL support for network booting, this needs to be added. I am not sure if this really makes sense, though. Many devices today have ROM code capable of reading boot images from USB or SDCard etc., so these are the naturally supported boot modes for such systems. I haven't seen network boot in such a configuration yet. If you add it, I guess the next steps will be support for WLAN booting and IPv6. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Why can you only have two doors on a chicken coop? If it had four it would be a chicken sedan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8xx malloc failing
Dear saugat mitra, In message AANLkTi=soo3ravp8ashbruynoq4ttc_f07miz3wrk...@mail.gmail.com you wrote: I have moved onto 2009.11, though more new versions are available but still .. Stefano wrote: | make yourself a favour and upgrade to last U-Boot version... Can you please explain why you stick again with code that is 1 year old? I am using a MPC8XX based board( as earlier), but now the code is crashing in env_relocate() function. On applying debug prints I found that the code was failing in malloc with a Bus Fault with the following dump - It would have been easier if you had just decoded the backtrace: Call backtrace: 00FC9988 00FDCD34 00FCCD60 00FC93B8 machine check Which routines are these addresses from? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In C we had to code our own bugs, in C++ we can inherit them. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] powerpc/8xxx: Refactor fsl_ddr_get_spd into common code from board
On Feb 1, 2011, at 4:08 AM, Timur Tabi wrote:
On Mon, Jan 31, 2011 at 11:28 PM, Kumar Gala ga...@kernel.crashing.org
wrote:
+#if defined(SPD_EEPROM_ADDRESS) || \
+defined(SPD_EEPROM_ADDRESS1) || defined(SPD_EEPROM_ADDRESS2) || \
+defined(SPD_EEPROM_ADDRESS3) || defined(SPD_EEPROM_ADDRESS4)
+#if (CONFIG_NUM_DDR_CONTROLLERS == 1) (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
+u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
+ [0][0] = SPD_EEPROM_ADDRESS,
+};
+#endif
+#if (CONFIG_NUM_DDR_CONTROLLERS == 2) (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
+u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
+ [0][0] = SPD_EEPROM_ADDRESS1, /* controller 1 */
+ [1][0] = SPD_EEPROM_ADDRESS2, /* controller 2 */
+};
+#endif
+#if (CONFIG_NUM_DDR_CONTROLLERS == 2) (CONFIG_DIMM_SLOTS_PER_CTLR == 2)
+u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
+ [0][0] = SPD_EEPROM_ADDRESS1, /* controller 1 */
+ [0][1] = SPD_EEPROM_ADDRESS2, /* controller 1 */
+ [1][0] = SPD_EEPROM_ADDRESS3, /* controller 2 */
+ [1][1] = SPD_EEPROM_ADDRESS4, /* controller 2 */
+};
+#endif
Wouldn't it be easier if we just temporarily defined values for
SPD_EEPROM_ADDRESSx? Like this:
#ifndef SPD_EEPROM_ADDRESS2
#define SPD_EEPROM_ADDRESS2 0
#endif
...
u8 spd_i2c_addr[2][2] = {
This is problematic because because if you notice SPD_EEPROM_ADDRESS2 is used
for both controller 2 / dimm 1 controller 1 / dimm 2.
+static void __get_spd(generic_spd_eeprom_t *spd, u8 i2c_address)
+{
+ int ret = i2c_read(i2c_address, 0, 1, (uchar *)spd,
+ sizeof(generic_spd_eeprom_t));
+
+ if (ret) {
+ debug(DDR: failed to read SPD from address %u\n,
i2c_address);
This should probably be a printf() instead.
will change
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
On Tue, 2011-02-01 at 08:34 +0100, Wolfgang Denk wrote: Can you please be more specific? I don't see where the LDFLAGS_u-boot commit (you mean 8aba9dc ?) would change any related code. The relevant hunk looks like this: @@ -204,9 +204,11 @@ endif AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS) -LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS) +LDFLAGS += $(PLATFORM_LDFLAGS) + +LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS) ifneq ($(CONFIG_SYS_TEXT_BASE),) -LDFLAGS += -Ttext $(CONFIG_SYS_TEXT_BASE) +LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE) endif # Location of a usable BFD library, where we define usable as and this does not make any changes of PLATFORM_LDFLAGS into LDFLAGS or vice versa. But PLATFORM_LDFLAGS has been changed in $(CPUDIR)/config.mk. You can see in commit 8aba9dc: --- a/arch/powerpc/config.mk +++ b/arch/powerpc/config.mk @@ -24,10 +24,10 @@ CROSS_COMPILE ?= ppc_8xx- STANDALONE_LOAD_ADDR = 0x4 - +LDFLAGS_u-boot = --gc-sections PLATFORM_RELFLAGS += -mrelocatable -ffunction-sections -fdata-sections PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__ -PLATFORM_LDFLAGS += -n --gc-sections +PLATFORM_LDFLAGS += -n Here, --gc-sections is set only for LDFLAGS_u-boot, the PLATFORM_LDFLAGS does have --gc-sections, So in toplevel config.mk: +LDFLAGS += $(PLATFORM_LDFLAGS) And later in this config.mk, @@ -259,7 +261,7 @@ $(obj)%.s: %.c # If the list of objects to link is empty, just create an empty built-in.o cmd_link_o_target = $(if $(strip $1),\ - $(LD) -r -o $@ $1 ,\ + $(LD) $(LDFLAGS) -r -o $@ $1,\ rm -f $@; $(AR) rcs $@ ) LDFLAGS is added in cmd_link_o_target which made changes to build nand_spl. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot compilation lowlevel_init.S:619: error: #error Unknown DDR configuration!!!
Getting this error with the u-boot compilation http://pastebin.com/h3x90vHK u-boot is a git clone of the git://gitorious.org/hawkboard/u-boot.git plz help any idea what needs to be done to fix this . Thanks . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot compilation lowlevel_init.S:619: error: #error Unknown DDR configuration!!!
Dear Vaishali, In message AANLkTikrrkC5fk7C1-Pm+Fx88h7Pu_2Nyz6rLJ=x2...@mail.gmail.com you wrote: Getting this error with the u-boot compilation http://pastebin.com/h3x90vHK u-boot is a git clone of the git://gitorious.org/hawkboard/u-boot.git plz help any idea what needs to be done to fix this . Sorry - please contact the people responsible for that repository. We have no idea if or how this corresponds to the mainline code we are discussing here. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Madness takes its toll. Please have exact change. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] spi subystem maintainer?
Do we have one? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Remove config.mk for nand linker script
On Mon, 31 Jan 2011 22:02:03 -0600 Kumar Gala ga...@kernel.crashing.org wrote: On Jan 31, 2011, at 4:52 PM, Scott Wood wrote: On Mon, 31 Jan 2011 16:37:44 -0600 Kumar Gala ga...@kernel.crashing.org wrote: * fix where we define this, it should !CONFIG_NAND_SPL, read the old config.mk incorrectly. I don't think that will make a difference -- CONFIG_NAND_SPL is never set when symbols are extracted into autoconf.mk, and CONFIG_SYS_LDSCRIPT is not used when building the SPL. it seems to work out ok. My point is it will work either way, the ifdef just confuses things, since that's not actually the mechanism by which a different linker script is used for SPL (nor would it work if you relied on the ifdef for that). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] !!! Trouble with u-boot and leon3 !!!!
Hi All,
We have built u-boot (from git as suggested by U-Boot SPARC / LEON Port v
1.0.0 April 2009.
The building is successfull.
I configured for execution in ram (CONFIG_SYS_TEXT_BASE = 0x4000) and
the system runs.
But nothing I see on the serial console connected to minicom.
When I do Crtl+C the system stop at an address inside such function:
arch/sparc/cpu/leon3/cpu_init.c - void cpu_init_f(void)
I found that it fails:
/* Find AMBA APB IRQMP Controller */
if (ambapp_apb_first(VENDOR_GAISLER, GAISLER_IRQMP, apbdev) != 1) {
/* no IRQ controller, something is wrong
* == jump to start (or hang)
*/
while (1) ;
}
so the while (1) occurs.
I discovered that:
ambapp_apb_first(VENDOR_GAISLER, GAISLER_IRQMP, apbdev)
Any suggetions?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
On Mon, 31 Jan 2011 22:14:45 -0500 Haiying Wang haiying.w...@freescale.com wrote: On Mon, 2011-01-31 at 15:28 -0600, Kumar Gala wrote: On Jan 31, 2011, at 2:50 PM, Haiying Wang wrote: On Mon, 2011-01-31 at 21:11 +0100, Wolfgang Denk wrote: +#ifdef CONFIG_P1021 + ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); + + /* QE9 and QE12 need to be set for enabling QE MII managment signals */ + setbits_be32(gur-pmuxcr, MPC85xx_PMUXCR_QE9); + setbits_be32(gur-pmuxcr, MPC85xx_PMUXCR_QE12); +#endif ... Can we please avoid having board specific code in common files? I wish I could, but only P1021 has such pin mux problems. If this is really necessary, it shoud be a feature-specific #define, not a board specific one. I don't know whether this *feature* will show up on other SoC. But if you insist, I can use CONFIG_QE_PIN_MUX. Thanks. Haiying I think pin muxing is a board level decision so it seems like board code is the right place for it. If it is a one time setting, there should be no problem to put it into board code. But these pin settings need to be done before any usage of phy read/write (accessing MDIO/MDC), and need to be released after the usage of phy, thus the devices connected to eLBC like NAND flash/BCSR can be accessed. If we use board code to set/release the pin, we don't know when the phy access and nand flash access will happen. Is this actually a board issue or an SoC issue? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] BLOCK: Fixup iMX51 ATA driver
On Tuesday 01 February 2011 08:11:51 Stefano Babic wrote: On 11/29/2010 03:18 PM, Marek Vasut wrote: Signed-off-by: Marek Vasut marek.va...@gmail.com Hi Marek, in my regression tests to check if all IMX boards are compiled clean I found the following warnings (efikamx): mxc_ata.c:90: warning: 'pio_t0' defined but not used mxc_ata.c:93: warning: 'pio_t2_16' defined but not used mxc_ata.c:94: warning: 'pio_t2i' defined but not used As I have already merged your patch into u-boot-imx (and Albert has already merged it in u-boot-arm), I will post a patch on top of it to remove them. Anyway, have you expected that these three variables are not used at all ? Could I remove them ? Yes, you can remove them. They are unused in the original freescale driver too, stupid sed-mistake. Thanks for the good catch :) Regards, Stefano ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote: If it is a one time setting, there should be no problem to put it into board code. But these pin settings need to be done before any usage of phy read/write (accessing MDIO/MDC), and need to be released after the usage of phy, thus the devices connected to eLBC like NAND flash/BCSR can be accessed. If we use board code to set/release the pin, we don't know when the phy access and nand flash access will happen. Is this actually a board issue or an SoC issue? It is not a board issue. It is a SoC *feature*. Too many pins are muxed on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20] which is used for MDIO signal. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MXC: removed warnings from IMX51 ATA driver
Drop warnings due to unused variables.
Signed-off-by: Stefano Babic sba...@denx.de
CC: Marek Vasut marek.va...@gmail.com
---
drivers/block/mxc_ata.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/block/mxc_ata.c b/drivers/block/mxc_ata.c
index 842a633..f22f4f4 100644
--- a/drivers/block/mxc_ata.c
+++ b/drivers/block/mxc_ata.c
@@ -87,11 +87,8 @@ struct mxc_data_hdd_regs {
/* PIO timing table */
#defineNR_PIO_SPECS5
-static uint16_t pio_t0[NR_PIO_SPECS] = { 600, 383, 240, 180, 120 };
static uint16_t pio_t1[NR_PIO_SPECS] = { 70, 50, 30, 30, 25 };
static uint16_t pio_t2_8[NR_PIO_SPECS] = { 290, 290, 290, 80, 70 };
-static uint16_t pio_t2_16[NR_PIO_SPECS]= { 165, 125, 100, 80, 70 };
-static uint16_t pio_t2i[NR_PIO_SPECS] = { 40, 0, 0, 0, 0 };
static uint16_t pio_t4[NR_PIO_SPECS] = { 30, 20, 15, 10, 10 };
static uint16_t pio_t9[NR_PIO_SPECS] = { 20, 15, 10, 10, 10 };
static uint16_t pio_tA[NR_PIO_SPECS] = { 50, 50, 50, 50, 50 };
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/1] imximage: Add MX53 boot image support
On 01/19/2011 08:40 PM, Jason Liu wrote: This patch add the MX53 boot image support. This patch has been tested on Freescale MX53EVK board and MX51EVK board. Signed-off-by: Jason Liu r64...@freescale.com --- Applied to u-boot-imx, thanks 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 RESEND] MC13892: Add SWx buck switchers definitions
On 01/19/2011 03:40 PM, Marek Vasut wrote: Define voltages configurable on SWx buck switchers. Signed-off-by: Marek Vasut marek.va...@gmail.com Acked-by: Stefano Babic sba...@denx.de --- include/mc13892.h | 39 +++ 1 files changed, 39 insertions(+), 0 deletions(-) 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3 v2] MX51EVK: Use SWx macros in PMIC init
On 01/19/2011 03:40 PM, Marek Vasut wrote: Signed-off-by: Marek Vasut marek.va...@gmail.com --- v2: Remove stray newline and useless parens board/freescale/mx51evk/mx51evk.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 11/11] Add support for Freescale's mx35pdk board.
On 01/20/2011 06:53 PM, Stefano Babic wrote: The patch adds suupport for the Freescale's mx35pdk board (known as well as mx35_3stack). The board boots from the NOR flash. Following devices are supported: - two ethernet devices (FEC and SMC911x on debug board) - I2C - PMIC (MC13892) via I2C interface - UART - NOR flash (64MB) - NAND flash (2GB) - basic access to mc9sdz60 registers via I2C interface Signed-off-by: Stefano Babic sba...@denx.de 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 08/11] SPI: mxc_spi: fix swapping bug and add missing swapping in unaligned rx case
On 01/20/2011 06:53 PM, Stefano Babic wrote: From: Anatolij Gustschin ag...@denx.de We need to shift only one time in each cycle in the swapping loop for unaligned tx case. Currently two byte shift operations are performed in each loop cycle causing zero gaps in the transmited data, so not all data scheduled for transmition is actually transmited. The proper swapping in unaligned rx case is missing, so add it as we need to put the received data into the rx buffer in the correct byte order. Signed-off-by: Anatolij Gustschin ag...@denx.de Tested-by: Stefano Babic sba...@denx.de 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/11] SPI: mxc_spi: add SPI clock calculation and setup to the driver
On 01/20/2011 09:46 AM, Stefano Babic wrote: From: Anatolij Gustschin ag...@denx.de The MXC SPI driver didn't calculate the SPI clock up to now and just used highest possible divider 512 for DATA RATE in the control register. This results in very low transfer rates. The patch adds code to calculate and setup the SPI clock frequency for transfers. Signed-off-by: Anatolij Gustschin ag...@denx.de Signed-off-by: Stefano Babic sba...@denx.de 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Albert, here my pull request for u-boot-imx. Since my last pull-request, I rebased my tree to substitute: imximage: Add MX53 boot image support I fixed the wrong mode,too, and I cherry-picked from u-boot-arm: ARM: fix broken build of ARM that you have already merged, to avoid leaving u-boot-imx broken. I hope this is not a problem for you. The following changes since commit 6f918bd46482f889f4d94623b09daf659a1974bd: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2011-01-31 23:20:32 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Anatolij Gustschin (2): SPI: mxc_spi: fix swapping bug and add missing swapping in unaligned rx case SPI: mxc_spi: add SPI clock calculation and setup to the driver Liu Hui-R64343 (9): MX51EVK: UART does not print out the early information MX5: Add initial support for MX53 processor fec_mxc: add support for MX53 processor serial_mxc: add support for MX53 processor mxc_gpio: add support for MX53 processor mxc_i2c: add support for MX53 processor fsl_pmic: add I2C interface support MX5:MX53: add initial support for MX53EVK board imximage: Add MX53 boot image support Marek Vasut (4): BLOCK: Add freescale IMX51 PATA driver MC13892: Add SWx buck switchers definitions MX51EVK: Use SWx macros in PMIC init iMX5: EfikaMX: Preliminary board support Stefano Babic (13): mxc_nand: add support for i.MX35 processor Add support for MX35 processor serial_mxc: add support for Freescale's i.MX35 processor mxc_i2c: Add support for the i.MX35 processor I2C: mxc_i2c: get rid of __REG access I2C: mxc_i2c: address failure with mx35 processor Add basic support for Freescale's mc9sdz60 SPI: mxc_spi: add support for i.MX35 processor SPI: mxc_spi: replace fixed offsets with structures Add support for Freescale's mx35pdk board. MX5: Reuse the gd-tbl value for timestamp and add gd-lastinc for lastinc bss MXC: removed warnings from IMX51 ATA driver ARM: fix broken build of ARM MAINTAINERS |8 +- arch/arm/config.mk |2 +- arch/arm/cpu/arm1136/mx35/Makefile | 63 +++ arch/arm/cpu/arm1136/mx35/asm-offsets.c | 43 ++ arch/arm/cpu/arm1136/mx35/generic.c | 463 ++ arch/arm/cpu/arm1136/mx35/iomux.c | 116 + arch/arm/cpu/arm1136/mx35/timer.c | 120 + arch/arm/cpu/armv7/mx5/iomux.c | 30 +- arch/arm/cpu/armv7/mx5/lowlevel_init.S | 91 +++-- arch/arm/cpu/armv7/mx5/soc.c| 22 +- arch/arm/cpu/armv7/mx5/timer.c |6 +- arch/arm/include/asm/arch-mx31/mx31-regs.h | 11 + arch/arm/include/asm/arch-mx35/clock.h | 45 ++ arch/arm/include/asm/arch-mx35/crm_regs.h | 270 +++ arch/arm/include/asm/arch-mx35/imx-regs.h | 303 arch/arm/include/asm/arch-mx35/iomux.h | 295 arch/arm/include/asm/arch-mx35/mx35_pins.h | 355 ++ arch/arm/include/asm/arch-mx35/sys_proto.h | 31 ++ arch/arm/include/asm/arch-mx5/asm-offsets.h |5 + arch/arm/include/asm/arch-mx5/imx-regs.h| 94 ++-- arch/arm/include/asm/arch-mx5/iomux.h | 102 arch/arm/include/asm/arch-mx5/mx5x_pins.h | 469 ++- board/efikamx/Makefile | 52 ++ board/efikamx/config.mk | 25 + board/efikamx/efikamx.c | 689 +++ board/efikamx/imximage.cfg | 122 + board/freescale/mx35pdk/Makefile| 49 ++ board/freescale/mx35pdk/lowlevel_init.S | 363 ++ board/freescale/mx35pdk/mx35pdk.c | 297 board/freescale/mx35pdk/mx35pdk.h | 101 board/freescale/mx51evk/mx51evk.c | 17 +- board/freescale/mx53evk/Makefile| 48 ++ board/freescale/mx53evk/config.mk | 24 + board/freescale/mx53evk/imximage.cfg| 112 + board/freescale/mx53evk/mx53evk.c | 397 +++ boards.cfg |3 + doc/README.imximage | 12 +- doc/README.mx35pdk | 188 drivers/block/Makefile |1 + drivers/block/mxc_ata.c | 146 ++ drivers/gpio/mxc_gpio.c |9 +- drivers/i2c/mxc_i2c.c | 172 +-- drivers/misc/Makefile |5 +- drivers/misc/fsl_pmic.c | 45 ++- drivers/misc/mc9sdz60.c | 51 ++ drivers/mtd/nand/mxc_nand.c |6 +- drivers/net/fec_mxc.c |2 +- drivers/net/fec_mxc.h |4 +- drivers/serial/serial_mxc.c
[U-Boot] PCIE supported networking cards?
Are there any PCIE networking cards that are supported? So far I've tried an Intel card and a Realtek RTL8168 card, but neither is supported. It looks like the E1000 driver only supports PCI and PCIX based cards (Linux uses the e1000e card for PCIe cards). -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again
Hi
On 02/01/2011 01:16 PM, Albert ARIBAUD wrote:
Le 01/02/2011 11:45, Michael Trimarchi a écrit :
Hi
/home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld
-pie -r -o libat91.o lowlevel_init.o clock.o cpu.o reset.o timer.o
/home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld:
-r and -shared may not be used together
I have tried this patch but this a problem releated to linking option. Do
you have this problem?
Michael
Read up recent posts on the list: this was detected and is fixed in the
master branch of the u-boot-arm repository.
Amicalement,
I see, but I see but I have other little problem. I have fixed the compilation,
but I have a segmentation fault.
Starting program:
/opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld
-pie -Bstatic -T u-boot.lds -Ttext 0x23e0 arch/arm/cpu/arm926ejs/start.o
--start-group api/libapi.o arch/arm/cpu/arm926ejs/at91/libat91.o
arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o common/libcommon.o
disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o
drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o
drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o
drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o
drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o
drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o
drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o
drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o
drivers/spi/libspi.o drivers/twserial/libtws.o
drivers/usb/gadget/libusb_gadget.o
drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o
drivers/usb/phy/libusb_phy.o drivers/video/libvideo.o
drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o
fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o
fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o
lib/lzma/liblzma.o lib/lzo/liblzo.o net/libnet.o post/libpost.o
board/atmel/at91sam9261ek/libat91sam9261ek.o --end-group
/home/michael/u-boot/arch/arm/lib/eabi_compat.o -L
/opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/../lib/gcc/arm-none-linux-gnueabi/4.1.2
-lgcc -Map u-boot.map -o u-boot
/opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld:
u-boot: warning: allocated section `.bss' not in segment
Program received signal SIGSEGV, Segmentation fault.
0x08081ebd in elf32_arm_finish_dynamic_sections ()
(gdb) bt
#0 0x08081ebd in elf32_arm_finish_dynamic_sections ()
#1 0x0809cc2b in bfd_elf_final_link ()
#2 0x0807b525 in elf32_arm_bfd_final_link ()
#3 0x0805bfce in ldwrite ()
#4 0x0805a0be in main ()
Michael
diff --git a/arch/arm/cpu/arm926ejs/at91/timer.c b/arch/arm/cpu/arm926ejs/at91/timer.c
index 82b8d7e..b140893 100644
--- a/arch/arm/cpu/arm926ejs/at91/timer.c
+++ b/arch/arm/cpu/arm926ejs/at91/timer.c
@@ -122,11 +122,21 @@ void __udelay(unsigned long usec)
*
* The time is used in CONFIG_SYS_HZ units!
*/
-void reset_timer(void)
+void reset_timer_masked(void)
{
gd-timer_reset_value = get_ticks();
}
+void reset_timer(void)
+{
+ reset_timer_masked();
+}
+
+ulong get_timer_masked(void)
+{
+return tick_to_time(get_ticks() - gd-timer_reset_value);
+}
+
ulong get_timer(ulong base)
{
return tick_to_time(get_ticks() - gd-timer_reset_value) - base;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PCIE supported networking cards?
We utilize e1000 PCIe cards all the time - k On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote: Are there any PCIE networking cards that are supported? So far I've tried an Intel card and a Realtek RTL8168 card, but neither is supported. It looks like the E1000 driver only supports PCI and PCIX based cards (Linux uses the e1000e card for PCIe cards). -Aaron ___ 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 6/6] p1021mds: add QE and UEC support
On Feb 1, 2011, at 11:01 AM, Haiying Wang wrote: On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote: If it is a one time setting, there should be no problem to put it into board code. But these pin settings need to be done before any usage of phy read/write (accessing MDIO/MDC), and need to be released after the usage of phy, thus the devices connected to eLBC like NAND flash/BCSR can be accessed. If we use board code to set/release the pin, we don't know when the phy access and nand flash access will happen. Is this actually a board issue or an SoC issue? It is not a board issue. It is a SoC *feature*. Too many pins are muxed on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20] which is used for MDIO signal. Haiying But its a board decision on how they want to utilize those pins and for what feature. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PCIE supported networking cards?
On Tue, 1 Feb 2011 13:15:01 -0600 Kumar Gala ga...@kernel.crashing.org wrote: We utilize e1000 PCIe cards all the time Aren't there some versions that work, and some that don't? -Scott - k On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote: Are there any PCIE networking cards that are supported? So far I've tried an Intel card and a Realtek RTL8168 card, but neither is supported. It looks like the E1000 driver only supports PCI and PCIX based cards (Linux uses the e1000e card for PCIe cards). -Aaron ___ 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spi subystem maintainer?
Dear Kumar Gala, In message 9a3702c1-3ed1-4f24-a0bc-ca7daea46...@kernel.crashing.org you wrote: Do we have one? Not yet. Are you volunteering? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again
Hi, 2011/2/1 Michael Trimarchi trimar...@gandalf.sssup.it: Hi On 02/01/2011 01:16 PM, Albert ARIBAUD wrote: Le 01/02/2011 11:45, Michael Trimarchi a écrit : Hi /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld -pie -r -o libat91.o lowlevel_init.o clock.o cpu.o reset.o timer.o /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld: -r and -shared may not be used together I have tried this patch but this a problem releated to linking option. Do you have this problem? Michael Read up recent posts on the list: this was detected and is fixed in the master branch of the u-boot-arm repository. I mentioned this as well directly after posting this patch for the first time. But anyway, if you look at 'cdc-at91' branch of u-boot-usb you can see all the other patches that are required to make it compile properly. Including the timer fix for the at91 family. Amicalement, I see, but I see but I have other little problem. I have fixed the compilation, but I have a segmentation fault. Starting program: /opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld -pie -Bstatic -T u-boot.lds -Ttext 0x23e0 arch/arm/cpu/arm926ejs/start.o --start-group api/libapi.o arch/arm/cpu/arm926ejs/at91/libat91.o arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o net/libnet.o post/libpost.o board/atmel/at91sam9261ek/libat91sam9261ek.o --end-group /home/michael/u-boot/arch/arm/lib/eabi_compat.o -L /opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/../lib/gcc/arm-none-linux-gnueabi/4.1.2 -lgcc -Map u-boot.map -o u-boot /opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld: u-boot: warning: allocated section `.bss' not in segment Program received signal SIGSEGV, Segmentation fault. 0x08081ebd in elf32_arm_finish_dynamic_sections () (gdb) bt #0 0x08081ebd in elf32_arm_finish_dynamic_sections () #1 0x0809cc2b in bfd_elf_final_link () #2 0x0807b525 in elf32_arm_bfd_final_link () #3 0x0805bfce in ldwrite () #4 0x0805a0be in main () Michael I see you use a rather old compiler. I tested with a GCC 4.3.4 (CodeSourcery 2009q1) compiler which works okay. I also noticed that the current make structure of U-boot is more picky on linker usage, and even unresolved externals result in crashing linkers. This has nothing to do with this patch though. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks
Hi, 2011/2/1 Simon Glass s...@chromium.org: Hi Remy, Still waiting on some boards to try, unfortunately. I expect it will happen in the next 2 weeks though (ARM9 and OMAP4 platforms). Once I get to the bottom of it I will split the patches as requested. I have not seen reports from other users of U-Boot. Also working on USB host Ethernet. Regards, Simon FWIW: I tested it on Atmel at91 and it does not seem to break OHCI, it does not seem to fix some troubles USB sticks I have here either... Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
On Tue, 2011-02-01 at 13:15 -0600, Kumar Gala wrote: On Feb 1, 2011, at 11:01 AM, Haiying Wang wrote: On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote: If it is a one time setting, there should be no problem to put it into board code. But these pin settings need to be done before any usage of phy read/write (accessing MDIO/MDC), and need to be released after the usage of phy, thus the devices connected to eLBC like NAND flash/BCSR can be accessed. If we use board code to set/release the pin, we don't know when the phy access and nand flash access will happen. Is this actually a board issue or an SoC issue? It is not a board issue. It is a SoC *feature*. Too many pins are muxed on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20] which is used for MDIO signal. Haiying But its a board decision on how they want to utilize those pins and for what feature. Yes, you can say that. If the board doesn't have QE UCC ETH support at all, we won't have to add such code in QE driver. But if there is QE UCC ETH on board, we have no choice to decide which pins to use. We definitely need to use CE_PB[20] for MDIO signal, there is no other GPIO pins to use for QE's MDIO. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
On Tue, 1 Feb 2011 20:32:29 +0100 Wolfgang Denk w...@denx.de wrote: Dear Scott Wood, In message 20110201102446.23b4a...@udp111988uds.am.freescale.net you wrote: Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was used? So before, anything that board/cpu code adds directly to LDFLAGS (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was used in the final link. After 8aba9dc, only things in PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link. And this is correct for all boards? By this do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the switch back to LDFLAGS? It's not obvious to me that the dropping of board/cpu modifications to LDFLAGS except during partial link was an intentional change, or a correct one for all boards. The only case I see where it makes any difference at all is arch/i386, which does LDFLAGS += --cref. From the description of --cref in the linker manual, it probably actually belongs in LDFLAGS_FINAL, though I'm not sure if it's harmless to include it in partial link or not. Currently, with 8aba9dc, it's included *only* in partial link. It's also not clear to me what this option has to do with i386... it looks like an arch-neutral debugging feature that doesn't affect the actual u-boot image at all (the output goes into the map file). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again
Dear all, /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld -pie -r -o libat91.o lowlevel_init.o clock.o cpu.o reset.o timer.o /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld: -r and -shared may not be used together I have tried this patch but this a problem releated to linking option. Do you have this problem? Michael Read up recent posts on the list: this was detected and is fixed in the master branch of the u-boot-arm repository. I'll rebase u-boot-atmel on u-boot-arm/master then. Please rebase at91 related patches on u-boot-atmel/rework then (my time permitting, that branch will exist somewhere tomorrow) Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
Dear Scott Wood, In message 20110201135136.0817f...@udp111988uds.am.freescale.net you wrote: Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was used? So before, anything that board/cpu code adds directly to LDFLAGS (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was used in the final link. After 8aba9dc, only things in PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link. And this is correct for all boards? By this do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the switch back to LDFLAGS? It's not obvious to me that the dropping of I don;t understand why you contine to talk about switch to PLATFORM_LDFLAGS in 8aba9dc. There was no such switch - at least I cannot see it. I see only a switch in your patch. This is why I'm asking. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de HANDLE WITH EXTREME CARE: This Product Contains Minute Electrically Charged Particles Moving at Velocities in Excess of Five Hundred Million Miles Per Hour. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
On Tue, 1 Feb 2011 21:20:50 +0100 Wolfgang Denk w...@denx.de wrote: Dear Scott Wood, In message 20110201135136.0817f...@udp111988uds.am.freescale.net you wrote: Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was used? So before, anything that board/cpu code adds directly to LDFLAGS (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was used in the final link. After 8aba9dc, only things in PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link. And this is correct for all boards? By this do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the switch back to LDFLAGS? It's not obvious to me that the dropping of I don;t understand why you contine to talk about switch to PLATFORM_LDFLAGS in 8aba9dc. There was no such switch - at least I cannot see it. I see only a switch in your patch. This is why I'm asking. Before 8aba9dc, the flags for the final link were produced by taking the existing LDFLAGS, and adding: -Bstatic -T linkerscript $(PLATFORM_LDFLAGS) -Ttext addr. This included anything that cpu/board code added to LDFLAGS -- some architectures added --gc-sections, x86 added --cref, etc. Since the above flags are added to LDFLAGS, rather than replacing them, these flags got used in the final link. Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the source for the flags for the final link. It generates LDFLAGS_u-boot using PLATFORM_LDFLAGS, not LDFLAGS. It converts most of the board/cpu updates to LDFLAGS into LDFLAGS_u-boot, but it missed --cref. I don't see any other LDFLAGS changes in board/cpu code, so the distinction between using LDFLAGS and PLATFORM_LDFLAGS should have no other impact on current boards. However, the patch appears to be intended to support platform linker flags that need to be used during partial link, which would involve board/cpu additions to LDFLAGS. This change would break that only if those options need to be used for partial link *only*, and cannot be used in the final link. In such a case I'd suggest using something like LDFLAGS_PARTIAL to make this explicit. But I'd be surprised if that were actually the case. If you're looking to cut down on the number of variables, it's not clear to me what PLATFORM_LDFLAGS is supposed to mean distinct from adding to LDFLAGS. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PCIE supported networking cards?
This is an Intel EXPI9301 PRO/1000 OEM card, vendor ID 0x8086, device ID 0x10d3. I added it to the list but I don't know what the MAC type is. I'll look into the Linux driver and see if I can see what it is. -Aaron On Tuesday, February 01, 2011 11:19:24 am Scott Wood wrote: On Tue, 1 Feb 2011 13:15:01 -0600 Kumar Gala ga...@kernel.crashing.org wrote: We utilize e1000 PCIe cards all the time Aren't there some versions that work, and some that don't? -Scott - k On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote: Are there any PCIE networking cards that are supported? So far I've tried an Intel card and a Realtek RTL8168 card, but neither is supported. It looks like the E1000 driver only supports PCI and PCIX based cards (Linux uses the e1000e card for PCIe cards). -Aaron ___ 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Stefano, Le 01/02/2011 19:13, Stefano Babic a écrit : Hi Albert, here my pull request for u-boot-imx. Since my last pull-request, I rebased my tree to substitute: imximage: Add MX53 boot image support I fixed the wrong mode,too, and I cherry-picked from u-boot-arm: ARM: fix broken build of ARM that you have already merged, to avoid leaving u-boot-imx broken. I hope this is not a problem for you. Pulled into u-boot-arm/master, thanks -- had to force update, though. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks
I too am interested in this. I am running EHCI and have had problems with a number of USB storage devices, one of which (the SanDisk Cruzer) causes a crash due to it reporting the maximum LUN as 1. I'm also seeing some interesting performance issues with ext2 being extremely slow compared to FAT. Additionally, I have been trying various USB hubs with EHCI and have found that a large percentage fail to work. Hopefully I'll look into it more soon when I get ahold of our USB analyzer again. -Aaron On Tuesday, February 01, 2011 11:34:00 am Remy Bohmer wrote: Hi, 2011/2/1 Simon Glass s...@chromium.org: Hi Remy, Still waiting on some boards to try, unfortunately. I expect it will happen in the next 2 weeks though (ARM9 and OMAP4 platforms). Once I get to the bottom of it I will split the patches as requested. I have not seen reports from other users of U-Boot. Also working on USB host Ethernet. Regards, Simon FWIW: I tested it on Atmel at91 and it does not seem to break OHCI, it does not seem to fix some troubles USB sticks I have here either... Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm
Hi Wolfgang, Please pull from u-boot-arm/master to go into rc1 of upcoming release. The following changes since commit 6f918bd46482f889f4d94623b09daf659a1974bd: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2011-01-31 23:20:32 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-arm.git master Alexander Holler (1): ARM: Avoid compiler optimization for readb, writeb and friends. Anatolij Gustschin (2): SPI: mxc_spi: fix swapping bug and add missing swapping in unaligned rx case SPI: mxc_spi: add SPI clock calculation and setup to the driver Heiko Schocher (2): arm1136: timer: Replace bss variable by gd arm926ejs: timer: Replace bss variable by gdr Jens Scharsig (1): remove (double) LED initialization in arm920t start.s Liu Hui-R64343 (10): MX51EVK: UART does not print out the early information MX5: Add initial support for MX53 processor fec_mxc: add support for MX53 processor serial_mxc: add support for MX53 processor mxc_gpio: add support for MX53 processor mxc_i2c: add support for MX53 processor fsl_pmic: add I2C interface support MX5:MX53: add initial support for MX53EVK board imximage: Add MX53 boot image support ARM: */start.S: code cleanup Marek Vasut (4): BLOCK: Add freescale IMX51 PATA driver MC13892: Add SWx buck switchers definitions MX51EVK: Use SWx macros in PMIC init iMX5: EfikaMX: Preliminary board support Mike Rapoport (1): OMAP3: add CM-T35 board Minkyu Kang (4): armv7: s5pc1xx: don't use function pointer for clock functions S5P: serial: Use the inline function instead of static value armv7: add support for S5PC210 SoC armv7: add support for s5pc210 universal board Po-Yu Chuang (1): arm: a320evb: fixes for relocation support Sandeep Paulraj (12): Davinci MMCSD Support DaVinci DM355: Adding MMC/SD support for DM355 EVM DaVinci DM365: Adding MMC/SD support for DM365 EVM DM365: Fix Build Error DaVinci EMAC: Fix davinci_eth_gigabit_enable DaVinci EMAC: Add name to Ethernet device DaVinci DM6467: Added ET1011C (LSI) PHY support ARM: Update mach types DaVinci DM6467: Enhance board Support DaVinci DM6467: Fix Build Error DaVinci Sonata: Fix Build Error DaVinci: Remove incorrect CONFIG option Stefano Babic (13): mxc_nand: add support for i.MX35 processor Add support for MX35 processor serial_mxc: add support for Freescale's i.MX35 processor mxc_i2c: Add support for the i.MX35 processor I2C: mxc_i2c: get rid of __REG access I2C: mxc_i2c: address failure with mx35 processor Add basic support for Freescale's mc9sdz60 SPI: mxc_spi: add support for i.MX35 processor SPI: mxc_spi: replace fixed offsets with structures Add support for Freescale's mx35pdk board. MX5: Reuse the gd-tbl value for timestamp and add gd-lastinc for lastinc bss MXC: removed warnings from IMX51 ATA driver ARM: fix broken build of ARM MAINTAINERS| 17 +- arch/arm/config.mk |2 +- arch/arm/cpu/arm1136/mx31/timer.c | 19 +- arch/arm/cpu/arm1136/mx35/Makefile | 63 + arch/arm/cpu/arm1136/mx35/asm-offsets.c| 43 + arch/arm/cpu/arm1136/mx35/generic.c| 463 arch/arm/cpu/arm1136/mx35/iomux.c | 116 + arch/arm/cpu/arm1136/mx35/timer.c | 120 + arch/arm/cpu/arm1136/omap24xx/timer.c | 19 +- arch/arm/cpu/arm1136/start.S |2 - arch/arm/cpu/arm1176/start.S |2 - arch/arm/cpu/arm720t/start.S |2 - arch/arm/cpu/arm920t/start.S |5 - arch/arm/cpu/arm925t/start.S |2 - arch/arm/cpu/arm926ejs/davinci/Makefile|2 +- arch/arm/cpu/arm926ejs/davinci/cpu.c | 14 +- arch/arm/cpu/arm926ejs/davinci/et1011c.c | 55 + arch/arm/cpu/arm926ejs/kirkwood/timer.c|6 +- arch/arm/cpu/arm926ejs/mb86r0x/timer.c |6 +- arch/arm/cpu/arm926ejs/mx25/timer.c|6 +- arch/arm/cpu/arm926ejs/mx27/timer.c|6 +- arch/arm/cpu/arm926ejs/omap/timer.c|6 +- arch/arm/cpu/arm926ejs/orion5x/timer.c |6 +- arch/arm/cpu/arm926ejs/spear/timer.c |6 +- arch/arm/cpu/arm926ejs/start.S |2 - arch/arm/cpu/arm926ejs/versatile/timer.c |6 +- arch/arm/cpu/arm946es/start.S |2 - arch/arm/cpu/arm_intcm/start.S |2 - arch/arm/cpu/armv7/mx5/iomux.c | 30 +-
Re: [U-Boot] [Patch V6 0/4] Add basic NVIDIA Tegra2 SoC support
I haven't seen any new feedback on this version (V6) of the patchset since it was posted. Wolfgang, Mike, Peter, et al - are you happy with the current patch? If so, when can I expect it to be pushed? Thanks, Tom On Thu, Jan 27, 2011 at 1:58 PM, Tom Warren twarren.nvi...@gmail.com wrote: This series of patches adds preliminary/baseline support for NVIDIA's Tegra2 SoC. Basic CPU (AVP), RAM and UART init are covered so that the system (Harmony or Seaboard) can boot to the U-Boot serial cmd prompt. Further support (for Cortex-A9 CPU(s), USB, SD/MMC, etc.) to follow. Changes for V2: - Coding style cleanup - Remove mach-types.h change; wait for ARM kernel sync-up - Move serial driver changes to separate patch - Use board/nvidia/ instead of /board/tegra - Remove TRUE/FALSE defines - Use standard NS16550 register/bit defines in UART init - Change nv-common.h config file to tegra2-common.h Changes for V3: - Use I/O accessors for Tegra2 HW MMIO register access - Allow conditional compile of UARTA/UARTD code to save space Changes for V4: - Use address of HW structs (pmc, etc.) in readl/writel - Remove empty lines, fix mixed case hex #s comments in header(s) - Move board/nvidia/common/board.c UART code header to arch/arm/cpu/armv7/tegra2/ - Declare internal functions as static in UART code Changes for V5: - Move arch/arm/cpu/armv7/uart.c board.h to drivers/serial and rename to serial_tegra2.c - Remove use of uart_num UART_A/D in serial_tegra2, simplify code Changes for V6: - Fix uart.c add delete in previous patchset - Move pinmux clock init code to common board file as per review - Use #if defined() where possible in config files/UART code - Drop all typedef and volatile struct declarations in header files Tom Warren (4): arm: Tegra2: Add basic NVIDIA Tegra2 SoC support serial: Add Tegra2 serial port support arm: Tegra2: Add support for NVIDIA Harmony board arm: Tegra2: Add support for NVIDIA Seaboard board MAINTAINERS | 5 + arch/arm/cpu/armv7/tegra2/Makefile | 48 +++ arch/arm/cpu/armv7/tegra2/board.c | 88 arch/arm/cpu/armv7/tegra2/config.mk | 28 arch/arm/cpu/armv7/tegra2/lowlevel_init.S | 65 + arch/arm/cpu/armv7/tegra2/sys_info.c | 35 + arch/arm/cpu/armv7/tegra2/timer.c | 122 arch/arm/include/asm/arch-tegra2/clk_rst.h | 165 ++ arch/arm/include/asm/arch-tegra2/pinmux.h | 55 arch/arm/include/asm/arch-tegra2/pmc.h | 124 + arch/arm/include/asm/arch-tegra2/sys_proto.h | 35 + arch/arm/include/asm/arch-tegra2/tegra2.h | 49 +++ arch/arm/include/asm/arch-tegra2/uart.h | 47 ++ board/nvidia/common/board.c | 193 ++ board/nvidia/harmony/Makefile | 50 +++ board/nvidia/seaboard/Makefile | 50 +++ boards.cfg | 2 + common/serial.c | 3 +- drivers/serial/Makefile | 1 + drivers/serial/serial_tegra2.c | 77 ++ drivers/serial/serial_tegra2.h | 29 include/configs/harmony.h | 49 +++ include/configs/seaboard.h | 43 ++ include/configs/tegra2-common.h | 160 + include/serial.h | 3 +- 25 files changed, 1524 insertions(+), 2 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/Makefile create mode 100644 arch/arm/cpu/armv7/tegra2/board.c create mode 100644 arch/arm/cpu/armv7/tegra2/config.mk create mode 100644 arch/arm/cpu/armv7/tegra2/lowlevel_init.S create mode 100644 arch/arm/cpu/armv7/tegra2/sys_info.c create mode 100644 arch/arm/cpu/armv7/tegra2/timer.c create mode 100644 arch/arm/include/asm/arch-tegra2/clk_rst.h create mode 100644 arch/arm/include/asm/arch-tegra2/pinmux.h create mode 100644 arch/arm/include/asm/arch-tegra2/pmc.h create mode 100644 arch/arm/include/asm/arch-tegra2/sys_proto.h create mode 100644 arch/arm/include/asm/arch-tegra2/tegra2.h create mode 100644 arch/arm/include/asm/arch-tegra2/uart.h create mode 100644 board/nvidia/common/board.c create mode 100644 board/nvidia/harmony/Makefile create mode 100644 board/nvidia/seaboard/Makefile create mode 100644 drivers/serial/serial_tegra2.c create mode 100644 drivers/serial/serial_tegra2.h create mode 100644 include/configs/harmony.h create mode 100644 include/configs/seaboard.h create mode 100644 include/configs/tegra2-common.h -- 1.7.3.5 ___ U-Boot
[U-Boot] Trouble running hello_world
Hello clueful people, I am new to U-Boot. I am having trouble executing anything using U-Boot. I have read the U-Boot README and Manual. I have also tried to following the steps on plugcomputer.org's wiki. I was feeling like I was beginning to get a clue but then I couldn't get anything to work. I figured a good place to start is trying to execute the u-boot hello_world standalone program but I couldn't even get that to work. I am connected to the serial port via the GuruPlug JTAG board to my GuruPlug Server Plus and here is my output from the serial console: U-Boot 2009.11-rc1-00602-g28a9c08-dirty (Feb 09 2010 - 18:15:21) Marvell-Plug2L SoC: Kirkwood 88F6281_A0 DRAM: 512 MB NAND: 512 MiB In:serial Out: serial Err: serial Net: egiga0, egiga1 88E1121 Initialized on egiga0 88E1121 Initialized on egiga1 Hit any key to stop autoboot: 0 Marvell loads ## Ready for S-Record download ... ## First Load Addr = 0x0C10 ## Last Load Addr = 0x0C100249 ## Total Size = 0x024A = 586 Bytes ## Start Addr = 0x0C10 Marvell go 0xC10 ## Starting application at 0x0C10 ... And that is it. The plug sits there with no further output to the serial console. I've also tried tftp 0x640 hello_world.bin and go 0x644 (like the manual says to start 4 bytes from start in section 5.12.1) but still, same boring results. I've also tried 0xC14 with the loads method just in case, but still nothing. Am I loosing serial console output when I issue the go command? Am I doing something wrong here? -alfred hello_world.srec: S01368656C6C6F5F776F726C642E7372656376 S3150C1070402DE90050A0E10100A0E10160A0E1D3 S3150C10001060EB0610A0E37C009FE530EBBF S3150C10002025EB0040A0E30010A0E16C009FE55A S3150C1000302BEB68009FE529EB64009FE5A0 S3150C1000400510A0E126EB07EA042196E754 S3150C10005054309FE552E30410A0E14C009FE5DC S3150C1000600320A0011EEB014084E2050054E1C0 S3150C100070F5DA38009FE519EB12EBD4 S3150C10008050E3FC0A0DEB24009FE577 S3150C10009013EBA0E37080BDE8C001100C4B S3150C1000A0E001100CFE01100C0B02100C1602100CB9 S3150C1000B01D02100C2E02100C4702100C50C098E5A5 S3150C1000C000F09CE550C098E504F09CE550C098E50E S3150C1000D008F09CE550C098E50CF09CE550C098E5EE S3150C1000E010F09CE550C098E514F09CE550C098E5CE S3150C1000F018F09CE550C098E51CF09CE550C098E5AE S3150C10010020F09CE550C098E524F09CE550C098E58D S3150C10011028F09CE550C098E52CF09CE550C098E56D S3150C10012030F09CE550C098E534F09CE550C098E54D S3150C10013038F09CE550C098E53CF09CE550C098E52D S3150C10014040F09CE550C098E544F09CE550C098E50D S3150C10015048F09CE550C098E54CF09CE550C098E5ED S3150C10016050F09CE550C098E554F09CE550C098E5CD S3150C10017058F09CE550C098E55CF09CE550C098E5AD S3150C10018060F09CE550C098E564F09CE550C098E58D S3150C10019068F09CE51EFF2FE118309FE501EA80 S3150C1001A00020A0E30120C3E40C209FE5020053E1DC S3150C1001B0FA3A1EFF2FE14A82100C4C82100CEC S3150C1001C04578616D706C6520657870656374732005 S3150C1001D04142492076657273696F6E2025640A0058 S3150C1001E041637475616C20552D426F6F74204142BA S3150C1001F0492076657273696F6E2025640A0048650E S3150C1002006C6C6F20576F726C640A00617267632096 S3150C1002103D2025640A003C4E554C4C3E00617267DD S3150C100220765B25645D203D20222573220A004869E1 S3150C1002307420616E79206B657920746F20657869EE S30F0C10024074202E2E2E2A0A0040 S7050C10DE ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] change email address in MAINTAINERS
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- This patch depends on sh: add support for sh7757lcr board. MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7313542..c26c9a7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1017,7 +1017,7 @@ Mark Jonas mark.jo...@de.bosch.com mpr2SH7720 -Yoshihiro Shimoda shimoda.yoshih...@renesas.com +Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com MS7720SESH7720 R0P77570030RL SH7757 -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] sh: add support for sh7757lcr board
The R0P7757LC0030RL board has SH7757, 256MB DDR3-SDRAM, SPI ROM,
Ethernet, and more.
This patch supports the following functions:
- 256MB DDR3-SDRAM
- SPI ROM
- Ethernet
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
about v3:
- change my email address in Makefile and u-boot.lds
MAINTAINERS |1 +
arch/sh/include/asm/cpu_sh4.h |2 +
arch/sh/include/asm/cpu_sh7757.h| 218
board/renesas/sh7757lcr/Makefile| 43 +++
board/renesas/sh7757lcr/lowlevel_init.S | 558 +++
board/renesas/sh7757lcr/sh7757lcr.c | 454 +
board/renesas/sh7757lcr/spi-boot.c | 109 ++
board/renesas/sh7757lcr/u-boot.lds | 101 ++
boards.cfg |1 +
doc/README.sh7757lcr| 64
include/configs/sh7757lcr.h | 146
11 files changed, 1697 insertions(+), 0 deletions(-)
create mode 100644 arch/sh/include/asm/cpu_sh7757.h
create mode 100644 board/renesas/sh7757lcr/Makefile
create mode 100644 board/renesas/sh7757lcr/lowlevel_init.S
create mode 100644 board/renesas/sh7757lcr/sh7757lcr.c
create mode 100644 board/renesas/sh7757lcr/spi-boot.c
create mode 100644 board/renesas/sh7757lcr/u-boot.lds
create mode 100644 doc/README.sh7757lcr
create mode 100644 include/configs/sh7757lcr.h
diff --git a/MAINTAINERS b/MAINTAINERS
index d7cd09c..7313542 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1020,6 +1020,7 @@ Mark Jonas mark.jo...@de.bosch.com
Yoshihiro Shimoda shimoda.yoshih...@renesas.com
MS7720SESH7720
+ R0P77570030RL SH7757
R0P77850011RL SH7785
#
diff --git a/arch/sh/include/asm/cpu_sh4.h b/arch/sh/include/asm/cpu_sh4.h
index fdcebd6..9b29d3a 100644
--- a/arch/sh/include/asm/cpu_sh4.h
+++ b/arch/sh/include/asm/cpu_sh4.h
@@ -44,6 +44,8 @@
# include asm/cpu_sh7722.h
#elif defined (CONFIG_CPU_SH7723)
# include asm/cpu_sh7723.h
+#elif defined (CONFIG_CPU_SH7757)
+# include asm/cpu_sh7757.h
#elif defined (CONFIG_CPU_SH7763)
# include asm/cpu_sh7763.h
#elif defined (CONFIG_CPU_SH7780)
diff --git a/arch/sh/include/asm/cpu_sh7757.h b/arch/sh/include/asm/cpu_sh7757.h
new file mode 100644
index 000..17a6537
--- /dev/null
+++ b/arch/sh/include/asm/cpu_sh7757.h
@@ -0,0 +1,218 @@
+/*
+ * Copyright (C) 2011 Renesas Solutions Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#ifndef _ASM_CPU_SH7757_H_
+#define _ASM_CPU_SH7757_H_
+
+#define CCR0xFF1C
+#define WTCNT 0xFFCC
+#define CCR_CACHE_INIT 0x090b
+#define CACHE_OC_NUM_WAYS 1
+
+#ifndef __ASSEMBLY__ /* put C only stuff in this section */
+/* MMU */
+struct mmu_regs {
+ unsigned intreserved[4];
+ unsigned intmmucr;
+};
+#define MMU_BASE ((struct mmu_regs *)0xff00)
+
+/* Watchdog */
+#define WTCSR0 0xffcc0002
+#define WRSTCSR_R 0xffcc0003
+#define WRSTCSR_W 0xffcc0002
+#define WTCSR_PREFIX 0xa500
+#define WRSTCSR_PREFIX 0x6900
+#define WRSTCSR_WOVF_PREFIX0x9600
+
+/* SCIF */
+#define SCIF0_BASE 0xfe4b /* The real name is SCIF2 */
+#define SCIF1_BASE 0xfe4c /* The real name is SCIF3 */
+#define SCIF2_BASE 0xfe4d /* The real name is SCIF4 */
+
+/* SerMux */
+#define SMR0 0xfe47
+
+/* TMU0 */
+#define TSTR 0xFE430004
+#define TOCR 0xFE43
+#define TSTR0 0xFE430004
+#define TCOR0 0xFE430008
+#define TCNT0 0xFE43000C
+#define TCR0 0xFE430010
+#define TCOR1 0xFE430014
+#define TCNT1 0xFE430018
+#define TCR1 0xFE43001C
+#define TCOR2 0xFE430020
+#define TCNT2 0xFE430024
+#define TCR2 0xFE430028
+#define TCPR2 0xFE43002C
+
+/* ETHER, GETHER MAC address */
+struct ether_mac_regs {
+ unsigned intreserved[114];
+ unsigned intmahr;
+ unsigned intreserved2;
+ unsigned intmalr;
+};
+#define GETHER0_MAC_BASE ((struct ether_mac_regs *)0xfee0400)
+#define GETHER1_MAC_BASE ((struct ether_mac_regs *)0xfee0c00)
+#define
Re: [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks
Hi Aaron, OK good. Yes I notice ext2 is slow also, but the dcache is still off so I assumed that was it. I have had no hub problems, but have only tried two types. I do recall a LUN patch floating around. I was going to try with an uSD card to see if it is needed there. Regards, Simon On Tue, Feb 1, 2011 at 4:03 PM, Aaron Williams aaron.willi...@caviumnetworks.com wrote: I too am interested in this. I am running EHCI and have had problems with a number of USB storage devices, one of which (the SanDisk Cruzer) causes a crash due to it reporting the maximum LUN as 1. I'm also seeing some interesting performance issues with ext2 being extremely slow compared to FAT. Additionally, I have been trying various USB hubs with EHCI and have found that a large percentage fail to work. Hopefully I'll look into it more soon when I get ahold of our USB analyzer again. -Aaron On Tuesday, February 01, 2011 11:34:00 am Remy Bohmer wrote: Hi, 2011/2/1 Simon Glass s...@chromium.org: Hi Remy, Still waiting on some boards to try, unfortunately. I expect it will happen in the next 2 weeks though (ARM9 and OMAP4 platforms). Once I get to the bottom of it I will split the patches as requested. I have not seen reports from other users of U-Boot. Also working on USB host Ethernet. Regards, Simon FWIW: I tested it on Atmel at91 and it does not seem to break OHCI, it does not seem to fix some troubles USB sticks I have here either... Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Add support for Bluewater Systems Snapper 9260 and 9G20 modules
Add support for Bluewater Systems AT91 based Snapper 9260 and 9G20 single board computer modules. Includes NAND flash and Ethernet support. Signed-off-by: Ryan Mallon r...@bluewatersys.com --- Patches apply against the rework101229 branch of git://git.denx.de/u-boot-atmel.git. Builds and runs. Tested Ethernet and NAND booting. Changes for v3: - Replaced SZ_ macros with shifts - Remove defined values from CONFIG_ defines - Moved boards.cfg entry to correct place - Added MAINTAINERS entry Changes for v2: - Updated for recent at91 changes - Use CONFIG_AT91FAMILY in soft_i2c driver - Fixed missing snapper9260.h config file - Add config to boards.cfg not Makefile - Removed config.mk (now in snapper9260.h) MAINTAINERS |5 + board/bluewater/snapper9260/Makefile | 53 board/bluewater/snapper9260/snapper9260.c | 169 + boards.cfg|2 + include/configs/snapper9260.h | 191 + 5 files changed, 420 insertions(+), 0 deletions(-) create mode 100644 board/bluewater/snapper9260/Makefile create mode 100644 board/bluewater/snapper9260/snapper9260.c create mode 100644 include/configs/snapper9260.h diff --git a/MAINTAINERS b/MAINTAINERS index a5f0493..f8c1996 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -298,6 +298,11 @@ Dan Malek d...@embeddedalley.com stxssa MPC85xx stxxtc MPC8xx +Ryan Mallon r...@bluewatersys.com + + snapper9260 ARM926EJS (AT91SAM9260 SoC) + snapper9g20 ARM926EJS (AT91SAM9G20 SoC) + Eran Man e...@nbase.co.il EVB64260_750CX MPC750CX diff --git a/board/bluewater/snapper9260/Makefile b/board/bluewater/snapper9260/Makefile new file mode 100644 index 000..4fccdaa --- /dev/null +++ b/board/bluewater/snapper9260/Makefile @@ -0,0 +1,53 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2011 Bluewater Systems +# Ryan Mallon r...@bluewatersys.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS-y+= snapper9260.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/bluewater/snapper9260/snapper9260.c b/board/bluewater/snapper9260/snapper9260.c new file mode 100644 index 000..6bb2ee0 --- /dev/null +++ b/board/bluewater/snapper9260/snapper9260.c @@ -0,0 +1,169 @@ +/* + * Bluewater Systems Snapper 9260/9G20 modules + * + * (C) Copyright 2011 Bluewater Systems + * Author: Andre Renaud an...@bluewatersys.com + * Author: Ryan Mallon r...@bluewatersys.com + * + * 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 common.h +#include asm/io.h +#include asm/arch/at91sam9260_matrix.h +#include asm/arch/at91sam9_smc.h +#include asm/arch/at91_common.h +#include asm/arch/at91_pmc.h +#include asm/arch/at91_rstc.h +#include asm/arch/gpio.h +#include net.h +#include netdev.h +#include
Re: [U-Boot] PCIE supported networking cards?
You may want to look at the following patch that adds support for 0x10d3: http://patchwork.ozlabs.org/patch/79788/ - k On Feb 1, 2011, at 3:32 PM, Aaron Williams wrote: This is an Intel EXPI9301 PRO/1000 OEM card, vendor ID 0x8086, device ID 0x10d3. I added it to the list but I don't know what the MAC type is. I'll look into the Linux driver and see if I can see what it is. -Aaron On Tuesday, February 01, 2011 11:19:24 am Scott Wood wrote: On Tue, 1 Feb 2011 13:15:01 -0600 Kumar Gala ga...@kernel.crashing.org wrote: We utilize e1000 PCIe cards all the time Aren't there some versions that work, and some that don't? -Scott - k On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote: Are there any PCIE networking cards that are supported? So far I've tried an Intel card and a Realtek RTL8168 card, but neither is supported. It looks like the E1000 driver only supports PCI and PCIX based cards (Linux uses the e1000e card for PCIe cards). -Aaron ___ 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
On Feb 1, 2011, at 1:46 PM, Haiying Wang wrote: On Tue, 2011-02-01 at 13:15 -0600, Kumar Gala wrote: On Feb 1, 2011, at 11:01 AM, Haiying Wang wrote: On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote: If it is a one time setting, there should be no problem to put it into board code. But these pin settings need to be done before any usage of phy read/write (accessing MDIO/MDC), and need to be released after the usage of phy, thus the devices connected to eLBC like NAND flash/BCSR can be accessed. If we use board code to set/release the pin, we don't know when the phy access and nand flash access will happen. Is this actually a board issue or an SoC issue? It is not a board issue. It is a SoC *feature*. Too many pins are muxed on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20] which is used for MDIO signal. Haiying But its a board decision on how they want to utilize those pins and for what feature. Yes, you can say that. If the board doesn't have QE UCC ETH support at all, we won't have to add such code in QE driver. But if there is QE UCC ETH on board, we have no choice to decide which pins to use. We definitely need to use CE_PB[20] for MDIO signal, there is no other GPIO pins to use for QE's MDIO. Haiying If that case and controlled by some CONFIG_QE_* define than we clearly can make the choice in non-board specific code. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash
On Jan 31, 2011, at 3:37 PM, Wolfgang Denk wrote: Dear Haiying Wang, In message 1296507737.2049.518.camel@haiying-laptop you wrote: On Mon, 2011-01-31 at 21:08 +0100, Wolfgang Denk wrote: Dear haiying.w...@freescale.com, In message 1296499317-26616-6-git-send-email-haiying.w...@freescale.com you wrote: From: Haiying Wang haiying.w...@freescale.com For some board which doesn't have NOR flash and the QE's firmware(ucode) is saved in its NAND flash, we don't want call qe_init in cpu_init_r, but will call it later after nand is initialized. Is there a pressing reason to do this so early for other boards? Can not all boards initialize this later? My understanding is that QE is a cpu feature, so it is called early in cpu_init_r. As Kumar recommended before, I can move qe_init from cpu_init_r to misc_init_r for every 85xx boards with qe support. Is it acceptable to you? Yes, if this way we can avoid to do the same thing at different points in the initialization sequence. Doing this in misc_init_r() isn't right either. We've had this argument before, can we just add a cpu_init_late_r() that is post env_relocate() ? Why should we duplicate cpu generic code in board code? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Trouble running hello_world
Le 02/02/2011 01:54, Alfred Morgan a écrit : Hello clueful people, I am new to U-Boot. I am having trouble executing anything using U-Boot. I have read the U-Boot README and Manual. I have also tried to following the steps on plugcomputer.org's wiki. I was feeling like I was beginning to get a clue but then I couldn't get anything to work. I figured a good place to start is trying to execute the u-boot hello_world standalone program but I couldn't even get that to work. I am connected to the serial port via the GuruPlug JTAG board to my GuruPlug Server Plus and here is my output from the serial console: U-Boot 2009.11-rc1-00602-g28a9c08-dirty (Feb 09 2010 - 18:15:21) Marvell-Plug2L This is an old U-Boot. Can you use a newer one? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mp2usb: remove board support
Hi Eric, Le 25/01/2011 23:31, Eric Bénard a écrit : this board was cancelled long time ago so remove it as it won't be maintained anymore Signed-off-by: Eric Bénarde...@eukrea.com --- board/mp2usb/Makefile| 50 - board/mp2usb/config.mk |3 - board/mp2usb/flash.c | 552 -- board/mp2usb/mp2usb.c| 98 include/configs/mp2usb.h | 242 5 files changed, 0 insertions(+), 945 deletions(-) delete mode 100644 board/mp2usb/Makefile delete mode 100644 board/mp2usb/config.mk delete mode 100644 board/mp2usb/flash.c delete mode 100644 board/mp2usb/mp2usb.c delete mode 100644 include/configs/mp2usb.h This patch does not remove the mp2usb from boards.cfg. Can you please fix that? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot compilation lowlevel_init.S:619: error: #error Unknown DDR configuration!!!
hi, On Tue, Feb 1, 2011 at 9:00 PM, Vaishali vaishali.dhak...@sukrutsystems.com wrote: Getting this error with the u-boot compilation http://pastebin.com/h3x90vHK u-boot http://pastebin.com/h3x90vHK%0Au-boot is a git clone of the git://gitorious.org/hawkboard/u-boot.git plz help any idea what needs to be done to fix this . Thanks . Mainline u-boot has hawkboard support. Why don't you try building and using that. Check out the doc/README.hawkboard for the procedure to build and flash. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sh: add support the CONFIG_SYS_LDSCRIPT
Applied, thanks. On Thu, Jan 27, 2011 at 10:06:14AM +0900, Yoshihiro Shimoda wrote: Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- arch/sh/config.mk |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/sh/config.mk b/arch/sh/config.mk index 415c949..b408a44 100644 --- a/arch/sh/config.mk +++ b/arch/sh/config.mk @@ -31,4 +31,8 @@ endif PLATFORM_CPPFLAGS += -DCONFIG_SH -D__SH__ PLATFORM_LDFLAGS += -e $(CONFIG_SYS_TEXT_BASE) --defsym reloc_dst=$(CONFIG_SYS_TEXT_BASE) +ifdef CONFIG_SYS_LDSCRIPT +LDSCRIPT := $(subst ,,$(CONFIG_SYS_LDSCRIPT)) +else LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds +endif -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot compilation lowlevel_init.S:619: error: #error Unknown DDR configuration!!!
hi, On Tue, Feb 1, 2011 at 9:00 PM, Vaishali vaishali.dhak...@sukrutsystems.com wrote: Getting this error with the u-boot compilation http://pastebin.com/h3x90vHK u-boot http://pastebin.com/h3x90vHK%0Au-boot is a git clone of the git://gitorious.org/hawkboard/u-boot.git plz help any idea what needs to be done to fix this . Mainline u-boot has hawkboard support. Why don't you try building and using that. Check out the doc/README.hawkboard for the procedure to build and flash. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spi subystem maintainer?
On Feb 1, 2011, at 1:29 PM, Wolfgang Denk wrote: Dear Kumar Gala, In message 9a3702c1-3ed1-4f24-a0bc-ca7daea46...@kernel.crashing.org you wrote: Do we have one? Not yet. Are you volunteering? Nope, too much to do as it stands. Wanted to see if anyone had input on how to deal with the SPI controller on some of our newer parts. It expects command data xfer's to happen together. However our current code does not call spi_xfer() that way. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] change email address in MAINTAINERS
Applied, thanks. On Wed, Feb 02, 2011 at 10:05:39AM +0900, Yoshihiro Shimoda wrote: Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- This patch depends on sh: add support for sh7757lcr board. MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7313542..c26c9a7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1017,7 +1017,7 @@ Mark Jonas mark.jo...@de.bosch.com mpr2SH7720 -Yoshihiro Shimoda shimoda.yoshih...@renesas.com +Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com MS7720SESH7720 R0P77570030RL SH7757 -- 1.7.1 ___ 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
[U-Boot] at91sam9263_nandflash build issues
The problem is clear from this IRC log, where vickylinuxer described his grief (so I included the log, the board really doesn't build). I also did a quick and dirty patch (follows the log, it might give you an idea where it breaks, but it's a mess -- not all is relevant and it probably breaks it even more). Cheers // LOG - 05:01 vickylinuxer guys i am making u-boot for at91sam9263 with ubifs support...which u-boot version i can prefer... 05:02 vickylinuxer because u-boot-12-2010 gave so many compilation problems... 05:06 Marex vickylinuxer: look ... what's the problem ? what board did you config it for ? 05:06 Marex vickylinuxer: give me the exact xyz for xyz_config 05:10 vickylinuxer at91sam9263_nandflash 05:11 vickylinuxer atmel board 05:11 Marex compiling, checking ... please wait 05:12 Marex I see 05:12 Marex vickylinuxer: it'll take a bit to fix it all ... wanna tinker with it and assist in fixing ? 05:38 vickylinuxer yes marex i want to update from ver 2010.09 to 2010.12..but 09 is working good... 05:39 vickylinuxer but when compiling uboot-12 i m getting sdram error and so on... 05:51 Marex vickylinuxer: ok well ... there seems to be more breakage than I expected 05:57 Marex vickylinuxer: try this http://pastebin.com/2Rq92nNg // DIFF - diff --git a/config.mk b/config.mk index 5147c35..fe1d40c 100644 --- a/config.mk +++ b/config.mk @@ -261,7 +261,7 @@ $(obj)%.s: %.c # If the list of objects to link is empty, just create an empty built-in.o cmd_link_o_target = $(if $(strip $1),\ - $(LD) $(LDFLAGS) -r -o $@ $1,\ + $(LD) -r -o $@ $1,\ rm -f $@; $(AR) rcs $@ ) # diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c index bfa1f3a..1cc8bc0 100644 --- a/drivers/serial/atmel_usart.c +++ b/drivers/serial/atmel_usart.c @@ -23,6 +23,7 @@ #include asm/io.h #include asm/arch/clk.h +#include asm/arch/hardware.h #include asm/arch/memory-map.h #if defined(CONFIG_USART0) diff --git a/drivers/spi/atmel_dataflash_spi.c b/drivers/spi/atmel_dataflash_spi.c index 4a5c4aa..d5215c0 100644 --- a/drivers/spi/atmel_dataflash_spi.c +++ b/drivers/spi/atmel_dataflash_spi.c @@ -158,12 +158,12 @@ unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc) } /* arm simple, non interrupt dependent timer */ - reset_timer_masked(); + reset_timer(); timeout = 0; writel(AT91_SPI_TXTEN + AT91_SPI_RXTEN, AT91_BASE_SPI + AT91_SPI_PTCR); while (!(readl(AT91_BASE_SPI + AT91_SPI_SR) AT91_SPI_RXBUFF) - ((timeout = get_timer_masked()) CONFIG_SYS_SPI_WRITE_TOUT)); + ((timeout = get_timer(0)) CONFIG_SYS_SPI_WRITE_TOUT)); writel(AT91_SPI_TXTDIS + AT91_SPI_RXTDIS, AT91_BASE_SPI + AT91_SPI_PTCR); pDesc-state = IDLE; diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h index f6cb406..3db8bd0 100644 --- a/include/configs/at91sam9263ek.h +++ b/include/configs/at91sam9263ek.h @@ -27,6 +27,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_AT91_LEGACY +#defineCONFIG_AT91FAMILY + /* ARM asynchronous clock */ #define CONFIG_SYS_AT91_MAIN_CLOCK 16367660/* 16.367 MHz crystal */ #define CONFIG_SYS_HZ 1000 @@ -341,6 +344,10 @@ */ #define CONFIG_SYS_MALLOC_LEN ROUND(3 * CONFIG_ENV_SIZE + 128*1024, 0x1000) +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x1000 - \ + GENERATED_GBL_DATA_SIZE) + #define CONFIG_STACKSIZE (32*1024) /* regular stack */ #ifdef CONFIG_USE_IRQ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch V6 0/4] Add basic NVIDIA Tegra2 SoC support
On 02/02/11 02:09, Tom Warren wrote: I haven't seen any new feedback on this version (V6) of the patchset since it was posted. Wolfgang, Mike, Peter, et al - are you happy with the current patch? I'm Ok with the current patch. If so, when can I expect it to be pushed? Thanks, Tom On Thu, Jan 27, 2011 at 1:58 PM, Tom Warren twarren.nvi...@gmail.com wrote: This series of patches adds preliminary/baseline support for NVIDIA's Tegra2 SoC. Basic CPU (AVP), RAM and UART init are covered so that the system (Harmony or Seaboard) can boot to the U-Boot serial cmd prompt. Further support (for Cortex-A9 CPU(s), USB, SD/MMC, etc.) to follow. Changes for V2: - Coding style cleanup - Remove mach-types.h change; wait for ARM kernel sync-up - Move serial driver changes to separate patch - Use board/nvidia/ instead of /board/tegra - Remove TRUE/FALSE defines - Use standard NS16550 register/bit defines in UART init - Change nv-common.h config file to tegra2-common.h Changes for V3: - Use I/O accessors for Tegra2 HW MMIO register access - Allow conditional compile of UARTA/UARTD code to save space Changes for V4: - Use address of HW structs (pmc, etc.) in readl/writel - Remove empty lines, fix mixed case hex #s comments in header(s) - Move board/nvidia/common/board.c UART code header to arch/arm/cpu/armv7/tegra2/ - Declare internal functions as static in UART code Changes for V5: - Move arch/arm/cpu/armv7/uart.c board.h to drivers/serial and rename to serial_tegra2.c - Remove use of uart_num UART_A/D in serial_tegra2, simplify code Changes for V6: - Fix uart.c add delete in previous patchset - Move pinmux clock init code to common board file as per review - Use #if defined() where possible in config files/UART code - Drop all typedef and volatile struct declarations in header files Tom Warren (4): arm: Tegra2: Add basic NVIDIA Tegra2 SoC support serial: Add Tegra2 serial port support arm: Tegra2: Add support for NVIDIA Harmony board arm: Tegra2: Add support for NVIDIA Seaboard board MAINTAINERS |5 + arch/arm/cpu/armv7/tegra2/Makefile | 48 +++ arch/arm/cpu/armv7/tegra2/board.c| 88 arch/arm/cpu/armv7/tegra2/config.mk | 28 arch/arm/cpu/armv7/tegra2/lowlevel_init.S| 65 + arch/arm/cpu/armv7/tegra2/sys_info.c | 35 + arch/arm/cpu/armv7/tegra2/timer.c| 122 arch/arm/include/asm/arch-tegra2/clk_rst.h | 165 ++ arch/arm/include/asm/arch-tegra2/pinmux.h| 55 arch/arm/include/asm/arch-tegra2/pmc.h | 124 + arch/arm/include/asm/arch-tegra2/sys_proto.h | 35 + arch/arm/include/asm/arch-tegra2/tegra2.h| 49 +++ arch/arm/include/asm/arch-tegra2/uart.h | 47 ++ board/nvidia/common/board.c | 193 ++ board/nvidia/harmony/Makefile| 50 +++ board/nvidia/seaboard/Makefile | 50 +++ boards.cfg |2 + common/serial.c |3 +- drivers/serial/Makefile |1 + drivers/serial/serial_tegra2.c | 77 ++ drivers/serial/serial_tegra2.h | 29 include/configs/harmony.h| 49 +++ include/configs/seaboard.h | 43 ++ include/configs/tegra2-common.h | 160 + include/serial.h |3 +- 25 files changed, 1524 insertions(+), 2 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/Makefile create mode 100644 arch/arm/cpu/armv7/tegra2/board.c create mode 100644 arch/arm/cpu/armv7/tegra2/config.mk create mode 100644 arch/arm/cpu/armv7/tegra2/lowlevel_init.S create mode 100644 arch/arm/cpu/armv7/tegra2/sys_info.c create mode 100644 arch/arm/cpu/armv7/tegra2/timer.c create mode 100644 arch/arm/include/asm/arch-tegra2/clk_rst.h create mode 100644 arch/arm/include/asm/arch-tegra2/pinmux.h create mode 100644 arch/arm/include/asm/arch-tegra2/pmc.h create mode 100644 arch/arm/include/asm/arch-tegra2/sys_proto.h create mode 100644 arch/arm/include/asm/arch-tegra2/tegra2.h create mode 100644 arch/arm/include/asm/arch-tegra2/uart.h create mode 100644 board/nvidia/common/board.c create mode 100644 board/nvidia/harmony/Makefile create mode 100644 board/nvidia/seaboard/Makefile create mode 100644 drivers/serial/serial_tegra2.c create mode 100644 drivers/serial/serial_tegra2.h create mode 100644 include/configs/harmony.h create mode 100644 include/configs/seaboard.h create mode 100644
