Re: [U-Boot] how to create patches for mailing
On Thu, Jan 24, 2013 at 13:10:56, Maxim Podbereznyy wrote: Hi! I want to add a new board support to u-boot. So I did the following: 1) git clone git://git.denx.de/u-boot.git u-boot-dev 2) modified existing files, added new Use git commit to commit your changes to tree 3) built the tree for my board, beagle and overo - OK 4) git format-patch - nothing happens git-format-patch -M --signoff --stat -p --raw -n -3 --cover-letter -3 == generate patches for 1st 3 patch -n = use n/n style --cover-letter == Generate Cover letter (0/n patch) are there any step by step instructions how to create and submit patches to u-boot mail-list? Use git-send-email to send patches git-send-email --to ' u-boot@lists.denx.de' --cc 'maintain...@email.id' --cc 'related_develo...@email.id' --cc 'self_for_refere...@email.id' --suppress-cc=all required-patches Reading this http://www.denx.de/wiki/view/U-Boot/Patchesdoes not give sufficient comprehension how to do it.. I appreciate any comments.. Regards, Gururaja ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p2041: skip waiting for SERDES bank 3 reset done
Hello, On Thu, 24 Jan 2013 02:33:31 + Xie Shaohui-B21989 b21...@freescale.com wrote: ... currently I do not have access to the p2041rdb board, but here is the previously captured boot log where I've seen this: U-Boot 2011.09-0-g2c02d1d (Oct 22 2011 - 18:31:36) [S.H] Did you try the latest U-boot? This u-boot is old. I don't see the time out dump with the latest U-boot. I'm not sure which exact version I've tried, IIRC it was v2013-rcX and the problem was there also. I'll have access to the p2041rdb board tomorrow and will tell which exact version it was. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] raspberry pi
Hi, Is there any active raspberry pi development going on, i am planning to do a support package for raspberry pi, any suggestions would be welcome. thanks, Haneef. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] powerpc/85xx: select -mcpu=8540 to match -Wa, e500
Scott, I reverted this patch, and it fixed some build errors: 20001122-1.c:1:0: error: E500 and FPRs not supported 20010114-2.c:1:0: error: E500 and FPRs not supported make[2]: *** [/local/afleming/u-boot/build/P2020DS/post/lib_powerpc/fpu/20001122-1.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [/local/afleming/u-boot/build/P2020DS/post/lib_powerpc/fpu/20010114-2.o] Error 1 make[1]: *** [postdeps] Error 2 make: *** [/local/afleming/u-boot/build/P2020DS/post/libpost.o] Error 2 make: INTERNAL: Exiting with 4 jobserver tokens available; should be 3! Similar errors were seen on all these boards: P2041RDB_SRIO_PCIE_BOOT P5020DS P3041DS P5020DS_NAND P2020DS P3041DS_NAND P5020DS_SDCARD P2020DS_36BIT P3041DS_SDCARD P5020DS_SECURE_BOOT P2020DS_DDR2 P3041DS_SECURE_BOOT P5020DS_SPIFLASH P2020DS_SDCARDP3041DS_SPIFLASH P5020DS_SRIO_PCIE_BOOT P2020DS_SPIFLASH P3041DS_SRIO_PCIE_BOOT P5040DS P2041RDB P4080DS xpedite520x P2041RDB_NAND P4080DS_SDCARD xpedite537x P2041RDB_SDCARD P4080DS_SECURE_BOOT xpedite550x P2041RDB_SECURE_BOOT P4080DS_SPIFLASH P2041RDB_SPIFLASH P4080DS_SRIO_PCIE_BOOT On Fri, Jan 18, 2013 at 7:38 PM, Scott Wood scottw...@freescale.com wrote: This allows building with toolchains that by default target e6500. When targetting e6500, GCC generates a two-operand form of mfcr which gas normally maps to mfocr. However, when we tell gas to target e500 rather than e6500, it rejects two-operand mfcr. Tell GCC to target a least-common-denominator e500 to match what we tell the assembler. -misel and -mno-strict-align are added to keep the code size from growing (it actually ends up shrinking a bit compared to -mcpu=603e, which was the default on my old toolchain). Signed-off-by: Scott Wood scottw...@freescale.com --- v2: add -misel and -mno-strict-align arch/powerpc/cpu/mpc85xx/config.mk |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/cpu/mpc85xx/config.mkb/arch/powerpc/cpu/mpc85xx/ config.mk index f36d823..450d511 100644 --- a/arch/powerpc/cpu/mpc85xx/config.mk +++ b/arch/powerpc/cpu/mpc85xx/config.mk @@ -23,7 +23,8 @@ PLATFORM_RELFLAGS += -meabi -PLATFORM_CPPFLAGS += -ffixed-r2 -Wa,-me500 -msoft-float -mno-string +PLATFORM_CPPFLAGS += -ffixed-r2 -mcpu=8540 -misel -mno-strict-align \ + -Wa,-me500 -msoft-float -mno-string # -mspe=yes is needed to have -mno-spe accepted by a buggy GCC; # see [PATCH,rs6000] make -mno-spe work as expected on -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] B4860/B4420 patches and some updates for qixis and T4240QDS
I'm seeing these errors, when these patches are enabled: /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:575:2: error: #error Processor type not defined for this platform /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:579:2: error: #error CONFIG_SYS_CCSRBAR_DEFAULT is not defined for this platform. /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:575:2: error: #error Processor type not defined for this platform /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:579:2: error: #error CONFIG_SYS_CCSRBAR_DEFAULT is not defined for this platform. In file included from /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config.h:25:0, from /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include/config.h:13, from /local/afleming/u-boot/include/common.h:37, from /local/afleming/u-boot/lib/asm-offsets.c:18: /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:575:2: error: #error Processor type not defined for this platform /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:579:2: error: #error CONFIG_SYS_CCSRBAR_DEFAULT is not defined for this platform. In file included from /local/afleming/u-boot/include/mpc85xx.h:14:0, from /local/afleming/u-boot/include/common.h:93, from /local/afleming/u-boot/lib/asm-offsets.c:18: /local/afleming/u-boot/include/e500.h:19:26: error: 'CONFIG_SYS_NUM_FMAN' undeclared here (not in a function) In file included from /local/afleming/u-boot/include/common.h:94:0, from /local/afleming/u-boot/lib/asm-offsets.c:18: /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/immap_85xx.h:1400:33: error: 'CONFIG_SYS_FSL_SRIO_MAX_PORTS' undeclared here (not in a function) /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/immap_85xx.h:1498:28: error: 'CONFIG_SYS_FSL_SRIO_OB_WIN_NUM' undeclared here (not in a function) /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/immap_85xx.h:1500:27: error: 'CONFIG_SYS_FSL_SRIO_IB_WIN_NUM' undeclared here (not in a function) make: *** [/local/afleming/u-boot/build/B4420QDS_SPIFLASH/lib/asm-offsets.s] Error 1 make: *** Waiting for unfinished jobs This was also seen on B4860QDS_SPIFLASH On Thu, Jan 17, 2013 at 11:18 PM, Aggrwal Poonam-B10812 b10...@freescale.com wrote: Hello Andy Any update on this patch set? Regards Poonam From: Aggrwal Poonam-B10812 Sent: Friday, December 21, 2012 6:16 PM To: U-Boot-Denx Subject: B4860/B4420 patches and some updates for qixis and T4240QDS The patchset contains the following patches: Mainly related to B4860/B4420QDS. Some are qixis updates and related additions for B4860/B4420QDS and T4240QDS. [PATCH 01/09] powerpc/mpc85xx: Few updates for B4860 cpu changes [PATCH 02/09] powerpc/mpc85xx:Add support of B4420 SoC [PATCH 03/09] board/freescale/common:Add support of QTAG register [PATCH 04/09] powerpc/mpc85xx:Fix Core cluster configuration loop [PATCH 05/09] powerpc/b4860qds: Added Support for B4860QDS [PATCH 06/09] powerpc/qixis: enable qixis dump command and add switch dumping command [PATCH 07/09] powerpc/b4860qds: Add support to dump switch settings on b4860qds board [PATCH 08/09] powerpc/t4240qds: Add support to dump switch settings on t4240qds board [PATCH 09/09] powerpc/t4240qds: Print FPGA detail version Regards Poonam ___ 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] how to create patches for mailing
On Thu, Jan 24, 2013 at 13:51:30, Maxim Podbereznyy wrote: Hi Gururaja! 1st don’t top-most. It breaks the flow. Your instructions are exceptional! However I have a few questions: 1) why should I generate patches for 1st 3 patch, because I have only one? That was just an example. 2) if there are 3 patches (only 1 is mine) + a cover which exactly required-patches should I send? If you have one patch, then only 1 patch should be sent. Cover-letter normally is for new feature addition/improvement which involves lots of files platforms. Normal fix/correction doesn’t require a cover-letter. thanks! 2013/1/24 Hebbar, Gururaja gururaja.heb...@ti.com On Thu, Jan 24, 2013 at 13:10:56, Maxim Podbereznyy wrote: Hi! I want to add a new board support to u-boot. So I did the following: 1) git clone git://git.denx.de/u-boot.git u-boot-dev 2) modified existing files, added new Use git commit to commit your changes to tree 3) built the tree for my board, beagle and overo - OK 4) git format-patch - nothing happens git-format-patch -M --signoff --stat -p --raw -n -3 --cover-letter -3 == generate patches for 1st 3 patch -n = use n/n style --cover-letter == Generate Cover letter (0/n patch) are there any step by step instructions how to create and submit patches to u-boot mail-list? Use git-send-email to send patches git-send-email --to ' u-boot@lists.denx.de' --cc 'maintain...@email.id' --cc 'related_develo...@email.id' --cc 'self_for_refere...@email.id' --suppress-cc=all required-patches Reading this http://www.denx.de/wiki/view/U-Boot/Patchesdoes not give sufficient comprehension how to do it.. I appreciate any comments.. Regards, Gururaja Regards, Gururaja ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to create patches for mailing
Hi Gururaja! Your instructions are exceptional! However I have a few questions: 1) why should I generate patches for 1st 3 patch, because I have only one? 2) if there are 3 patches (only 1 is mine) + a cover which exactly required-patches should I send? thanks! 2013/1/24 Hebbar, Gururaja gururaja.heb...@ti.com On Thu, Jan 24, 2013 at 13:10:56, Maxim Podbereznyy wrote: Hi! I want to add a new board support to u-boot. So I did the following: 1) git clone git://git.denx.de/u-boot.git u-boot-dev 2) modified existing files, added new Use git commit to commit your changes to tree 3) built the tree for my board, beagle and overo - OK 4) git format-patch - nothing happens git-format-patch -M --signoff --stat -p --raw -n -3 --cover-letter -3 == generate patches for 1st 3 patch -n = use n/n style --cover-letter == Generate Cover letter (0/n patch) are there any step by step instructions how to create and submit patches to u-boot mail-list? Use git-send-email to send patches git-send-email --to ' u-boot@lists.denx.de' --cc 'maintain...@email.id' --cc 'related_develo...@email.id' --cc 'self_for_refere...@email.id' --suppress-cc=all required-patches Reading this http://www.denx.de/wiki/view/U-Boot/Patchesdoes not give sufficient comprehension how to do it.. I appreciate any comments.. Regards, Gururaja ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] lcd: add option for board specific splash screen preparation
On 01/24/13 00:13, Jeroen Hofstee wrote: Hello Nikita, On 01/23/2013 09:31 AM, Nikita Kiryanov wrote: On 01/21/2013 09:14 PM, Jeroen Hofstee wrote: Hello Nikita, On 01/21/2013 08:51 AM, Nikita Kiryanov wrote: Hi Jeroen, On 01/20/2013 10:34 PM, Jeroen Hofstee wrote: [...] diff --git a/include/lcd.h b/include/lcd.h index c24164a..4ac4ddd 100644 --- a/include/lcd.h +++ b/include/lcd.h @@ -47,6 +47,7 @@ extern struct vidinfo panel_info; extern void lcd_ctrl_init (void *lcdbase); extern void lcd_enable (void); +extern int board_splash_screen_prepare(void); /* setcolreg used in 8bpp/16bpp; initcolregs used in monochrome */ extern void lcd_setcolreg (ushort regno, Other boards seem to do this in lcd_enable. Perhaps that is also an option. The problem with doing it in lcd_enable is that it's akin to a side effect, given what the function's name advertises. Preparing the splash image can, however, be a natural part of the process that displays it. mmm, I am not so sure I agree that loading a bitmap in lcd_enable is a _problem_, while loading it in show logo and requiring a CONFIG_* is _natural_. Well, it is a problem. If we don't respect the abstractions we create then things like function names become meaningless. A function called lcd_enable should do just that- enable lcd. Not load stuff from storage to memory or manipulate BMPs. my point is that lcd_clear will e.g. call lcd_logo. Although I haven't tested it, it seems you're make a side effect of a function only called once a side effect of another function (which could be called multiple times). So you make things even worse (loading an bitmap while the function is just named to display it). So what's your point? Do you think we should add a splash screen specific callback inside the board.c U-Boot boot flow? Please, be more specific, as both approaches are not suitable according to what was said above... But anyway, can't this at least be changed to a __weak function, so the CONFIG and ifdef stuff can be dropped? The motivation behind the CONFIG was to make it a documentable user setting, rather than an undocumented feature buried in the code. then document the callback... Sorry, may be I've missed something, but I can't see any callback being documented in the README file... I don't see the improvement of this patch.. What does that suppose to mean? Either be constructive or don't bother... I'd like to hear Anatolij's opinion on this. -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to create patches for mailing
Hi Maxim, Le Thu, 24 Jan 2013 12:21:30 +0400, Maxim Podbereznyy lisar...@gmail.com a écrit : Your instructions are exceptional! However I have a few questions: 1) why should I generate patches for 1st 3 patch, because I have only one? 2) if there are 3 patches (only 1 is mine) + a cover which exactly required-patches should I send? you have more details here : http://www.denx.de/wiki/U-Boot/Patches Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
Mats Kärrman mats.karr...@tritech.se wrote on 2013/01/23 22:58:56: Dear Wolfgang Denk, Found that it was looping endlessly in arch/powerpc/lib/ticks.S::wait_ticks (). Reverting commit ppc: Create a stack frame for wait_ticks() made everything work again. This makes no sense to me - especially as it works on all other systems. Me neither, there is not a lot details. I do recall having other problems with wait_ticks from time to time, sometimes the TB counter(mtfbu, mftb in get_ticks) would not increment so one would just loop forever in wait_ticks. This problem had nothing to do with my patch though. Never got around to finding out what caused it, we ended up blaming unstable HW. Some ideas though: - Perhaps you have some alignment problem, try adding nop's here and there. - My patch uses r0(which is what one should use to make gdb happy) instead of r8 to stash the LR. Possibly you have some odd dependency on r0, try using r8 again. None of the above is a real fix tough. If you say it works, it makes no sense to me either. I thought it might be some subtle difference in the way the e300c4 core or GCC works compared to other PPC cores. If there are no such differences, then a patch with no intended functional difference beyond keeping gdb happy should not make any difference, good or bad. hmm, we use e300c2 with no problem. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
Joakim Tjernlund/Transmode wrote on 2013/01/24 09:40:45: From: Joakim Tjernlund/Transmode To: Mats Kärrman mats.karr...@tritech.se, Cc: u-boot@lists.denx.de u-boot@lists.denx.de, Wolfgang Denk w...@denx.de Date: 2013/01/24 09:40 Subject: RE: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01 Mats Kärrman mats.karr...@tritech.se wrote on 2013/01/23 22:58:56: Dear Wolfgang Denk, Found that it was looping endlessly in arch/powerpc/lib/ticks.S::wait_ticks (). Reverting commit ppc: Create a stack frame for wait_ticks() made everything work again. This makes no sense to me - especially as it works on all other systems. Me neither, there is not a lot details. I do recall having other problems with wait_ticks from time to time, sometimes the TB counter(mtfbu, mftb in get_ticks) would not increment so one would just loop forever in wait_ticks. This problem had nothing to do with my patch though. Never got around to finding out what caused it, we ended up blaming unstable HW. Some ideas though: - Perhaps you have some alignment problem, try adding nop's here and there. - My patch uses r0(which is what one should use to make gdb happy) instead of r8 to stash the LR. Possibly you have some odd dependency on r0, try using r8 again. Try getting LR from stack instead of trusting r0 to be valid: - mtlrr0 /* restore link register */ + lwz r0, 20(r1) /* restore link register */ + mtlrr0 This is what one should do but as we have complete control of r0 here we don't need to. hmm, do you have WATCHDOG_RESET defined? does it use r0? I guess the above patch would make wait_ticks safer from accidental use by WATCHDOG_RESET, if it works for you, please send a proper patch to u-boot. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] cm-t35: add support for dvi displays
On 01/23/13 23:39, Jeroen Hofstee wrote:
On 01/21/2013 09:12 AM, Nikita Kiryanov wrote:
+else if (!strncmp(displaytype, dvi800x600, 10))
+return set_dvi_preset(preset_dvi_800X600, 800, 600);
+else if (!strncmp(displaytype, dvi1024x768, 11))
+return set_dvi_preset(preset_dvi_1024X768, 1024, 768);
+else if (!strncmp(displaytype, dvi1152x864, 11))
+return set_dvi_preset(preset_dvi_1152X864, 1152, 864);
+else if (!strncmp(displaytype, dvi1280x960, 11))
+return set_dvi_preset(preset_dvi_1280X960, 1280, 960);
+else if (!strncmp(displaytype, dvi1280x1024, 12))
+return set_dvi_preset(preset_dvi_1280X1024, 1280, 1024);
+
+return NONE;
+}
I think the lcd_line_length is no longer needed. ( but I haven't checked)
Wondering if this should be board specific..
These variables are here because at the time the implementation of
lcd.c required them to be defined by the board. If you succeed in
removing them it will be a simple matter of a clean up patch.
What I meant is that Stephan Warren posted a patch to fix the lcd_line_length
update in general, see http://patchwork.ozlabs.org/patch/212378/. (Which I
thought was picked up, but isn't yet), instead of fixing it in boards, like
you do.
Unless. explicitly, requested by Anatolij,
we should not wait for specific patches to be merged or not merged.
This does not work like this.
After improvements are made, the code can be adjusted -
that's what the -rc cycle is for.
+void lcd_ctrl_init(void *lcdbase)
+{
+struct dispc_regs *dispc = (struct dispc_regs *)OMAP3_DISPC_BASE;
+struct prcm *prcm = (struct prcm *)PRCM_BASE;
+char *displaytype = getenv(displaytype);
+
+if (displaytype == NULL)
+return;
+
+lcd_def = env_parse_displaytype(displaytype);
+if (lcd_def == NONE)
+return;
+
+panel_cfg.frame_buffer = lcdbase;
+omap3_dss_panel_config(panel_cfg);
+/*
+ * Pixel clock is defined with many divisions and only few
+ * multiplications of the system clock. Since DSS FCLK divisor is
set
+ * to 16 by default, we need to set it to a smaller value, like 3
+ * (chosen via trial and error).
+ */
bah, guessing timer values, this might help you
https://github.com/jhofstee/u-boot/blob/bpp3_dev2/board/victron/bpp3/lcd_timing.c
(a bit old, but simply downloading the file should work, and yes it
might warn a bit)
Thanks.
I'll consider it for future extensions to this code, but for the time
being the guess serves its purpose.
What purpose does it serve exactly? The link I mentioned is not to update the
code per definition, but to be a bit more explicit why the timer adjustments
are
needed instead of this seems to work..
Thanks for the explanation, we will look into this.
Currently, I don't see a good reason we should miss the merge window
just to adopt those above. We will put it on our TODO list.
Thanks!
The whole routine should go to the video driver in my opinion.
What this function is, is predefines + call to omap3_dss_panel_config()
+ some corrections.
Anything related to the predefines is not generic. They have many
assumptions in them (such as whether the screen is active or passive)
and they are selected using a user interface that is also specific to
our board.
The adjustment after the call to omap3_dss_panel_config() is, once
again, specific to our own choices.
So overall, I don't think this is fit to be a generic driver function.
The idea would be that the driver could optionally check the env for a
display configuration. If not found or not enabled call board_video_init.
So there is a single driver for video and lcd and configurable by the
environment and you can also have all control of it in the board. I don't
have the time currently to check if this would actually work, but
I don't see a reason why not (perhaps I can check something during
the weekend).
It should work, but first we should decide if it is suitable for all
OMAP DSS users.
So I would suggest we see how it works and if people decide this is
good enough to be in the generic DSS code, we can move it to live there.
And I didn't mean the predefined lcd configs. I am fine with you having
them in you board / tested to work / delivered with them etc. But you
add custom omap frame buffers settings, set by the user and I don't
think that part should go into a board, since it is at least common to
omap(3/4?) (or at least should be in my opinion).
If I get you correctly,
you are suggesting to parametrize the GFXFORMAT_RGB16 and GFXBURSTSIZE16?
This can be done.
+ clrsetbits_le32(prcm-clksel_dss, 0xF, 3);
+/*
+ * Some of what the omap3_dss_panel_config() function did, needs
to be
+ * adjusted, otherwise the image will be messed up/not appear at
all.
+ */
+clrsetbits_le32(dispc-gfx_attributes, 0xF 1, GFXFORMAT_RGB16
1);
+clrsetbits_le32(dispc-gfx_attributes, 0x3
Re: [U-Boot] [PATCH V3 0/9] separate miiphy from ethernet
On 23/01/2013 20:06, Troy Kisky wrote: Hi Troy, you're right, this patchset stalls - but on the other side, I have not found any comment that should avoid that it can be merged. If nobody complains, I propose I go on and I try to merge it into u-boot-imx. Here my first attempt: as far as I can see, the patchset breaks mx6qsabreauto and mx35 boards. Generally speking, it breaks boards like flea3 that define CONFIG_PHYLIB in their config file. undefined reference to `phy_connect_dev' drivers/net/libnet.o: In function `fecmxc_initialize_multi': I think the patchset assumes that boards have its own board_eth_init(), making the required phy initialization, but most boards call only cpu_eth_init(). Strange, my ./MAKEALL -a arm finished fine Surely something is missing on my tree - SUMMARY Boards compiled: 297 Boards with warnings but no errors: 3 ( VCMA9 smdk2410 cam_enc_4xx ) -- Did you apply [PATCH V3 5/9] phy: add phy_find_by_mask/phy_connect_dev That is ! It is assigned to Joe, and I have not found soon in patchwork. Now I can build. Joe, this patch is really network-related and is in your competence area, but if you do not complain I will apply together with the rest to avoid to break some i.MX boards. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2] powerpc/mpc85xx: Add property 'fsl, sec-era' in device tree node 'crypto'
If property 'fsl,sec-era' is already present, it is updated.
This property is required so that applications can ascertain which
descriptor commands are supported on a particular CAAM version.
Signed-off-by: Vakul Garg va...@freescale.com
Cc: Andy Fleming aflem...@gmail.com
---
Changelog:
v1: Added '__iomem' as per Timur's comment.
v2:
Define CONFIG_SYS_FSL_SEC_OFFSET for non corenet platforms.
This fixes compilation issue. Tested for P1010.
arch/powerpc/cpu/mpc85xx/fdt.c|8 +++
arch/powerpc/cpu/mpc8xxx/fdt.c| 78 -
arch/powerpc/include/asm/immap_85xx.h |7 +++
3 files changed, 92 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index ab09330..b0a1368 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -591,6 +591,14 @@ void ft_cpu_setup(void *blob, bd_t *bd)
/* delete crypto node if not on an E-processor */
if (!IS_E_PROCESSOR(get_svr()))
fdt_fixup_crypto_node(blob, 0);
+#if CONFIG_SYS_FSL_SEC_COMPAT = 4
+ else {
+ ccsr_sec_t __iomem *sec;
+
+ sec = (void __iomem *)CONFIG_SYS_FSL_SEC_ADDR;
+ fdt_fixup_crypto_node(blob, in_be32(sec-secvid_ms));
+ }
+#endif
fdt_fixup_ethernet(blob);
diff --git a/arch/powerpc/cpu/mpc8xxx/fdt.c b/arch/powerpc/cpu/mpc8xxx/fdt.c
index 1986fea..2847094 100644
--- a/arch/powerpc/cpu/mpc8xxx/fdt.c
+++ b/arch/powerpc/cpu/mpc8xxx/fdt.c
@@ -297,10 +297,86 @@ void fdt_fixup_crypto_node(void *blob, int sec_rev)
fdt_strerror(err));
}
#elif CONFIG_SYS_FSL_SEC_COMPAT = 4 /* SEC4 */
+static u8 caam_get_era(void)
+{
+ static const struct {
+ u16 ip_id;
+ u8 maj_rev;
+ u8 era;
+ } caam_eras[] = {
+ {0x0A10, 1, 1},
+ {0x0A10, 2, 2},
+ {0x0A12, 1, 3},
+ {0x0A14, 1, 3},
+ {0x0A14, 2, 4},
+ {0x0A16, 1, 4},
+ {0x0A10, 3, 4},
+ {0x0A11, 1, 4},
+ {0x0A18, 1, 4},
+ {0x0A11, 2, 5},
+ {0x0A12, 2, 5},
+ {0x0A13, 1, 5},
+ {0x0A1C, 1, 5}
+ };
+
+ ccsr_sec_t __iomem *sec = (void __iomem *)CONFIG_SYS_FSL_SEC_ADDR;
+ u32 secvid_ms = in_be32(sec-secvid_ms);
+ u32 ccbvid = in_be32(sec-ccbvid);
+ u16 ip_id = (secvid_ms SEC_SECVID_MS_IPID_MASK)
+ SEC_SECVID_MS_IPID_SHIFT;
+ u8 maj_rev = (secvid_ms SEC_SECVID_MS_MAJ_REV_MASK)
+ SEC_SECVID_MS_MAJ_REV_SHIFT;
+ u8 era = (ccbvid SEC_CCBVID_ERA_MASK) SEC_CCBVID_ERA_SHIFT;
+
+ int i;
+
+ if (era)/* This is '0' prior to CAAM ERA-6 */
+ return era;
+
+ for (i = 0; i ARRAY_SIZE(caam_eras); i++)
+ if (caam_eras[i].ip_id == ip_id
+ caam_eras[i].maj_rev == maj_rev)
+ return caam_eras[i].era;
+
+ return 0;
+}
+
+static void fdt_fixup_crypto_era(void *blob, u32 era)
+{
+ int err;
+ int crypto_node;
+
+ crypto_node = fdt_path_offset(blob, crypto);
+ if (crypto_node 0) {
+ printf(WARNING: Missing crypto node\n);
+ return;
+ }
+
+ err = fdt_setprop(blob, crypto_node, fsl,sec-era, era,
+ sizeof(era));
+ if (err 0) {
+ printf(ERROR: could not set fsl,sec-era property: %s\n,
+ fdt_strerror(err));
+ }
+}
+
void fdt_fixup_crypto_node(void *blob, int sec_rev)
{
- if (!sec_rev)
+ u8 era;
+
+ if (!sec_rev) {
fdt_del_node_and_alias(blob, crypto);
+ return;
+ }
+
+ /* Add SEC ERA information in compatible */
+ era = caam_get_era();
+ if (era) {
+ fdt_fixup_crypto_era(blob, era);
+ } else {
+ printf(WARNING: Unable to get ERA for CAAM rev: %d\n,
+ sec_rev);
+ }
}
#endif
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 296b549..6a78e65 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -2727,6 +2727,12 @@ typedef struct ccsr_sec {
#define SEC_CHANUM_MS_JRNUM_SHIFT 28
#define SEC_CHANUM_MS_DECONUM_MASK 0x0f00
#define SEC_CHANUM_MS_DECONUM_SHIFT24
+#define SEC_SECVID_MS_IPID_MASK0x
+#define SEC_SECVID_MS_IPID_SHIFT 16
+#define SEC_SECVID_MS_MAJ_REV_MASK 0xff00
+#define SEC_SECVID_MS_MAJ_REV_SHIFT8
+#define SEC_CCBVID_ERA_MASK0xff00
+#define SEC_CCBVID_ERA_SHIFT 24
#endif
typedef struct ccsr_qman {
@@ -2962,6 +2968,7 @@ struct ccsr_pman {
#endif
#define CONFIG_SYS_MDIO1_OFFSET
Re: [U-Boot] [PATCH 4/5] cm-t35: add support for user defined lcd parameters
On 01/24/13 00:36, Jeroen Hofstee wrote:
Hi Nikita,
On 01/21/2013 09:25 AM, Nikita Kiryanov wrote:
Hi Jeroen,
On 01/20/2013 11:08 PM, Jeroen Hofstee wrote:
On 12/23/2012 08:03 AM, Nikita Kiryanov wrote:
[...]
+ * Returns -1 on failure, 0 on success.
+ */
+static int parse_customlcd(char *custom_lcd_params)
+{
+char params_cpy[160];
+char *setting;
+
+strncpy(params_cpy, custom_lcd_params, 160);
I fail to understand why you want to copy this.
strtok modifies the string it operates on. The documentation for
getenv states that you must not modify the string it returns.
that seems to make sense...
+setting = strtok(params_cpy, ,);
+while (setting) {
+if (parse_setting(setting) 0)
+return -1;
+
+setting = strtok(NULL, ,);
+}
+
+/* Currently we don't support changing this via custom lcd params */
+panel_cfg.data_lines = LCD_INTERFACE_24_BIT;
+
again, if you only support 24 panels, why not drive them as such?
Can you please elaborate on this comment? I'm not entirely sure what
inconsistencies you are referring to.
You're driving only 24 bit panels, yet you want the software to drive 16 bit
panels.
Why not keep the software frame buffer at 32 bits?
+return 0;
+}
+
Is above really board specific or should it be in omap_videomodes.c or
whatever?
Well, most of it is parsing for a custom feature, so I would say this is
board specific.
I can't understand how custom settings can be board specific, unless you
mess with timer of course (but even then).
I fail to understand which timer are you talking about...
Probably, you mean the DPLLs and the clocks?
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
Joakim Tjernlund/Transmode wrote on 2013/01/24 09:58:35: Joakim Tjernlund/Transmode wrote on 2013/01/24 09:40:45: From: Joakim Tjernlund/Transmode To: Mats Kärrman mats.karr...@tritech.se, Cc: u-boot@lists.denx.de u-boot@lists.denx.de, Wolfgang Denk w...@denx.de Date: 2013/01/24 09:40 Subject: RE: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01 Mats Kärrman mats.karr...@tritech.se wrote on 2013/01/23 22:58:56: Dear Wolfgang Denk, Found that it was looping endlessly in arch/powerpc/lib/ticks.S::wait_ticks (). Reverting commit ppc: Create a stack frame for wait_ticks() made everything work again. This makes no sense to me - especially as it works on all other systems. Me neither, there is not a lot details. I do recall having other problems with wait_ticks from time to time, sometimes the TB counter(mtfbu, mftb in get_ticks) would not increment so one would just loop forever in wait_ticks. This problem had nothing to do with my patch though. Never got around to finding out what caused it, we ended up blaming unstable HW. Some ideas though: - Perhaps you have some alignment problem, try adding nop's here and there. - My patch uses r0(which is what one should use to make gdb happy) instead of r8 to stash the LR. Possibly you have some odd dependency on r0, try using r8 again. Try getting LR from stack instead of trusting r0 to be valid: - mtlrr0 /* restore link register */ + lwz r0, 20(r1) /* restore link register */ + mtlrr0 This is what one should do but as we have complete control of r0 here we don't need to. hmm, do you have WATCHDOG_RESET defined? does it use r0? I guess the above patch would make wait_ticks safer from accidental use by WATCHDOG_RESET, if it works for you, please send a proper patch to u-boot. Looking at the watchdog impl. I see it can be normal C code. This makes wait_ticks unsafe (even before my patch) as wait_ticks relies on r6 and r7 (and with my patch r0 too) to be unmodified. This MIGHT be the fix: --- a/arch/powerpc/lib/ticks.S +++ b/arch/powerpc/lib/ticks.S @@ -56,13 +56,17 @@ wait_ticks: /* Calculate end time */ addcr7, r4, r7 /* Compute end time lower */ addze r6, r3 /* and end time upper */ - + stw r7, 4(r1) /* Stash r6 and r7 */ + stw r6, 8(r1) WATCHDOG_RESET /* Trigger watchdog, if needed */ + lwz r7, 4(r1) + lwz r6, 8(r1) 1: bl get_ticks /* Get current time */ subfc r4, r4, r7 /* Subtract current time from end time */ subfe. r3, r3, r6 bge 1b /* Loop until time expired */ - mtlrr0 /* restore link register */ + lwz r0, 20(r1) /* restore link register */ + mtlrr0 addir1,r1,16 blr Not sure about the 4 and 8 offsets though Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7 V2] EXYNOS5: Add audio support for Snow
This patch set creats a new configuration file and DTS file for Snow. Driver for MAX98095 is added and support for same is incorporated in sound driver and Snow Board. Changes in V2: - Corrected multi-line comment style Rajeshwari Shinde (7): EXYNOS5: Add function to enable XXTI clock source Sound: MAX98095: Add the driver for codec Sound: Support for MAX98095 codec in driver EXYNOS5: GPIO to enable MAX98095 EXYNOS5: FDT: Add compatible strings for MAX98095 EXYNOS5: Add initial DTS file for Snow. EXYNOS5: Snow: Add a configuration file arch/arm/cpu/armv7/exynos/power.c| 11 + arch/arm/include/asm/arch-exynos/power.h | 11 + arch/arm/include/asm/arch-exynos/sound.h | 10 +- board/samsung/dts/exynos5250-snow.dts| 69 board/samsung/smdk5250/smdk5250.c| 15 + boards.cfg |1 + drivers/sound/Makefile |1 + drivers/sound/max98095.c | 550 ++ drivers/sound/max98095.h | 311 + drivers/sound/sound.c| 13 +- include/configs/exynos5250-dt.h |1 - include/configs/smdk5250.h |1 + include/configs/snow.h | 34 ++ include/fdtdec.h |1 + include/sound.h |1 + lib/fdtdec.c |1 + 16 files changed, 1027 insertions(+), 4 deletions(-) create mode 100644 board/samsung/dts/exynos5250-snow.dts create mode 100644 drivers/sound/max98095.c create mode 100644 drivers/sound/max98095.h create mode 100644 include/configs/snow.h -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7 V2] Sound: Support for MAX98095 codec in driver
This patchs adds support for MAX98095 codec in
sound driver.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- None
arch/arm/include/asm/arch-exynos/sound.h | 10 +-
drivers/sound/sound.c| 13 +++--
include/sound.h |1 +
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/sound.h
b/arch/arm/include/asm/arch-exynos/sound.h
index d1bd2f6..a216b00 100644
--- a/arch/arm/include/asm/arch-exynos/sound.h
+++ b/arch/arm/include/asm/arch-exynos/sound.h
@@ -33,6 +33,7 @@
#define I2S_RFS256
#define I2S_BFS32
+#ifdef CONFIG_SOUND_WM8994
/* I2C values */
#define AUDIO_I2C_BUS 1
#define AUDIO_I2C_REG 0x1a
@@ -40,5 +41,12 @@
/* Audio Codec */
#define AUDIO_CODECwm8994
-#define AUDIO_COMPAT 1
+#else /* CONFIG_SOUND_MAX98095 */
+/* I2C values */
+#define AUDIO_I2C_BUS 7
+#define AUDIO_I2C_REG 0x22
+
+/* Audio Codec */
+#define AUDIO_CODECmax98095
+#endif
#endif
diff --git a/drivers/sound/sound.c b/drivers/sound/sound.c
index fa8432d..a74590b 100644
--- a/drivers/sound/sound.c
+++ b/drivers/sound/sound.c
@@ -31,6 +31,7 @@
#include sound.h
#include asm/arch/sound.h
#include wm8994.h
+#include max98095.h
/* defines */
#define SOUND_400_HZ 400
@@ -143,17 +144,25 @@ static int codec_init(const void *blob, struct i2stx_info
*pi2s_tx)
#else
codectype = AUDIO_CODEC;
#endif
+#ifdef CONFIG_SOUND_WM8994
if (!strcmp(codectype, wm8994)) {
/* Check the codec type and initialise the same */
ret = wm8994_init(blob, WM8994_AIF2,
pi2s_tx-samplingrate,
(pi2s_tx-samplingrate * (pi2s_tx-rfs)),
pi2s_tx-bitspersample, pi2s_tx-channels);
+#endif
+#ifdef CONFIG_SOUND_MAX98095
+ if (!strcmp(codectype, max98095)) {
+ ret = max98095_init(blob, pi2s_tx-samplingrate,
+ (pi2s_tx-samplingrate * (pi2s_tx-rfs)),
+ pi2s_tx-bitspersample);
+#endif
} else {
- debug(%s: Unknown code type %s\n, __func__,
- codectype);
+ debug(%s: Unknown codec type %s\n, __func__, codectype);
return -1;
}
+
if (ret) {
debug(%s: Codec init failed\n, __func__);
return -1;
diff --git a/include/sound.h b/include/sound.h
index d73839d..94922f6 100644
--- a/include/sound.h
+++ b/include/sound.h
@@ -28,6 +28,7 @@
enum en_sound_codec {
CODEC_WM_8994,
CODEC_WM_8995,
+ CODEC_MAX_98095,
CODEC_MAX
};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7 V2] EXYNOS5: Add function to enable XXTI clock source
This patch adds funtion to enable XXTI clock source
required by MAX98095 codec.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Corrected multi-line comment style
arch/arm/cpu/armv7/exynos/power.c| 11 +++
arch/arm/include/asm/arch-exynos/power.h | 11 +++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index 8572cfd..8de30c1 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -105,3 +105,14 @@ void power_ps_hold_setup(void)
setbits_le32(power-ps_hold_control,
EXYNOS_PS_HOLD_CONTROL_DATA_HIGH);
}
+
+
+void power_enable_xclkout(void)
+{
+ struct exynos5_power *power =
+ (struct exynos5_power *)samsung_get_base_power();
+
+ /* use xxti for xclk out */
+ clrsetbits_le32(power-pmu_debug, PMU_DEBUG_CLKOUT_SEL_MASK,
+ PMU_DEBUG_XXTI);
+}
diff --git a/arch/arm/include/asm/arch-exynos/power.h
b/arch/arm/include/asm/arch-exynos/power.h
index 85e2cd9..09343d7 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -872,4 +872,15 @@ void set_dp_phy_ctrl(unsigned int enable);
* (e.g. power button).
*/
void power_ps_hold_setup(void);
+
+/* PMU_DEBUG bits [12:8] = 0x1000 selects XXTI clock source */
+#define PMU_DEBUG_XXTI 0x1000
+/* Mask bit[12:8] for xxti clock selection */
+#define PMU_DEBUG_CLKOUT_SEL_MASK 0x1f00
+
+/*
+ * Pmu debug is used for xclkout, enable xclkout with
+ * source as XXTI
+ */
+void power_enable_xclkout(void);
#endif
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7 V2] EXYNOS5: GPIO to enable MAX98095
This patch sets high a GPIO to enable the codec MAX98095
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- None
board/samsung/smdk5250/smdk5250.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index 12cc03e..6f2e067 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -56,6 +56,18 @@ int board_usb_vbus_init(void)
}
#endif
+#ifdef CONFIG_SOUND_MAX98095
+static void board_enable_audio_codec(void)
+{
+ struct exynos5_gpio_part1 *gpio1 = (struct exynos5_gpio_part1 *)
+ samsung_get_base_gpio_part1();
+
+ /* Enable MAX98095 Codec */
+ s5p_gpio_direction_output(gpio1-x1, 7, 1);
+ s5p_gpio_set_pull(gpio1-x1, 7, GPIO_PULL_NONE);
+}
+#endif
+
int board_init(void)
{
gd-bd-bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
@@ -65,6 +77,9 @@ int board_init(void)
#ifdef CONFIG_USB_EHCI_EXYNOS
board_usb_vbus_init();
#endif
+#ifdef CONFIG_SOUND_MAX98095
+ board_enable_audio_codec();
+#endif
return 0;
}
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7 V2] Sound: MAX98095: Add the driver for codec
This patch adds the driver for codec MAX98095 required by Snow
Board
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- None
drivers/sound/Makefile |1 +
drivers/sound/max98095.c | 550 ++
drivers/sound/max98095.h | 311 ++
3 files changed, 862 insertions(+), 0 deletions(-)
create mode 100644 drivers/sound/max98095.c
create mode 100644 drivers/sound/max98095.h
diff --git a/drivers/sound/Makefile b/drivers/sound/Makefile
index 8fdffb1..1987ca1 100644
--- a/drivers/sound/Makefile
+++ b/drivers/sound/Makefile
@@ -28,6 +28,7 @@ LIB := $(obj)libsound.o
COBJS-$(CONFIG_SOUND) += sound.o
COBJS-$(CONFIG_I2S)+= samsung-i2s.o
COBJS-$(CONFIG_SOUND_WM8994) += wm8994.o
+COBJS-$(CONFIG_SOUND_MAX98095) += max98095.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/sound/max98095.c b/drivers/sound/max98095.c
new file mode 100644
index 000..0beee56
--- /dev/null
+++ b/drivers/sound/max98095.c
@@ -0,0 +1,550 @@
+/*
+ * max98095.c -- MAX98095 ALSA SoC Audio driver
+ *
+ * Copyright 2011 Maxim Integrated Products
+ *
+ * Modified for uboot by R. Chandrasekar (rcse...@samsung.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include asm/arch/clk.h
+#include asm/arch/cpu.h
+#include asm/arch/power.h
+#include asm/gpio.h
+#include asm/io.h
+#include common.h
+#include div64.h
+#include fdtdec.h
+#include i2c.h
+#include sound.h
+#include i2s.h
+#include max98095.h
+
+enum max98095_type {
+ MAX98095,
+};
+
+struct max98095_priv {
+ enum max98095_type devtype;
+ unsigned int sysclk;
+ unsigned int rate;
+ unsigned int fmt;
+};
+
+static struct sound_codec_info g_codec_info;
+struct max98095_priv g_max98095_info;
+unsigned int g_max98095_i2c_dev_addr;
+
+/* Index 0 is reserved. */
+int rate_table[] = {0, 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000,
+ 88200, 96000};
+
+/*
+ * Writes value to a device register through i2c
+ *
+ * @param reg reg number to be write
+ * @param data data to be writen to the above registor
+ *
+ * @return int value 1 for change, 0 for no change or negative error code.
+ */
+static int max98095_i2c_write(unsigned int reg, unsigned char data)
+{
+ debug(%s: Write Addr : 0x%02X, Data : 0x%02X\n,
+ __func__, reg, data);
+ return i2c_write(g_max98095_i2c_dev_addr, reg, 1, data, 1);
+}
+
+/*
+ * Read a value from a device register through i2c
+ *
+ * @param reg reg number to be read
+ * @param data address of read data to be stored
+ *
+ * @return int value 0 for success, -1 in case of error.
+ */
+static unsigned int max98095_i2c_read(unsigned int reg, unsigned char *data)
+{
+ int ret;
+
+ ret = i2c_read(g_max98095_i2c_dev_addr, reg, 1, data, 1);
+ if (ret != 0) {
+ debug(%s: Error while reading register %#04x\n,
+ __func__, reg);
+ return -1;
+ }
+
+ return 0;
+}
+
+/*
+ * update device register bits through i2c
+ *
+ * @param reg codec register
+ * @param mask register mask
+ * @param valuenew value
+ *
+ * @return int value 0 for success, non-zero error code.
+ */
+static int max98095_update_bits(unsigned int reg, unsigned char mask,
+ unsigned char value)
+{
+ int change, ret = 0;
+ unsigned char old, new;
+
+ if (max98095_i2c_read(reg, old) != 0)
+ return -1;
+ new = (old ~mask) | (value mask);
+ change = (old != new) ? 1 : 0;
+ if (change)
+ ret = max98095_i2c_write(reg, new);
+ if (ret 0)
+ return ret;
+
+ return change;
+}
+
+/*
+ * codec mclk clock divider coefficients based on sampling rate
+ *
+ * @param rate sampling rate
+ * @param value address of indexvalue to be stored
+ *
+ * @return 0 for success or negative error code.
+ */
+static int rate_value(int rate, u8 *value)
+{
+ int i;
+
+ for (i = 1; i ARRAY_SIZE(rate_table); i++) {
+ if (rate_table[i] = rate) {
+ *value = i;
+ return 0;
+ }
+ }
+ *value = 1;
+
+ return -1;
+}
+
+/*
+ * Sets hw params for max98095
+ *
+ * @param max98095 max98095 information pointer
+ * @param rate Sampling rate
+ * @param bits_per_sample Bits per sample
+ *
+ * @return -1 for error and 0 Success.
+ */
+static int max98095_hw_params(struct max98095_priv *max98095,
+ unsigned int rate, unsigned int bits_per_sample)
+{
+ u8 regval;
+ int error;
+
+ switch (bits_per_sample) {
+ case 16:
+ error = max98095_update_bits(M98095_034_DAI2_FORMAT,
+ M98095_DAI_WS, 0);
+
[U-Boot] [PATCH 5/7 V2] EXYNOS5: FDT: Add compatible strings for MAX98095
Add required compatible information for MAX98095 codec
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- None
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index f77d195..e76cdc1 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -79,6 +79,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
COMPAT_SAMSUNG_EXYNOS_USB_PHY, /* Exynos phy controller for usb2.0 */
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
+ COMPAT_MAXIM_98095_CODEC, /* MAX98095 Codec */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 16921e1..a5f770f 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -54,6 +54,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS_EHCI, samsung,exynos-ehci),
COMPAT(SAMSUNG_EXYNOS_USB_PHY, samsung,exynos-usb-phy),
COMPAT(MAXIM_MAX77686_PMIC, maxim,max77686_pmic),
+ COMPAT(MAXIM_98095_CODEC, maxim,max98095-codec),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7 V2] EXYNOS5: Add initial DTS file for Snow.
This patch adds the DTS file for Snow Board.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- None
board/samsung/dts/exynos5250-snow.dts | 69 +
1 files changed, 69 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/dts/exynos5250-snow.dts
diff --git a/board/samsung/dts/exynos5250-snow.dts
b/board/samsung/dts/exynos5250-snow.dts
new file mode 100644
index 000..af788a6
--- /dev/null
+++ b/board/samsung/dts/exynos5250-snow.dts
@@ -0,0 +1,69 @@
+/*
+ * SAMSUNG SMDK5250 board device tree source
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+/include/ ARCH_CPU_DTS
+
+/ {
+ model = Google Snow;
+ compatible = google,snow, samsung,exynos5250;
+
+ aliases {
+ i2c0 = /i2c@12c6;
+ i2c1 = /i2c@12c7;
+ i2c2 = /i2c@12c8;
+ i2c3 = /i2c@12c9;
+ i2c4 = /i2c@12ca;
+ i2c5 = /i2c@12cb;
+ i2c6 = /i2c@12cc;
+ i2c7 = /i2c@12cd;
+ spi0 = /spi@12d2;
+ spi1 = /spi@12d3;
+ spi2 = /spi@12d4;
+ spi3 = /spi@131a;
+ spi4 = /spi@131b;
+ };
+
+ sromc@1225 {
+ bank = 1;
+ srom-timing = 1 9 12 1 6 1 1;
+ width = 2;
+ lan@500 {
+ compatible = smsc,lan9215, smsc,lan;
+ reg = 0x500 0x100;
+ phy-mode = mii;
+ };
+ };
+
+ sound@12d6 {
+ samsung,i2s-epll-clock-frequency = 19200;
+ samsung,i2s-sampling-rate = 48000;
+ samsung,i2s-bits-per-sample = 16;
+ samsung,i2s-channels = 2;
+ samsung,i2s-lr-clk-framesize = 256;
+ samsung,i2s-bit-clk-framesize = 32;
+ samsung,codec-type = max98095;
+ };
+
+ i2c@12cd {
+ soundcodec@22 {
+ reg = 0x22;
+ compatible = maxim,max98095-codec;
+ };
+ };
+
+ i2c@12c6 {
+ pmic@9 {
+ reg = 0x9;
+ compatible = maxim,max77686_pmic;
+ };
+ };
+};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7 V2] EXYNOS5: Snow: Add a configuration file
This patch adds the configuration file for Snow Board and defines the same in boards.cfg. The Audio codec required for SMDK5250 and Snow are different hence they are defined in the corresponding configuration files. Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- Changes in V2: - None boards.cfg |1 + include/configs/exynos5250-dt.h |1 - include/configs/smdk5250.h |1 + include/configs/snow.h | 34 ++ 4 files changed, 36 insertions(+), 1 deletions(-) create mode 100644 include/configs/snow.h diff --git a/boards.cfg b/boards.cfg index e4b0d44..f247b03 100644 --- a/boards.cfg +++ b/boards.cfg @@ -283,6 +283,7 @@ s5p_goni arm armv7 goni samsung smdkc100 arm armv7 smdkc100 samsungs5pc1xx origen arm armv7 origen samsungexynos s5pc210_universalarm armv7 universal_c210 samsungexynos +snowarm armv7 smdk5250 samsungexynos smdk5250arm armv7 smdk5250 samsungexynos smdkv310arm armv7 smdkv310 samsungexynos tratsarm armv7 trats samsungexynos diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index a01fb96..7b9c393 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -297,7 +297,6 @@ #ifdef CONFIG_CMD_SOUND #define CONFIG_SOUND #define CONFIG_I2S -#define CONFIG_SOUND_WM8994 #endif /* Enable devicetree support */ diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 81f83a8..b23b5bc 100644 --- a/include/configs/smdk5250.h +++ b/include/configs/smdk5250.h @@ -30,4 +30,5 @@ #undef CONFIG_DEFAULT_DEVICE_TREE #define CONFIG_DEFAULT_DEVICE_TREE exynos5250-smdk5250 +#define CONFIG_SOUND_WM8994 #endif /* __CONFIG_SMDK_H */ diff --git a/include/configs/snow.h b/include/configs/snow.h new file mode 100644 index 000..be38635 --- /dev/null +++ b/include/configs/snow.h @@ -0,0 +1,34 @@ +/* + * Copyright (C) 2012 Samsung Electronics + * + * Configuration settings for the SAMSUNG SMDK5250 board. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef __CONFIG_SMDK_H +#define __CONFIG_SMDK_H + +#include configs/exynos5250-dt.h + +#undef CONFIG_DEFAULT_DEVICE_TREE +#define CONFIG_DEFAULT_DEVICE_TREE exynos5250-snow + +#define CONFIG_SOUND_MAX98095 +#endif /* __CONFIG_SMDK_H */ -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] drivers/net/designware, do an explicit memory access instead of implicit, re-written assignments to use readl() and writel(), all of this as preperation for making the driver
Hi Vipin, On Wed, 23 Jan 2013 15:46:31 +0530, Vipin Kumar vipin.ku...@st.com wrote: My first feeling is that the descriptors are allocated as Normal Cachabale memory and it would not help to access them using readl/writel ... And no, we don't need to allocate them non-cacheable, although in this case we need to use cache flush and invalidate calls. I would suggest doing so rather than allocating the descriptors none cacheable, because using non-cacheable memory makes the dependency between the driver and cache codes implicit (and thus more prone to improperly thought out changes in either code) and the memory usage more complex, while explicit cache operations make the relationship explicit. Yes, got it. Thanks Albert Frank, so in that case rather changing the code to use readl/writel, cache flush and invalidate operations need to be performed at appropriate places Vipin I believe patch 2/2 adds explicit cache ops, though I haven't read it in detail and thus don't know if everything needed is present and ok. Amicalement, Albert. Hi Vipin and Albert, Sorry, I have to clarify here a bit more. The descriptors are 16 bytes in length and a cache line is in most architectures more than 16 bytes in length (in our case either 32 or 64). This means that cached accesses is not an option for these descriptors. Background, two adjacent descriptors as be on one cache line may be owned by different entities (host cpu / network ip). Explicit cache calls that we are added in patch 2/2 are meant for payload of the package. And these are made cache line aligned with patch 1/2. Unfortunately we can't align the descriptors on cache line boundaries due to hardware limitations (for architectures with cache line longer than 16 bytes) ! With kind regards, greetings, Frank. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Want to study U-Boot code
Hi, List Is there a book or web document to help start to understand how U-Boot works? Thanks! -- woody I can't go back to yesterday - because I was a different person then. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v2] console: USB: KBD: Fix incorrect autoboot timeout
On Thu, 2013-01-24 at 03:33 +0800, Wolfgang Denk wrote:
Dear Jim Lin,
In message 1358937511-32664-1-git-send-email-ji...@nvidia.com you wrote:
Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if
CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in
configuration file and when tstc() function for checking key pressed
takes longer time than 10 ms (e.g., 50 ms) to finish.
Thanks. One minor nitpick...
+ /* delay 1000 ms */
+ ts = get_timer(0);
+ do {
if (tstc()) { /* we got a key press */
abort = 1; /* don't auto boot */
bootdelay = 0; /* no more delay*/
@@ -263,8 +263,7 @@ int abortboot(int bootdelay)
# endif
break;
}
- udelay(1);
- }
+ } while (!abort get_timer(ts) 1000);
I recommend to keep a short udelay() [say, an udelay(1000)] in the
loop, as this will make sure that watchdog still gets triggered on
systems that need this.
I will keep
udelay(1);
for safety in next patch.
Thanks.
-- nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot timeout
Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if
CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in
configuration file and when tstc() function for checking key pressed
takes longer time than 10 ms (e.g., 50 ms) to finish.
Signed-off-by: Jim Lin ji...@nvidia.com
---
Changes in v2:
- use do-while and get_timer to count timeout.
Changes in v3:
- revert original udelay(1); for safety.
common/main.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/common/main.c b/common/main.c
index b145f85..dcd2a42 100644
--- a/common/main.c
+++ b/common/main.c
@@ -225,6 +225,7 @@ static inline
int abortboot(int bootdelay)
{
int abort = 0;
+ unsigned long ts;
#ifdef CONFIG_MENUPROMPT
printf(CONFIG_MENUPROMPT);
@@ -248,11 +249,10 @@ int abortboot(int bootdelay)
#endif
while ((bootdelay 0) (!abort)) {
- int i;
-
--bootdelay;
- /* delay 100 * 10ms */
- for (i=0; !abort i100; ++i) {
+ /* delay 1000 ms */
+ ts = get_timer(0);
+ do {
if (tstc()) { /* we got a key press */
abort = 1; /* don't auto boot */
bootdelay = 0; /* no more delay*/
@@ -264,7 +264,7 @@ int abortboot(int bootdelay)
break;
}
udelay(1);
- }
+ } while (!abort get_timer(ts) 1000);
printf(\b\b\b%2d , bootdelay);
}
--
1.7.3
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] usb:composite: USB Mass Storage - storage_common.c from Linux kernel
Dear Piotr Wilczek, From: Lukasz Majewski l.majew...@samsung.com The storage_common.c source file from v2.6.36 Linux kernel. Is it not possibly to port anything more recent? If not, so be it. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] usb:composite: USB Mass Storage - f_mass_storage.c from Linux kernel
Dear Piotr Wilczek, The f_mass_storage.c source file from v2.6.36 Linux kernel. commit 8876f5e7d3b2a320777dd4f6f5301d474c97a06c Author: Michal Nazarewicz m.nazarew...@samsung.com Date: Mon Jun 21 13:57:09 2010 +0200 USB: gadget: f_mass_storage: added eject callback Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Piotr Wilczek p.wilc...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Why is there so much code that's crudely commented out, like in the synchronize_cache function? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] usb:gadget: USB Mass Storage Gadget support
Dear Piotr Wilczek,
From: Lukasz Majewski l.majew...@samsung.com
This patch adds the USB Mass Storage Gadget to u-boot
New command called ums is implemented to provide access
to on-device embedded persistent memory.
USB Mass Storage is supposed to work on top of the USB
Gadget framework
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Marek Vasut marek.va...@gmail.com
---
common/Makefile |1 +
common/cmd_usb_mass_storage.c | 85
+ drivers/usb/gadget/g_dnl.c|
6 +++
include/usb_mass_storage.h| 59
4 files changed, 151 insertions(+)
create mode 100644 common/cmd_usb_mass_storage.c
create mode 100644 include/usb_mass_storage.h
diff --git a/common/Makefile b/common/Makefile
index 54fcc81..8ec95d2 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -174,6 +174,7 @@ COBJS-y += cmd_usb.o
COBJS-y += usb.o usb_hub.o
COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
endif
+COBJS-$(CONFIG_CMD_USB_MASS_STORAGE) += cmd_usb_mass_storage.o
COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
COBJS-$(CONFIG_CMD_SPL) += cmd_spl.o
diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
new file mode 100644
index 000..bc5b239
--- /dev/null
+++ b/common/cmd_usb_mass_storage.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ * Lukasz Majewski l.majew...@samsung.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 errno.h
+#include common.h
+#include command.h
+#include g_dnl.h
+#include usb_mass_storage.h
+
+int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
+int argc, char * const argv[])
+{
+ char *ep;
+ unsigned int dev_num = 0, offset = 0, part_size = 0;
+ int rc;
+
+ struct ums_board_info *ums_info;
+ static char *s = ums;
+
+ if (argc 2) {
+ printf(usage: ums dev - e.g. ums 0\n);
+ return 0;
+ }
+
+ dev_num = (int)simple_strtoul(argv[1], ep, 16);
+
+ if (dev_num) {
+ puts(\nSet eMMC device to 0! - e.g. ums 0\n);
+ goto fail;
+ }
+
+ board_usb_init();
+ ums_info = board_ums_init(dev_num, offset, part_size);
+
+ if (!ums_info) {
+ printf(MMC: %d - NOT available\n, dev_num);
+ goto fail;
+ }
+ rc = fsg_init(ums_info);
+ if (rc) {
+ printf(cmd ums: fsg_init failed\n);
+ goto fail;
+ }
+
+ g_dnl_register(s);
+
+ while (1) {
+ /* Handle control-c and timeouts */
+ if (ctrlc()) {
+ printf(The remote end did not respond in time.\n);
+ goto exit;
+ }
+ usb_gadget_handle_interrupts();
+ /* Check if USB cable has been detached */
+ if (fsg_main_thread(NULL) == EIO)
+ goto exit;
+ }
+exit:
+ g_dnl_unregister();
+
+fail:
+ return -1;
+}
+
+U_BOOT_CMD(ums, CONFIG_SYS_MAXARGS, 1, do_usb_mass_storage,
+ Use the UMS [User Mass Storage],
+ ums - User Mass Storage Gadget
+);
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index a5a4c1f..cc3f344 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -31,6 +31,7 @@
#include gadget_chips.h
#include composite.c
+#include f_mass_storage.c
/*
* One needs to define the following:
@@ -104,6 +105,8 @@ static int g_dnl_do_config(struct usb_configuration *c)
printf(GADGET DRIVER: %s\n, s);
if (!strcmp(s, usb_dnl_dfu))
ret = dfu_add(c);
+ else if (!strcmp(s, usb_dnl_ums))
+ ret = fsg_add(c);
return ret;
}
@@ -188,6 +191,9 @@ int g_dnl_register(const char *type)
if (!strcmp(type, dfu)) {
strcpy(name, shortname);
strcat(name, type);
+ } else if (!strcmp(type, ums)) {
+ strcpy(name, shortname);
+ strcat(name, type);
} else {
printf(%s: unknown command:
[U-Boot] [PATCH 0/1] Add support for new SomIQ-AM37 system on module
From: Maxim Podberezny lisar...@gmail.com This patch add support for a SOM SomIQ-AM37 based on TI AM37/DM37 precessors. SomIQ-AM37 design is based on Beagleboard-xM schematic Maxim Podberezny (1): Add support for new SomIQ-AM37 system on module from MENTOREL Ltd SomIQ-AM37 is based on TI AM37/DM37 processors arch/arm/include/asm/mach-types.h | 13 + board/mentorel/somiq_am37/Makefile | 44 +++ board/mentorel/somiq_am37/somiq_am37.c | 281 +++ board/mentorel/somiq_am37/somiq_am37.h | 471 boards.cfg |2 + include/configs/somiq_am37.h | 415 6 files changed, 1226 insertions(+), 0 deletions(-) create mode 100644 board/mentorel/somiq_am37/Makefile create mode 100644 board/mentorel/somiq_am37/somiq_am37.c create mode 100644 board/mentorel/somiq_am37/somiq_am37.h create mode 100644 include/configs/somiq_am37.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] Add support for new SomIQ-AM37 system on module from MENTOREL Ltd SomIQ-AM37 is based on TI AM37/DM37 processors
From: Maxim Podberezny lisar...@gmail.com Signed-off-by: Maxim Podberezny lisar...@gmail.com --- :100644 100644 a676b6d... 817e0e6... M arch/arm/include/asm/mach-types.h :00 100644 000... 018142a... A board/mentorel/somiq_am37/Makefile :00 100644 000... 3a974bd... A board/mentorel/somiq_am37/somiq_am37.c :00 100644 000... cd48a43... A board/mentorel/somiq_am37/somiq_am37.h :100644 100644 e4b0d44... c8cc252... M boards.cfg :00 100644 000... 6e07c0b... A include/configs/somiq_am37.h arch/arm/include/asm/mach-types.h | 13 + board/mentorel/somiq_am37/Makefile | 44 +++ board/mentorel/somiq_am37/somiq_am37.c | 281 +++ board/mentorel/somiq_am37/somiq_am37.h | 471 boards.cfg |2 + include/configs/somiq_am37.h | 415 6 files changed, 1226 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h index a676b6d..817e0e6 100644 --- a/arch/arm/include/asm/mach-types.h +++ b/arch/arm/include/asm/mach-types.h @@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_OMAP5_SEVM 3777 #define MACH_TYPE_ARMADILLO_800EVA 3863 #define MACH_TYPE_KZM9G4140 +#define MACH_TYPE_SOMIQ_AM37 4196 #ifdef CONFIG_ARCH_EBSA110 # ifdef machine_arch_type @@ -14248,6 +14249,18 @@ extern unsigned int __machine_arch_type; # define machine_is_kzm9g()(0) #endif +#ifdef CONFIG_MACH_SOMIQ_AM37 +# ifdef machine_arch_type +# undef machine_arch_type +# define machine_arch_type __machine_arch_type +# else +# define machine_arch_type MACH_TYPE_SOMIQ_AM37 +# endif +# define machine_is_somiq_am37() (machine_arch_type == MACH_TYPE_SOMIQ_AM37) +#else +# define machine_is_somiq_am37() (0) +#endif + /* * These have not yet been registered */ diff --git a/board/mentorel/somiq_am37/Makefile b/board/mentorel/somiq_am37/Makefile new file mode 100644 index 000..018142a --- /dev/null +++ b/board/mentorel/somiq_am37/Makefile @@ -0,0 +1,44 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS-y:= $(BOARD).o + +COBJS := $(sort $(COBJS-y)) +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/mentorel/somiq_am37/somiq_am37.c b/board/mentorel/somiq_am37/somiq_am37.c new file mode 100644 index 000..3a974bd --- /dev/null +++ b/board/mentorel/somiq_am37/somiq_am37.c @@ -0,0 +1,281 @@ +/* + * (C) Copyright 2013 + * MENTOREL Limited, www.mentorel.com + * + * Derived from Beagle Board and 3430 SDP code by + * Richard Woodruff r-woodru...@ti.com + * Syed Mohammed Khasim kha...@ti.com + * + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ +#include common.h +#include twl4030.h +#include linux/mtd/nand.h +#include asm/io.h +#include asm/arch/mmc_host_def.h +#include asm/arch/mux.h +#include asm/arch/mem.h +#include
Re: [U-Boot] [PATCH v3] sandbox: fix compiler warning
Hi Allen, On Wed, 23 Jan 2013 13:05:27 -0800, Allen Martin amar...@nvidia.com wrote: Shouldn't the function be given '__attribute__((noreturn))' rather than adding a non-executed 'return 0' to it? The function in question is sandbox main(), and it can return if there was an error prior to calling board_init_f(). Here's the whole function for context: int main(int argc, char *argv[]) [...] Makes sense, thanks. -Allen Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
Joakim Tjernlund/Transmode wrote on 2013/01/24 09:21: Looking at the watchdog impl. I see it can be normal C code. This makes wait_ticks unsafe (even before my patch) as wait_ticks relies on r6 and r7 (and with my patch r0 too) to be unmodified. Yes! I can see in the assembly from my watchdog_reset() (arch/powerpc/cpu/mpc5125/cpu.c) that it does not touch r7 and r8 but indeed r0 -- for storing lr in fact so the endless loop is explained! Many thanks! I'll prepare a patch as soon as I've got one tested. BR // Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
Mats Kärrman mats.karr...@tritech.se wrote on 2013/01/24 14:31:02: Joakim Tjernlund/Transmode wrote on 2013/01/24 09:21: Looking at the watchdog impl. I see it can be normal C code. This makes wait_ticks unsafe (even before my patch) as wait_ticks relies on r6 and r7 (and with my patch r0 too) to be unmodified. Yes! I can see in the assembly from my watchdog_reset() (arch/powerpc/cpu/mpc5125/ cpu.c) that it does not touch r7 and r8 but indeed r0 -- for storing lr in fact so the endless loop is explained! Many thanks! I'll prepare a patch as soon as I've got one tested. Great, just one thing though. I think the 4 resp.8 stack offsets should be 8 resp. 12 instead. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] board: add support for amcore board
Dear Angelo Dureghello,
In message 20130123145107.GA5565@sion.sysam you wrote:
Add support for Sysam AMCORE mcf5307 (coldfire) based board.
Signed-off-by: Angelo Dureghello sysa...@gmail.com
Cc: Jason Jin jason@freescale.com
...
diff --git a/MAINTAINERS b/MAINTAINERS
index 28c052d..1d27cb7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1137,6 +1137,10 @@ Wolfgang Wegner w.weg...@astro-kom.de
astro_mcf5373l MCF5373L
+Angelo Dureghello sysa...@gmail.com
+
+ amcore mcf5307
Please keep the list sorted...
+
+ for (p = pstart; p pend; p++) {
+ if (*p != 0x) {
+ printf(SDRAM test fails at: %08x\n, (uint) p);
+ return 1;
+ }
Incorrect indentation.
+/*
+ * BOOTP options
+ */
+#undef CONFIG_BOOTP_BOOTFILESIZE
+#undef CONFIG_BOOTP_BOOTPATH
+#undef CONFIG_BOOTP_GATEWAY
+#undef CONFIG_BOOTP_HOSTNAME
Please don't undef what is not defined anyway. Please fix globally.
+#define CONFIG_SYS_SDRAM_BASE0x
+#define CONFIG_SYS_SDRAM_SIZE16 /* in MB */
NAK. CONFIG_SYS_SDRAM_SIZE is always and everywhere in bytes...
+/* reserve 128-4KB */
+#define CONFIG_SYS_MONITOR_BASE (CONFIG_SYS_FLASH_BASE + 0x400)
+#define CONFIG_SYS_MONITOR_LEN ((128-4)*1024)
Are you sure this is sufficient?
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
There's a way out of any cage.
-- Captain Christopher Pike, The Menagerie (The Cage),
stardate unknown.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] powerpc/lib: unsafe register handling in wait_ticks
Hi, If watchdog is enabled, the arch/powerpc/lib/ticks.S::wait_ticks() function calls the function specified by the WATCHDOG_RESET macro. The wait_ticks function depends on the registers r0, r6 and r7 being preserved however that is not guaranteed if the reset function is a C function. The following patch changes to using r14+r15 instead of r6+r7 and saves all necessary registers on the stack. As I'm quite fresh to PowerPC assembly language I would appreciate any feedback on the implementation. On a side note, one could wonder why this function is not written in C language to start with. Best regards, Mats Kärrman --- a/arch/powerpc/lib/ticks.S +++ b/arch/powerpc/lib/ticks.S @@ -50,19 +50,24 @@ wait_ticks: stwur1, -16(r1) mflrr0 /* save link register */ stw r0, 20(r1) /* Use r0 or GDB will be unhappy */ - mr r7, r3 /* save tick count */ + stw r14, 12(r1) /* save used registers */ + stw r15, 8(r1) + mr r14, r3 /* save tick count */ bl get_ticks /* Get start time */ /* Calculate end time */ - addcr7, r4, r7 /* Compute end time lower */ - addze r6, r3 /* and end time upper */ + addcr14, r4, r14/* Compute end time lower */ + addze r15, r3 /* and end time upper */ WATCHDOG_RESET /* Trigger watchdog, if needed */ 1: bl get_ticks /* Get current time */ - subfc r4, r4, r7 /* Subtract current time from end time */ - subfe. r3, r3, r6 + subfc r4, r4, r14 /* Subtract current time from end time */ + subfe. r3, r3, r15 bge 1b /* Loop until time expired */ - mtlrr0 /* restore link register */ + lwz r15, 8(r1) /* restore saved registers */ + lwz r14, 12(r1) + lwz r0, 20(r1) addir1,r1,16 + mtlrr0 blr ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] board: add support for amcore board
Dear Wolfgang, thanks for the review, will fix all points. +/* reserve 128-4KB */ +#define CONFIG_SYS_MONITOR_BASE(CONFIG_SYS_FLASH_BASE + 0x400) +#define CONFIG_SYS_MONITOR_LEN ((128-4)*1024) Are you sure this is sufficient? For my board/case actually seems to be more than enough. I can still change this in the future. Best Regards, Angelo Dureghello ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] MIPS: start.S: save reused arguments earlier in relocate_code
Save the reused parameters at the beginning of the 'relocate_code' function. This makes the function a bit more readable. Signed-off-by: Gabor Juhos juh...@openwrt.org Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com --- arch/mips/cpu/mips32/start.S |5 +++-- arch/mips/cpu/mips64/start.S |5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/mips/cpu/mips32/start.S b/arch/mips/cpu/mips32/start.S index 88e8036..64a606f 100644 --- a/arch/mips/cpu/mips32/start.S +++ b/arch/mips/cpu/mips32/start.S @@ -279,11 +279,13 @@ reset: relocate_code: movesp, a0 # set new stack pointer + moves0, a1 # save gd in s0 + moves2, a2 # save destination address in s2 + li t0, CONFIG_SYS_MONITOR_BASE la t3, in_ram lw t2, -12(t3) # t2 -- uboot_end_data movet1, a2 - moves2, a2 # s2 -- destination address /* * Fix $gp: @@ -304,7 +306,6 @@ relocate_code: /* * Save destination address and size for later usage in flush_cache() */ - moves0, a1 # save gd in s0 movea0, t1 # a0 -- destination addr sub a1, t2, t0 # a1 -- size diff --git a/arch/mips/cpu/mips64/start.S b/arch/mips/cpu/mips64/start.S index d3c5cea..3c0f1c3 100644 --- a/arch/mips/cpu/mips64/start.S +++ b/arch/mips/cpu/mips64/start.S @@ -158,11 +158,13 @@ reset: relocate_code: movesp, a0 # set new stack pointer + moves0, a1 # save gd in s0 + moves2, a2 # save destination address in s2 + dli t0, CONFIG_SYS_MONITOR_BASE dla t3, in_ram ld t2, -24(t3) # t2 -- uboot_end_data movet1, a2 - moves2, a2 # s2 -- destination address /* * Fix $gp: @@ -183,7 +185,6 @@ relocate_code: /* * Save destination address and size for dlater usage in flush_cache() */ - moves0, a1 # save gd in s0 movea0, t1 # a0 -- destination addr dsuba1, t2, t0 # a1 -- size -- 1.7.10 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] MIPS: start.S: relocate_code fixes and cleanups
This series contain various patches for the relocate_code function. The first patch fixes a minor issue in the relocation code, and the subsequent patches are doing some optimalization and cleanup. Gabor Juhos (5): MIPS: start.S: fix boundary check in relocate_code MIPS: start.S: set sp register directly MIPS: start.S: save reused arguments earlier in relocate_code MIPS: start.S: simplify relocation offset calculation MIPS: start.S: don't save flush_cache parameters in advance arch/mips/cpu/mips32/start.S | 34 ++ arch/mips/cpu/mips64/start.S | 34 ++ arch/mips/cpu/xburst/start.S |2 +- 3 files changed, 21 insertions(+), 49 deletions(-) -- 1.7.10 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] MIPS: start.S: set sp register directly
The current code uses two instructions to load the stack pointer into the 'sp' register. This results in the following assembly code: 468: 3c088040lui t0,0x8040 46c: 251daddiu sp,t0,0 The first instuction loads the stack pointer into the 't0' register then the value of the 'sp' register is computed by adding zero to the value of the 't0' register. The same issue present on the 64-bit version as well: 56c: 3c0c8040lui t0,0x8040 570: 659ddaddiu sp,t0,0 Change the code to load the stack pointer directly into the 'sp' register. The generated code is functionally equivalent to the previous version but it is simpler. 32-bit: 468: 3c1d8040lui sp,0x8040 64-bit: 56c: 3c1d8040lui sp,0x8040 Signed-off-by: Gabor Juhos juh...@openwrt.org Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com --- arch/mips/cpu/mips32/start.S |3 +-- arch/mips/cpu/mips64/start.S |3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/mips/cpu/mips32/start.S b/arch/mips/cpu/mips32/start.S index a4fc1ec..88e8036 100644 --- a/arch/mips/cpu/mips32/start.S +++ b/arch/mips/cpu/mips32/start.S @@ -258,8 +258,7 @@ reset: #endif /* Set up temporary stack */ - li t0, CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_INIT_SP_OFFSET - la sp, 0(t0) + li sp, CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_INIT_SP_OFFSET la t9, board_init_f jr t9 diff --git a/arch/mips/cpu/mips64/start.S b/arch/mips/cpu/mips64/start.S index aed82e1..d3c5cea 100644 --- a/arch/mips/cpu/mips64/start.S +++ b/arch/mips/cpu/mips64/start.S @@ -137,8 +137,7 @@ reset: #endif /* Set up temporary stack */ - dli t0, CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_INIT_SP_OFFSET - dla sp, 0(t0) + dli sp, CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_INIT_SP_OFFSET dla t9, board_init_f jr t9 -- 1.7.10 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] MIPS: start.S: simplify relocation offset calculation
The current code uses four instructions and a temporary register to calculate the relocation offset and to adjust the gp register. The relocation offset can be calculated directly from the CONFIG_SYS_MONITOR_BASE constant and from the destination address. The resulting offset can be used to adjust the gp pointer. This approach makes the code a bit simpler because it needs two instructions only. Signed-off-by: Gabor Juhos juh...@openwrt.org Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com --- arch/mips/cpu/mips32/start.S | 12 +++- arch/mips/cpu/mips64/start.S | 12 +++- 2 files changed, 6 insertions(+), 18 deletions(-) diff --git a/arch/mips/cpu/mips32/start.S b/arch/mips/cpu/mips32/start.S index 64a606f..d67dafa 100644 --- a/arch/mips/cpu/mips32/start.S +++ b/arch/mips/cpu/mips32/start.S @@ -283,19 +283,13 @@ relocate_code: moves2, a2 # save destination address in s2 li t0, CONFIG_SYS_MONITOR_BASE + sub s1, s2, t0 # s1 -- relocation offset + la t3, in_ram lw t2, -12(t3) # t2 -- uboot_end_data movet1, a2 - /* -* Fix $gp: -* -* New $gp = (Old $gp - CONFIG_SYS_MONITOR_BASE) + Destination Address -*/ - movet6, gp - sub gp, CONFIG_SYS_MONITOR_BASE - add gp, a2 # gp now adjusted - sub s1, gp, t6 # s1 -- relocation offset + add gp, s1 # adjust gp /* * t0 = source address diff --git a/arch/mips/cpu/mips64/start.S b/arch/mips/cpu/mips64/start.S index 3c0f1c3..d213c8e 100644 --- a/arch/mips/cpu/mips64/start.S +++ b/arch/mips/cpu/mips64/start.S @@ -162,19 +162,13 @@ relocate_code: moves2, a2 # save destination address in s2 dli t0, CONFIG_SYS_MONITOR_BASE + dsubs1, s2, t0 # s1 -- relocation offset + dla t3, in_ram ld t2, -24(t3) # t2 -- uboot_end_data movet1, a2 - /* -* Fix $gp: -* -* New $gp = (Old $gp - CONFIG_SYS_MONITOR_BASE) + Destination Address -*/ - movet8, gp - dsubgp, CONFIG_SYS_MONITOR_BASE - daddgp, a2 # gp now adjusted - dsubs1, gp, t8 # s1 -- relocation offset + daddgp, s1 # adjust gp /* * t0 = source address -- 1.7.10 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] MIPS: start.S: fix boundary check in relocate_code
The loop code copies more data with one than necessary due to the 'ble' instuction. Use the 'blt' instruction instead to fix that. Due to the lack of suitable hardware the Xburst specific code is compile tested only. However the change is quite obvious. Signed-off-by: Gabor Juhos juh...@openwrt.org Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com --- arch/mips/cpu/mips32/start.S |2 +- arch/mips/cpu/mips64/start.S |2 +- arch/mips/cpu/xburst/start.S |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/mips/cpu/mips32/start.S b/arch/mips/cpu/mips32/start.S index 22a9c1b..a4fc1ec 100644 --- a/arch/mips/cpu/mips32/start.S +++ b/arch/mips/cpu/mips32/start.S @@ -313,7 +313,7 @@ relocate_code: lw t3, 0(t0) sw t3, 0(t1) addut0, 4 - ble t0, t2, 1b + blt t0, t2, 1b addu t1, 4 /* If caches were enabled, we would have to flush them here. */ diff --git a/arch/mips/cpu/mips64/start.S b/arch/mips/cpu/mips64/start.S index bc7e41e..aed82e1 100644 --- a/arch/mips/cpu/mips64/start.S +++ b/arch/mips/cpu/mips64/start.S @@ -192,7 +192,7 @@ relocate_code: lw t3, 0(t0) sw t3, 0(t1) daddu t0, 4 - ble t0, t2, 1b + blt t0, t2, 1b daddu t1, 4 /* If caches were enabled, we would have to flush them here. */ diff --git a/arch/mips/cpu/xburst/start.S b/arch/mips/cpu/xburst/start.S index 3a8280c..194d745 100644 --- a/arch/mips/cpu/xburst/start.S +++ b/arch/mips/cpu/xburst/start.S @@ -87,7 +87,7 @@ relocate_code: lw t3, 0(t0) sw t3, 0(t1) addut0, 4 - ble t0, t2, 1b + blt t0, t2, 1b addu t1, 4 /* If caches were enabled, we would have to flush them here. */ -- 1.7.10 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] MIPS: start.S: don't save flush_cache parameters in advance
Saving the parameters in advance unnecessarily complicates the code. The destination address is already saved in the 's2' register, and that register is not clobbered by the copy loop. The size of the copied data can be computed after the copy loop is done. Change the code to compute the size parameter right before calling flush_cache, and set the destination address parameter in the delay slot of the actuall call. Signed-off-by: Gabor Juhos juh...@openwrt.org Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com --- arch/mips/cpu/mips32/start.S | 12 ++-- arch/mips/cpu/mips64/start.S | 12 ++-- 2 files changed, 4 insertions(+), 20 deletions(-) diff --git a/arch/mips/cpu/mips32/start.S b/arch/mips/cpu/mips32/start.S index d67dafa..77f1103 100644 --- a/arch/mips/cpu/mips32/start.S +++ b/arch/mips/cpu/mips32/start.S @@ -296,13 +296,6 @@ relocate_code: * t1 = target address * t2 = source end address */ - - /* -* Save destination address and size for later usage in flush_cache() -*/ - movea0, t1 # a0 -- destination addr - sub a1, t2, t0 # a1 -- size - 1: lw t3, 0(t0) sw t3, 0(t1) @@ -311,11 +304,10 @@ relocate_code: addu t1, 4 /* If caches were enabled, we would have to flush them here. */ - - /* a0 a1 are already set up for flush_cache(start, size) */ + sub a1, t1, s2 # a1 -- size la t9, flush_cache jalrt9 -nop +move a0, s2 # a0 -- destination address /* Jump to where we've relocated ourselves */ addit0, s2, in_ram - _start diff --git a/arch/mips/cpu/mips64/start.S b/arch/mips/cpu/mips64/start.S index d213c8e..80e6bb1 100644 --- a/arch/mips/cpu/mips64/start.S +++ b/arch/mips/cpu/mips64/start.S @@ -175,13 +175,6 @@ relocate_code: * t1 = target address * t2 = source end address */ - - /* -* Save destination address and size for dlater usage in flush_cache() -*/ - movea0, t1 # a0 -- destination addr - dsuba1, t2, t0 # a1 -- size - 1: lw t3, 0(t0) sw t3, 0(t1) @@ -190,11 +183,10 @@ relocate_code: daddu t1, 4 /* If caches were enabled, we would have to flush them here. */ - - /* a0 a1 are already set up for flush_cache(start, size) */ + dsuba1, t1, s2 # a1 -- size dla t9, flush_cache jalrt9 -nop +move a0, s2 # a0 -- destination address /* Jump to where we've relocated ourselves */ daddi t0, s2, in_ram - _start -- 1.7.10 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/11] tablebased pinmux for Tegra20
This series introduces tablebased pinmux to all Tegra20 boards and removes the old way of doing pinmux to avoid any possible conflicts in pin setup. Patch 1 introduces a temporary CONFIG option for the new pinmux style to avoid breaking bisectability in the middle of the series. This option gets removed again in patch 10. I have verified that all commits build without errors and tested the new pinmux on my Colibri T20 platform. For all other boards I took the pinmux configuration from the Linux kernel, but only un-tristated the pads that are used by U-Boot. I can't test the other boards myself, so please everyone with the hardware give this a run and provide a tested-by or a bug report. The series is based denx.de/u-boot-tegra/next. Patch 11 is more of a RFC and removes the old funcmux as after the switchover nothing uses it anymore. We are not doing real muxing in U-Boot, so there is no need to keep it. But I want to hear from other people if they see any reason to keep this. Lucas Stach (11): tegra: introduce config option to do table based pinmux tegra20: add entry point and helper for tablebased pinmux tegra20: switch over colibri_t20 board to use tablebased pinmux tegra20: switch over tamonten platform to use tablebased pinmux tegra20: switch over harmony board to use tablebased pinmux tegra20: switch over seaboard and ventana to use tablebased pinmux tegra20: switch over whistler board to use tablebased pinmux tegra20: switch over paz00 board to use tablebased pinmux tegra20: switch over trimslice board to use tablebased pinmux tegra20: remove old pinmux setup tegra20: remove funcmux arch/arm/cpu/tegra-common/board.c | 26 -- arch/arm/cpu/tegra20-common/Makefile | 2 +- arch/arm/cpu/tegra20-common/funcmux.c | 310 - arch/arm/include/asm/arch-tegra/board.h| 12 - arch/arm/include/asm/arch-tegra20/funcmux.h| 67 - arch/arm/include/asm/arch-tegra20/pinmux.h | 12 + board/avionic-design/common/tamonten.c | 133 +++-- board/compal/paz00/paz00.c | 149 +++--- board/compulab/trimslice/trimslice.c | 146 +++--- board/nvidia/common/board.c| 36 +-- board/nvidia/harmony/harmony.c | 143 -- board/nvidia/seaboard/seaboard.c | 133 +++-- board/nvidia/whistler/whistler.c | 131 - .../colibri_t20-common/colibri_t20-common.c| 132 +++-- board/toradex/colibri_t20_iris/colibri_t20_iris.c | 16 +- drivers/i2c/tegra_i2c.c| 9 - drivers/input/tegra-kbc.c | 4 +- drivers/mtd/nand/tegra_nand.c | 1 - drivers/video/tegra.c | 3 - include/configs/colibri_t20_iris.h | 1 - include/configs/trimslice.h| 1 - include/configs/whistler.h | 1 - 22 files changed, 814 insertions(+), 654 deletions(-) delete mode 100644 arch/arm/cpu/tegra20-common/funcmux.c delete mode 100644 arch/arm/include/asm/arch-tegra20/funcmux.h -- 1.8.0.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/11] tegra: introduce config option to do table based pinmux
This disables all pinmux entry points and instead calls pinmux_init() in
early board init, allowing boards to set up the pinmux in one shot, like
it's done with Tegra30.
This option is temporary and can go away once we switched over all
boards to the new pinmux style.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
board/nvidia/common/board.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index a4af539..d9d0e59 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -132,7 +132,9 @@ int board_init(void)
gpio_config_uart();
#endif
#ifdef CONFIG_TEGRA_SPI
+#ifndef CONFIG_TEGRA_TABLEBASED_PINMUX
pin_mux_spi();
+#endif
spi_init();
#endif
#ifdef CONFIG_PWM_TEGRA
@@ -140,7 +142,9 @@ int board_init(void)
debug(%s: Failed to init pwm\n, __func__);
#endif
#ifdef CONFIG_LCD
+#ifndef CONFIG_TEGRA_TABLEBASED_PINMUX
pin_mux_display();
+#endif
tegra_lcd_check_next_stage(gd-fdt_blob, 0);
#endif
/* boot param addr */
@@ -165,14 +169,16 @@ int board_init(void)
#endif /* CONFIG_TEGRA_I2C */
#ifdef CONFIG_USB_EHCI_TEGRA
+#ifndef CONFIG_TEGRA_TABLEBASED_PINMUX
pin_mux_usb();
+#endif
board_usb_init(gd-fdt_blob);
#endif
#ifdef CONFIG_LCD
tegra_lcd_check_next_stage(gd-fdt_blob, 0);
#endif
-#ifdef CONFIG_TEGRA_NAND
+#if defined(CONFIG_TEGRA_NAND) !defined(CONFIG_TEGRA_TABLEBASED_PINMUX)
pin_mux_nand();
#endif
@@ -196,7 +202,7 @@ void gpio_early_init(void) __attribute__((weak,
alias(__gpio_early_init)));
int board_early_init_f(void)
{
-#if defined(CONFIG_TEGRA30)
+#if defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA_TABLEBASED_PINMUX)
pinmux_init();
#endif
board_init_uart_f();
--
1.8.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/11] tegra20: add entry point and helper for tablebased pinmux
Signed-off-by: Lucas Stach d...@lynxeye.de
---
arch/arm/include/asm/arch-tegra20/pinmux.h | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/include/asm/arch-tegra20/pinmux.h
b/arch/arm/include/asm/arch-tegra20/pinmux.h
index a9b4eda..a167e48 100644
--- a/arch/arm/include/asm/arch-tegra20/pinmux.h
+++ b/arch/arm/include/asm/arch-tegra20/pinmux.h
@@ -350,4 +350,16 @@ void pinmux_set_tristate(enum pmux_pingrp pin, int enable);
*/
void pinmux_config_table(const struct pingroup_config *config, int len);
+/* Set a group of pins from a table */
+void pinmux_init(void);
+
+/* helper to fill pinmux table */
+#define PINMUX_ENTRY(_pingroup, _mux, _pull, _tri) \
+ { \
+ .pingroup = PINGRP_##_pingroup, \
+ .func = PMUX_FUNC_##_mux, \
+ .pull = PMUX_PULL_##_pull,\
+ .tristate = PMUX_TRI_##_tri, \
+ }
+
#endif /* PINMUX_H */
--
1.8.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/11] tegra20: switch over tamonten platform to use tablebased pinmux
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
board/avionic-design/common/tamonten.c | 133 -
include/configs/medcom-wide.h | 3 +
include/configs/plutux.h | 3 +
include/configs/tec.h | 3 +
4 files changed, 125 insertions(+), 17 deletions(-)
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
index e6a932e..f072407 100644
--- a/board/avionic-design/common/tamonten.c
+++ b/board/avionic-design/common/tamonten.c
@@ -3,6 +3,8 @@
* NVIDIA Corporation www.nvidia.com
* (C) Copyright 2011-2012
* Avionic Design GmbH www.avionic-design.de
+ * (C) Copyright 2013
+ * Lucas Stach
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -28,7 +30,6 @@
#include asm/io.h
#include asm/gpio.h
#include asm/arch/clock.h
-#include asm/arch/funcmux.h
#include asm/arch/pinmux.h
#include asm/arch/tegra.h
#include asm/arch-tegra/board.h
@@ -50,28 +51,126 @@ void gpio_early_init(void)
#endif
#ifdef CONFIG_TEGRA_MMC
-/*
- * Routine: pin_mux_mmc
- * Description: setup the pin muxes/tristate values for the SDMMC(s)
- */
-static void pin_mux_mmc(void)
-{
- funcmux_select(PERIPH_ID_SDMMC4, FUNCMUX_SDMMC4_ATB_GMA_GME_8_BIT);
- /* for write-protect GPIO PI6 */
- pinmux_tristate_disable(PINGRP_ATA);
- /* for CD GPIO PH2 */
- pinmux_tristate_disable(PINGRP_ATD);
-}
-
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- /* Enable muxes, etc. for SDMMC controllers */
- pin_mux_mmc();
-
/* init dev 0, SD slot, with 4-bit bus */
tegra_mmc_init(0, 4, GPIO_PI6, GPIO_PH2);
return 0;
}
#endif
+
+static struct pingroup_config tamonten_pinmux[] = {
+ PINMUX_ENTRY(ATA, IDE, NORMAL, NORMAL), /* GPIO */
+ PINMUX_ENTRY(ATB, SDIO4, NORMAL, NORMAL), /* MMC */
+ PINMUX_ENTRY(ATC, NAND, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATD, GMI, NORMAL, NORMAL), /* GPIO */
+ PINMUX_ENTRY(ATE, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV1, PLLA_OUT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV2, PLLP_OUT4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CRTP, CRT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CSUS, VI_SENSOR_CLK, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP1, DAP1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP2, DAP2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP3, DAP3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP4, DAP4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DDC, RSVD4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTA, SDIO2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTB, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTC, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTD, SDIO2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTE, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTF, I2C3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMA, SDIO4, NORMAL, NORMAL), /* MMC */
+ PINMUX_ENTRY(GMB, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMC, UARTD, NORMAL, NORMAL), /* UART D */
+ PINMUX_ENTRY(GMD, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GME, SDIO4, NORMAL, NORMAL), /* MMC */
+ PINMUX_ENTRY(GPU, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GPU7, RTCK, NORMAL, NORMAL), /* JTAG RTCK */
+ PINMUX_ENTRY(GPV, PCIE, NORMAL, TRISTATE),
+ PINMUX_ENTRY(HDINT, HDMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(I2CP, I2C, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRRX, UARTA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRTX, UARTA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCA, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCB, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCC, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCD, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCE, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCF, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LCSN, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD0, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD1, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD2, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD3, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD4, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD5, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD6, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD7, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD8, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD9, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD10, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD11, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD12, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD13, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD14, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD15, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD16, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD17, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LDC, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LDI, DISPA,
[U-Boot] [PATCH 03/11] tegra20: switch over colibri_t20 board to use tablebased pinmux
Init Colibri T20 pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
.../colibri_t20-common/colibri_t20-common.c| 132 +
board/toradex/colibri_t20_iris/colibri_t20_iris.c | 16 +--
include/configs/colibri_t20_iris.h | 3 +
3 files changed, 115 insertions(+), 36 deletions(-)
diff --git a/board/toradex/colibri_t20-common/colibri_t20-common.c
b/board/toradex/colibri_t20-common/colibri_t20-common.c
index 6d5e47d..e5163f3 100644
--- a/board/toradex/colibri_t20-common/colibri_t20-common.c
+++ b/board/toradex/colibri_t20-common/colibri_t20-common.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012 Lucas Stach
+ * Copyright (C) 2012-2013 Lucas Stach
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -14,31 +14,121 @@
*/
#include common.h
-#include asm/arch/clock.h
-#include asm/arch/funcmux.h
#include asm/arch/pinmux.h
#include asm/arch-tegra/board.h
#include colibri_t20-common.h
-#ifdef CONFIG_USB_EHCI_TEGRA
-void colibri_t20_common_pin_mux_usb(void)
-{
- /* module internal USB bus to connect ethernet chipset */
- funcmux_select(PERIPH_ID_USB2, FUNCMUX_USB2_ULPI);
- /* ULPI reference clock output */
- pinmux_set_func(PINGRP_CDEV2, PMUX_FUNC_PLLP_OUT4);
- pinmux_tristate_disable(PINGRP_CDEV2);
- /* PHY reset GPIO */
- pinmux_tristate_disable(PINGRP_UAC);
- /* VBus GPIO */
- pinmux_tristate_disable(PINGRP_DTE);
-}
-#endif
+static struct pingroup_config colibri_t20_pinmux[] = {
+ PINMUX_ENTRY(ATA, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATB, SDIO4, NORMAL, NORMAL), /* MMC */
+ PINMUX_ENTRY(ATC, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATD, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATE, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV1, PLLA_OUT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV2, PLLP_OUT4, NORMAL, NORMAL), /* ULPI REFCLK */
+ PINMUX_ENTRY(CRTP, CRT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CSUS, VI_SENSOR_CLK, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP1, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP2, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP3, DAP3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP4, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DDC, I2C2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTA, RSVD4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTB, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTC, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTD, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTE, RSVD1, NORMAL, NORMAL), /* GPIO */
+ PINMUX_ENTRY(DTF, RSVD4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMA, SDIO4, NORMAL, NORMAL), /* MMC */
+ PINMUX_ENTRY(GMB, IDE, NORMAL, NORMAL), /* GPIO */
+ PINMUX_ENTRY(GMC, UARTD, NORMAL, NORMAL), /* UART D */
+ PINMUX_ENTRY(GMD, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GME, SDIO4, NORMAL, NORMAL), /* MMC 8bit */
+ PINMUX_ENTRY(GPU, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GPU7, RTCK, NORMAL, NORMAL), /* JTAG RTCK */
+ PINMUX_ENTRY(GPV, RSVD4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(HDINT, HDMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(I2CP, I2C, NORMAL, NORMAL),
+ PINMUX_ENTRY(IRRX, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRTX, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCA, NAND, NORMAL, NORMAL), /* NAND */
+ PINMUX_ENTRY(KBCB, NAND, NORMAL, NORMAL), /* NAND */
+ PINMUX_ENTRY(KBCC, NAND, NORMAL, NORMAL), /* NAND */
+ PINMUX_ENTRY(KBCD, NAND, NORMAL, NORMAL), /* NAND */
+ PINMUX_ENTRY(KBCE, NAND, NORMAL, NORMAL), /* NAND */
+ PINMUX_ENTRY(KBCF, NAND, NORMAL, NORMAL), /* NAND */
+ PINMUX_ENTRY(LCSN,RSVD4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD0, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD1, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD2, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD3, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD4, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD5, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD6, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD7, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD8, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD9, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD10, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD11, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD12, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD13, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD14, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD15, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD16, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD17, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LDC, RSVD4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LDI, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LHP0, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LHP1, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LHP2, DISPA,
[U-Boot] [PATCH 05/11] tegra20: switch over harmony board to use tablebased pinmux
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
board/nvidia/harmony/harmony.c | 143 -
include/configs/harmony.h | 3 +
2 files changed, 116 insertions(+), 30 deletions(-)
diff --git a/board/nvidia/harmony/harmony.c b/board/nvidia/harmony/harmony.c
index 93430ed..f6dc709 100644
--- a/board/nvidia/harmony/harmony.c
+++ b/board/nvidia/harmony/harmony.c
@@ -1,6 +1,8 @@
/*
* (C) Copyright 2010,2011
* NVIDIA Corporation www.nvidia.com
+ * (C) Copyright 2013
+ * Lucas Stach
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -24,7 +26,6 @@
#include common.h
#include asm/io.h
#include asm/arch/clock.h
-#include asm/arch/funcmux.h
#include asm/arch/pinmux.h
#include asm/arch/tegra.h
#include asm/arch-tegra/mmc.h
@@ -35,34 +36,11 @@
#ifdef CONFIG_TEGRA_MMC
-/*
- * Routine: pin_mux_mmc
- * Description: setup the pin muxes/tristate values for the SDMMC(s)
- */
-static void pin_mux_mmc(void)
-{
- funcmux_select(PERIPH_ID_SDMMC4, FUNCMUX_SDMMC4_ATB_GMA_GME_8_BIT);
- funcmux_select(PERIPH_ID_SDMMC2, FUNCMUX_SDMMC2_DTA_DTD_8BIT);
-
- /* For power GPIO PI6 */
- pinmux_tristate_disable(PINGRP_ATA);
- /* For CD GPIO PH2 */
- pinmux_tristate_disable(PINGRP_ATD);
-
- /* For power GPIO PT3 */
- pinmux_tristate_disable(PINGRP_DTB);
- /* For CD GPIO PI5 */
- pinmux_tristate_disable(PINGRP_ATC);
-}
-
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
debug(board_mmc_init called\n);
- /* Enable muxes, etc. for SDMMC controllers */
- pin_mux_mmc();
-
debug(board_mmc_init: init SD slot J26\n);
/* init dev 0, SD slot J26, with 8-bit bus */
tegra_mmc_init(0, 8, GPIO_PI6, GPIO_PH2);
@@ -75,11 +53,116 @@ int board_mmc_init(bd_t *bd)
}
#endif
-void pin_mux_usb(void)
+static struct pingroup_config harmony_pinmux[] = {
+ PINMUX_ENTRY(ATA, IDE, NORMAL, NORMAL), /* GPIO PI6*/
+ PINMUX_ENTRY(ATB, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(ATC, NAND, NORMAL, NORMAL), /* NAND, GPIO PI5 */
+ PINMUX_ENTRY(ATD, GMI, NORMAL, NORMAL), /* GPIO PH2 */
+ PINMUX_ENTRY(ATE, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV1, PLLA_OUT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV2, PLLP_OUT4, NORMAL, NORMAL), /* ULPI REFCLK */
+ PINMUX_ENTRY(CRTP, CRT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CSUS, VI_SENSOR_CLK, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP1, DAP1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP2, DAP2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP3, DAP3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP4, DAP4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DDC, I2C2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTA, SDIO2, NORMAL, NORMAL), /* SDMMC2 */
+ PINMUX_ENTRY(DTB, RSVD1, NORMAL, NORMAL), /* GPIO PT3 */
+ PINMUX_ENTRY(DTC, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTD, SDIO2, NORMAL, NORMAL), /* SDMMC2 */
+ PINMUX_ENTRY(DTE, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTF, I2C3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMA, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(GMB, GMI, NORMAL, NORMAL), /* GPIO PC7 */
+ PINMUX_ENTRY(GMC, UARTD, NORMAL, NORMAL), /* UART D */
+ PINMUX_ENTRY(GMD, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GME, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(GPU, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GPU7, RTCK, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GPV, PCIE, NORMAL, TRISTATE),
+ PINMUX_ENTRY(HDINT, HDMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(I2CP, I2C, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRRX, UARTA, NORMAL, NORMAL), /* UART A */
+ PINMUX_ENTRY(IRTX, UARTA, NORMAL, NORMAL), /* UART A */
+ PINMUX_ENTRY(KBCA, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCB, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCC, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCD, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCE, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCF, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LCSN, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD0, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD1, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD2, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD3, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD4, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD5, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD6, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD7, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD8, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD9, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD10, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD11, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD12, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD13, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD14, DISPA, NORMAL,
[U-Boot] [PATCH 07/11] tegra20: switch over whistler board to use tablebased pinmux
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
board/nvidia/whistler/whistler.c | 131 ++-
include/configs/whistler.h | 3 +
2 files changed, 119 insertions(+), 15 deletions(-)
diff --git a/board/nvidia/whistler/whistler.c b/board/nvidia/whistler/whistler.c
index 592cd6b..56f066e 100644
--- a/board/nvidia/whistler/whistler.c
+++ b/board/nvidia/whistler/whistler.c
@@ -1,6 +1,8 @@
/*
* (C) Copyright 2010-2012
* NVIDIA Corporation www.nvidia.com
+ * (C) Copyright 2013
+ * Lucas Stach
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -25,7 +27,6 @@
#include asm/io.h
#include asm/arch/tegra.h
#include asm/arch/clock.h
-#include asm/arch/funcmux.h
#include asm/arch/pinmux.h
#include asm/arch-tegra/mmc.h
#include asm/gpio.h
@@ -34,17 +35,6 @@
#include mmc.h
#endif
-
-/*
- * Routine: pin_mux_mmc
- * Description: setup the pin muxes/tristate values for the SDMMC(s)
- */
-static void pin_mux_mmc(void)
-{
- funcmux_select(PERIPH_ID_SDMMC3, FUNCMUX_SDMMC3_SDB_SLXA_8BIT);
- funcmux_select(PERIPH_ID_SDMMC4, FUNCMUX_SDMMC4_ATC_ATD_8BIT);
-}
-
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
@@ -70,9 +60,6 @@ int board_mmc_init(bd_t *bd)
if (ret)
printf(i2c_write 0 0x3c 0x44 failed: %d\n, ret);
- /* Enable muxes, etc. for SDMMC controllers */
- pin_mux_mmc();
-
/* init dev 0 (SDMMC4), (J29 HSMMC) with 8-bit bus */
tegra_mmc_init(0, 8, -1, -1);
@@ -107,3 +94,117 @@ void pin_mux_usb(void)
if (ret)
printf(i2c_write 0 0x20 6 failed: %d\n, ret);
}
+
+static struct pingroup_config whistler_pinmux[] = {
+ PINMUX_ENTRY(ATA, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATB, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATC, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(ATD, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(ATE, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV1, PLLA_OUT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV2, OSC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CRTP, CRT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CSUS, VI_SENSOR_CLK, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP1, DAP1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP2, DAP2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP3, DAP3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP4, DAP4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DDC, I2C2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTA, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTB, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTC, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTD, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTE, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTF, I2C3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMA, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMB, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMC, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMD, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GME, DAP5, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GPU, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GPU7, RTCK, NORMAL, NORMAL), /* JTAG RTCK */
+ PINMUX_ENTRY(GPV, PCIE, NORMAL, TRISTATE),
+ PINMUX_ENTRY(HDINT, HDMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(I2CP, I2C, NORMAL, NORMAL), /* DVC */
+ PINMUX_ENTRY(IRRX, UARTB, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRTX, UARTB, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCA, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCB, SDIO2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCC, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCD, SDIO2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCE, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCF, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LCSN, SPI3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD0, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD1, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD2, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD3, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD4, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD5, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD6, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD7, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD8, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD9, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD10, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD11, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD12, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD13, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD14, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD15, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD16, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD17, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LDC, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LDI, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LHP0, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LHP1, DISPA, NORMAL,
[U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
board/nvidia/seaboard/seaboard.c | 133 +--
include/configs/seaboard.h | 3 +
include/configs/ventana.h| 3 +
3 files changed, 121 insertions(+), 18 deletions(-)
diff --git a/board/nvidia/seaboard/seaboard.c b/board/nvidia/seaboard/seaboard.c
index 3e33da0..b5b4b31 100644
--- a/board/nvidia/seaboard/seaboard.c
+++ b/board/nvidia/seaboard/seaboard.c
@@ -1,6 +1,8 @@
/*
* (C) Copyright 2010,2011
* NVIDIA Corporation www.nvidia.com
+ * (C) Copyright 2013
+ * Lucas Stach
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -25,7 +27,6 @@
#include asm/io.h
#include asm/arch/tegra.h
#include asm/arch/clock.h
-#include asm/arch/funcmux.h
#include asm/arch/gpio.h
#include asm/arch/pinmux.h
#include asm/arch-tegra/mmc.h
@@ -47,29 +48,12 @@ void gpio_early_init_uart(void)
#endif
#ifdef CONFIG_TEGRA_MMC
-/*
- * Routine: pin_mux_mmc
- * Description: setup the pin muxes/tristate values for the SDMMC(s)
- */
-static void pin_mux_mmc(void)
-{
- funcmux_select(PERIPH_ID_SDMMC4, FUNCMUX_SDMMC4_ATB_GMA_GME_8_BIT);
- funcmux_select(PERIPH_ID_SDMMC3, FUNCMUX_SDMMC3_SDB_4BIT);
-
- /* For power GPIO PI6 */
- pinmux_tristate_disable(PINGRP_ATA);
- /* For CD GPIO PI5 */
- pinmux_tristate_disable(PINGRP_ATC);
-}
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
debug(board_mmc_init called\n);
- /* Enable muxes, etc. for SDMMC controllers */
- pin_mux_mmc();
-
debug(board_mmc_init: init eMMC\n);
/* init dev 0, eMMC chip, with 8-bit bus */
tegra_mmc_init(0, 8, -1, -1);
@@ -87,3 +71,116 @@ void pin_mux_usb(void)
/* For USB's GPIO PD0. For now, since we have no pinmux in fdt */
pinmux_tristate_disable(PINGRP_SLXK);
}
+static struct pingroup_config seaboard_pinmux[] = {
+ PINMUX_ENTRY(ATA, IDE, NORMAL, NORMAL), /* GPIO PI6 */
+ PINMUX_ENTRY(ATB, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(ATC, NAND, NORMAL, NORMAL), /* NAND, GPIO PI5 */
+ PINMUX_ENTRY(ATD, GMI, NORMAL, NORMAL), /* NAND, GPIO PH1,PH3 */
+ PINMUX_ENTRY(ATE, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV1, PLLA_OUT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV2, PLLP_OUT4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CRTP, CRT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CSUS, VI_SENSOR_CLK, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP1, DAP1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP2, DAP2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP3, DAP3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP4, DAP4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DDC, I2C2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTA, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTB, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTC, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTD, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTE, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTF, I2C3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMA, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(GMB, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMC, UARTD, NORMAL, NORMAL), /* UART D */
+ PINMUX_ENTRY(GMD, SFLASH, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GME, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(GPU, PWM, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GPU7, RTCK, NORMAL, NORMAL), /* JTAG RTCK */
+ PINMUX_ENTRY(GPV, PCIE, NORMAL, TRISTATE),
+ PINMUX_ENTRY(HDINT, HDMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(I2CP, I2C, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRRX, UARTB, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRTX, UARTB, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCA, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(KBCB, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(KBCC, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(KBCD, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(KBCE, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(KBCF, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(LCSN, RSVD4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD0, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD1, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD2, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD3, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD4, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD5, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD6, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD7, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD8, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD9, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD10, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD11, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD12, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD13, DISPA, NORMAL,
[U-Boot] [PATCH 08/11] tegra20: switch over paz00 board to use tablebased pinmux
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
board/compal/paz00/paz00.c | 149 ++---
include/configs/paz00.h| 3 +
2 files changed, 115 insertions(+), 37 deletions(-)
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..b56ba41 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2010-2012, NVIDIA CORPORATION. All rights reserved.
+ * Copyright (c) 2013 Lucas Stach
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -26,40 +27,11 @@
#ifdef CONFIG_TEGRA_MMC
-/*
- * Routine: pin_mux_mmc
- * Description: setup the pin muxes/tristate values for the SDMMC(s)
- */
-static void pin_mux_mmc(void)
-{
- /* SDMMC4: config 3, x8 on 2nd set of pins */
- pinmux_set_func(PINGRP_ATB, PMUX_FUNC_SDIO4);
- pinmux_set_func(PINGRP_GMA, PMUX_FUNC_SDIO4);
- pinmux_set_func(PINGRP_GME, PMUX_FUNC_SDIO4);
-
- pinmux_tristate_disable(PINGRP_ATB);
- pinmux_tristate_disable(PINGRP_GMA);
- pinmux_tristate_disable(PINGRP_GME);
-
- /* SDIO1: SDIO1_CLK, SDIO1_CMD, SDIO1_DAT[3:0] */
- pinmux_set_func(PINGRP_SDIO1, PMUX_FUNC_SDIO1);
-
- pinmux_tristate_disable(PINGRP_SDIO1);
-
- /* For power GPIO PV1 */
- pinmux_tristate_disable(PINGRP_UAC);
- /* For CD GPIO PV5 */
- pinmux_tristate_disable(PINGRP_GPV);
-}
-
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
debug(board_mmc_init called\n);
- /* Enable muxes, etc. for SDMMC controllers */
- pin_mux_mmc();
-
debug(board_mmc_init: init eMMC\n);
/* init dev 0, eMMC chip, with 8-bit bus */
tegra_mmc_init(0, 8, -1, -1);
@@ -72,13 +44,116 @@ int board_mmc_init(bd_t *bd)
}
#endif
-#ifdef CONFIG_LCD
-/* this is a weak define that we are overriding */
-void pin_mux_display(void)
-{
- debug(init display pinmux\n);
+static struct pingroup_config paz00_pinmux[] = {
+ PINMUX_ENTRY(ATA, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATB, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(ATC, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATD, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATE, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV1, PLLA_OUT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV2, PLLP_OUT4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CRTP, CRT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CSUS, PLLC_OUT1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP1, DAP1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP2, GMI, NORMAL, NORMAL), /* GPIO PA4 */
+ PINMUX_ENTRY(DAP3, DAP3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP4, DAP4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DDC, I2C2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTA, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTB, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTC, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTD, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTE, RSVD1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTF, I2C3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMA, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(GMB, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMC, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMD, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GME, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(GPU, PWM, NORMAL, NORMAL), /* GPIO PU4 */
+ PINMUX_ENTRY(GPU7, RTCK, NORMAL, NORMAL), /* JTAG RTCK */
+ PINMUX_ENTRY(GPV, PCIE, NORMAL, NORMAL), /* GPIO PV5 */
+ PINMUX_ENTRY(HDINT, HDMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(I2CP, I2C, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRRX, UARTA, NORMAL, NORMAL), /* UART A */
+ PINMUX_ENTRY(IRTX, UARTA, NORMAL, NORMAL), /* UART A */
+ PINMUX_ENTRY(KBCA, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCB, SDIO2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCC, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCD, SDIO2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCE, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCF, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LCSN, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD0, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD1, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD2, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD3, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD4, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD5, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD6, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD7, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD8, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD9, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD10, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD11, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD12, DISPA,
[U-Boot] [PATCH 09/11] tegra20: switch over trimslice board to use tablebased pinmux
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
board/compulab/trimslice/trimslice.c | 146 +++
include/configs/trimslice.h | 3 +
2 files changed, 118 insertions(+), 31 deletions(-)
diff --git a/board/compulab/trimslice/trimslice.c
b/board/compulab/trimslice/trimslice.c
index 8f4dd09..9af7ca6 100644
--- a/board/compulab/trimslice/trimslice.c
+++ b/board/compulab/trimslice/trimslice.c
@@ -1,6 +1,8 @@
/*
* (C) Copyright 2010-2012
* NVIDIA Corporation www.nvidia.com
+ * (C) Copyright 2013
+ * Lucas Stach
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -25,7 +27,6 @@
#include asm/io.h
#include asm/arch/tegra.h
#include asm/arch/clock.h
-#include asm/arch/funcmux.h
#include asm/arch/pinmux.h
#include asm/arch-tegra/mmc.h
#include asm/gpio.h
@@ -34,41 +35,11 @@
#include mmc.h
#endif
-void pin_mux_usb(void)
-{
- /*
-* USB1 internal/external mux GPIO, which masquerades as a VBUS GPIO
-* in the current device tree.
-*/
- pinmux_tristate_disable(PINGRP_UAC);
-}
-
-void pin_mux_spi(void)
-{
- funcmux_select(PERIPH_ID_SPI1, FUNCMUX_SPI1_GMC_GMD);
-}
-
-/*
- * Routine: pin_mux_mmc
- * Description: setup the pin muxes/tristate values for the SDMMC(s)
- */
-static void pin_mux_mmc(void)
-{
- funcmux_select(PERIPH_ID_SDMMC1, FUNCMUX_SDMMC1_SDIO1_4BIT);
- funcmux_select(PERIPH_ID_SDMMC4, FUNCMUX_SDMMC4_ATB_GMA_4_BIT);
-
- /* For CD GPIO PP1 */
- pinmux_tristate_disable(PINGRP_DAP3);
-}
-
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
debug(board_mmc_init called\n);
- /* Enable muxes, etc. for SDMMC controllers */
- pin_mux_mmc();
-
/* init dev 0 (SDMMC4), (micro-SD slot) with 4-bit bus */
tegra_mmc_init(0, 4, -1, GPIO_PP1);
@@ -77,3 +48,116 @@ int board_mmc_init(bd_t *bd)
return 0;
}
+static struct pingroup_config trimslice_pinmux[] = {
+ PINMUX_ENTRY(ATA, IDE, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATB, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(ATC, NAND, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATD, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(ATE, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV1, PLLA_OUT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV2, PLLP_OUT4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CRTP, CRT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CSUS, VI_SENSOR_CLK, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP1, DAP1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP2, DAP2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP3, DAP3, NORMAL, NORMAL), /* GPIO PP1 */
+ PINMUX_ENTRY(DAP4, DAP4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DDC, I2C2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTA, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTB, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTC, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTD, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTE, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTF, I2C3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMA, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(GMB, NAND, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMC, SFLASH, NORMAL, NORMAL), /* SPI1 */
+ PINMUX_ENTRY(GMD, SFLASH, NORMAL, NORMAL), /* SPI1 */
+ PINMUX_ENTRY(GME, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GPU, UARTA, NORMAL, NORMAL), /* UART A */
+ PINMUX_ENTRY(GPU7, RTCK, NORMAL, NORMAL), /* JTAG RTCK */
+ PINMUX_ENTRY(GPV, PCIE, NORMAL, TRISTATE),
+ PINMUX_ENTRY(HDINT, HDMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(I2CP, I2C, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRRX, UARTB, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRTX, UARTB, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCA, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCB, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCC, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCD, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCE, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCF, KBC, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LCSN, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD0, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD1, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD2, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD3, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD4, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD5, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD6, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD7, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD8, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD9, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD10, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD11, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD12, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD13, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD14, DISPA, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD15, DISPA, NORMAL, TRISTATE),
[U-Boot] [PATCH 10/11] tegra20: remove old pinmux setup
All boards are converted to the new tablebased pinmux setup. Get rid of
the old method.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
arch/arm/cpu/tegra-common/board.c | 25
arch/arm/include/asm/arch-tegra/board.h | 12 --
board/nvidia/common/board.c | 41 +
drivers/i2c/tegra_i2c.c | 9
drivers/input/tegra-kbc.c | 4 +---
drivers/video/tegra.c | 3 ---
include/configs/colibri_t20_iris.h | 4
include/configs/harmony.h | 3 ---
include/configs/medcom-wide.h | 3 ---
include/configs/paz00.h | 3 ---
include/configs/plutux.h| 3 ---
include/configs/seaboard.h | 3 ---
include/configs/tec.h | 3 ---
include/configs/trimslice.h | 4
include/configs/ventana.h | 3 ---
include/configs/whistler.h | 4
16 files changed, 2 insertions(+), 125 deletions(-)
diff --git a/arch/arm/cpu/tegra-common/board.c
b/arch/arm/cpu/tegra-common/board.c
index 1ec6c06..bb6a035 100644
--- a/arch/arm/cpu/tegra-common/board.c
+++ b/arch/arm/cpu/tegra-common/board.c
@@ -102,30 +102,6 @@ int checkboard(void)
}
#endif /* CONFIG_DISPLAY_BOARDINFO */
-static int uart_configs[] = {
-#if defined(CONFIG_TEGRA20)
- #if defined(CONFIG_TEGRA_UARTA_UAA_UAB)
- FUNCMUX_UART1_UAA_UAB,
- #elif defined(CONFIG_TEGRA_UARTA_GPU)
- FUNCMUX_UART1_GPU,
- #elif defined(CONFIG_TEGRA_UARTA_SDIO1)
- FUNCMUX_UART1_SDIO1,
- #else
- FUNCMUX_UART1_IRRX_IRTX,
- #endif
- FUNCMUX_UART2_UARTB,
- -1,
- FUNCMUX_UART4_GMC,
- -1,
-#else /* Tegra30 */
- FUNCMUX_UART1_ULPI, /* UARTA */
- -1,
- -1,
- -1,
- -1,
-#endif
-};
-
/**
* Set up the specified uarts
*
@@ -145,7 +121,6 @@ static void setup_uarts(int uart_ids)
if (uart_ids (1 i)) {
enum periph_id id = id_for_uart[i];
- funcmux_select(id, uart_configs[i]);
clock_ll_start_uart(id);
}
}
diff --git a/arch/arm/include/asm/arch-tegra/board.h
b/arch/arm/include/asm/arch-tegra/board.h
index 3db0d93..fffd55e 100644
--- a/arch/arm/include/asm/arch-tegra/board.h
+++ b/arch/arm/include/asm/arch-tegra/board.h
@@ -34,16 +34,4 @@ void board_init_uart_f(void);
/* Set up any early GPIOs the board might need for proper operation */
void gpio_early_init(void); /* overrideable GPIO config*/
-/*
- * Hooks to allow boards to set up the pinmux for a specific function.
- * Has to be implemented in the board files as we don't yet support pinmux
- * setup from FTD. If a board file does not implement one of those functions
- * an empty stub function will be called.
- */
-
-void pin_mux_usb(void); /* overrideable USB pinmux setup */
-void pin_mux_spi(void); /* overrideable SPI pinmux setup */
-void pin_mux_nand(void); /* overrideable NAND pinmux setup*/
-void pin_mux_display(void); /* overrideable DISPLAY pinmux setup */
-
#endif
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index d9d0e59..c76791c 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -69,18 +69,6 @@ int timer_init(void)
}
#endif
-void __pin_mux_usb(void)
-{
-}
-
-void pin_mux_usb(void) __attribute__((weak, alias(__pin_mux_usb)));
-
-void __pin_mux_spi(void)
-{
-}
-
-void pin_mux_spi(void) __attribute__((weak, alias(__pin_mux_spi)));
-
void __gpio_early_init_uart(void)
{
}
@@ -88,19 +76,6 @@ void __gpio_early_init_uart(void)
void gpio_early_init_uart(void)
__attribute__((weak, alias(__gpio_early_init_uart)));
-void __pin_mux_nand(void)
-{
- funcmux_select(PERIPH_ID_NDFLASH, FUNCMUX_DEFAULT);
-}
-
-void pin_mux_nand(void) __attribute__((weak, alias(__pin_mux_nand)));
-
-void __pin_mux_display(void)
-{
-}
-
-void pin_mux_display(void) __attribute__((weak, alias(__pin_mux_display)));
-
/*
* Routine: power_det_init
* Description: turn off power detects
@@ -132,9 +107,6 @@ int board_init(void)
gpio_config_uart();
#endif
#ifdef CONFIG_TEGRA_SPI
-#ifndef CONFIG_TEGRA_TABLEBASED_PINMUX
- pin_mux_spi();
-#endif
spi_init();
#endif
#ifdef CONFIG_PWM_TEGRA
@@ -142,9 +114,6 @@ int board_init(void)
debug(%s: Failed to init pwm\n, __func__);
#endif
#ifdef CONFIG_LCD
-#ifndef CONFIG_TEGRA_TABLEBASED_PINMUX
- pin_mux_display();
-#endif
tegra_lcd_check_next_stage(gd-fdt_blob, 0);
#endif
/* boot param addr */
@@ -169,19 +138,12 @@ int board_init(void)
#endif /* CONFIG_TEGRA_I2C */
#ifdef CONFIG_USB_EHCI_TEGRA
-#ifndef CONFIG_TEGRA_TABLEBASED_PINMUX
- pin_mux_usb();
-#endif
board_usb_init(gd-fdt_blob);
#endif
#ifdef CONFIG_LCD
tegra_lcd_check_next_stage(gd-fdt_blob, 0);
#endif
-#if
[U-Boot] [PATCH 11/11] tegra20: remove funcmux
It's not used by anything anymore, now that all boards are using
tablebased pinmux.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
arch/arm/cpu/tegra-common/board.c | 1 -
arch/arm/cpu/tegra20-common/Makefile| 2 +-
arch/arm/cpu/tegra20-common/funcmux.c | 310
arch/arm/include/asm/arch-tegra20/funcmux.h | 67 --
board/nvidia/common/board.c | 1 -
drivers/mtd/nand/tegra_nand.c | 1 -
6 files changed, 1 insertion(+), 381 deletions(-)
delete mode 100644 arch/arm/cpu/tegra20-common/funcmux.c
delete mode 100644 arch/arm/include/asm/arch-tegra20/funcmux.h
diff --git a/arch/arm/cpu/tegra-common/board.c
b/arch/arm/cpu/tegra-common/board.c
index bb6a035..073da3a 100644
--- a/arch/arm/cpu/tegra-common/board.c
+++ b/arch/arm/cpu/tegra-common/board.c
@@ -24,7 +24,6 @@
#include common.h
#include asm/io.h
#include asm/arch/clock.h
-#include asm/arch/funcmux.h
#include asm/arch/tegra.h
#include asm/arch-tegra/board.h
#include asm/arch-tegra/pmc.h
diff --git a/arch/arm/cpu/tegra20-common/Makefile
b/arch/arm/cpu/tegra20-common/Makefile
index 8184e5e..142786f 100644
--- a/arch/arm/cpu/tegra20-common/Makefile
+++ b/arch/arm/cpu/tegra20-common/Makefile
@@ -31,7 +31,7 @@ CFLAGS_arch/arm/cpu/tegra20-common/warmboot_avp.o +=
-march=armv4t
LIB= $(obj)lib$(SOC)-common.o
-COBJS-y+= clock.o funcmux.o pinmux.o
+COBJS-y+= clock.o pinmux.o
COBJS-$(CONFIG_TEGRA_LP0) += warmboot.o crypto.o warmboot_avp.o
COBJS-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o
COBJS-$(CONFIG_TEGRA_PMU) += pmu.o
diff --git a/arch/arm/cpu/tegra20-common/funcmux.c
b/arch/arm/cpu/tegra20-common/funcmux.c
deleted file mode 100644
index a1c55a6..000
--- a/arch/arm/cpu/tegra20-common/funcmux.c
+++ /dev/null
@@ -1,310 +0,0 @@
-/*
- * Copyright (c) 2011 The Chromium OS Authors.
- * 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
- */
-
-/* Tegra20 high-level function multiplexing */
-#include common.h
-#include asm/arch/clock.h
-#include asm/arch/funcmux.h
-#include asm/arch/pinmux.h
-
-/*
- * The PINMUX macro is used to set up pinmux tables.
- */
-#define PINMUX(grp, mux, pupd, tri) \
- {PINGRP_##grp, PMUX_FUNC_##mux, PMUX_PULL_##pupd, PMUX_TRI_##tri}
-
-static const struct pingroup_config disp1_default[] = {
- PINMUX(LDI, DISPA, NORMAL,NORMAL),
- PINMUX(LHP0, DISPA, NORMAL,NORMAL),
- PINMUX(LHP1, DISPA, NORMAL,NORMAL),
- PINMUX(LHP2, DISPA, NORMAL,NORMAL),
- PINMUX(LHS, DISPA, NORMAL,NORMAL),
- PINMUX(LM0, RSVD4, NORMAL,NORMAL),
- PINMUX(LPP, DISPA, NORMAL,NORMAL),
- PINMUX(LPW0, DISPA, NORMAL,NORMAL),
- PINMUX(LPW2, DISPA, NORMAL,NORMAL),
- PINMUX(LSC0, DISPA, NORMAL,NORMAL),
- PINMUX(LSPI, DISPA, NORMAL,NORMAL),
- PINMUX(LVP1, DISPA, NORMAL,NORMAL),
- PINMUX(LVS, DISPA, NORMAL,NORMAL),
- PINMUX(SLXD, SPDIF, NORMAL,NORMAL),
-};
-
-
-int funcmux_select(enum periph_id id, int config)
-{
- int bad_config = config != FUNCMUX_DEFAULT;
-
- switch (id) {
- case PERIPH_ID_UART1:
- switch (config) {
- case FUNCMUX_UART1_IRRX_IRTX:
- pinmux_set_func(PINGRP_IRRX, PMUX_FUNC_UARTA);
- pinmux_set_func(PINGRP_IRTX, PMUX_FUNC_UARTA);
- pinmux_tristate_disable(PINGRP_IRRX);
- pinmux_tristate_disable(PINGRP_IRTX);
- break;
- case FUNCMUX_UART1_UAA_UAB:
- pinmux_set_func(PINGRP_UAA, PMUX_FUNC_UARTA);
- pinmux_set_func(PINGRP_UAB, PMUX_FUNC_UARTA);
- pinmux_tristate_disable(PINGRP_UAA);
- pinmux_tristate_disable(PINGRP_UAB);
- bad_config = 0;
- break;
- case FUNCMUX_UART1_GPU:
- pinmux_set_func(PINGRP_GPU, PMUX_FUNC_UARTA);
- pinmux_tristate_disable(PINGRP_GPU);
- bad_config = 0;
-
[U-Boot] [U-BOOT] help on mmc driver
Hi, I need some help on mmc driver development on u-boot. Few questions: 1. is mmc framework in u-boot supports all type of card interfaces like SD, MMC, and eMMC 2. If I write a driver do I need to develop the common driver for all or a separate drivers for individual cards. 3. Is there any drivers in current u-boot drivers/mmc have individual card interfaces support (SD MMC eMMC) 4. is there any drivers in current u-boot driver/mmc for common card intefaces (SD | MMC | eMMC) Request for help. Thanks, Jagan. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3] Consolidate bool type
On Wed, Jan 23, 2013 at 02:05:26PM -0800, York Sun wrote:
On 01/23/2013 02:02 PM, Scott Wood wrote:
On 01/23/2013 04:01:49 PM, York Sun wrote:
On 01/23/2013 01:52 PM, Scott Wood wrote:
On 01/23/2013 03:46:04 PM, York Sun wrote:
On 01/23/2013 01:41 PM, York Sun wrote:
I should put RFC in the subject as I am not able to compile all ARCH
myself.
So how do you see this patch becoming non-RFC? I think most people
don't have every single toolchain. You should at least get a toolchain
for a couple major architectures such as ARM. Usually RFC is for when
you know the patch has issues, and don't want it applied yet even if
nobody else finds fault with it.
I know this version has problem. I am hoping more people get involved
and test what they can. I tried the arm toolchain you pointed to me. I
couldn't run MAKEALL for arm.
Even before your patch, using USE_PRIVATE_LIBGCC? How many boards failed?
I don't know. Wolfgang brought it. Allen kindly offered help to verify
on tegra which uses USE_PRIVATE_LIBGCC.
Built and tested on tegra, no problems. I'm still seeing a lot of
references to TRUE/FALSE even after this patch though:
$ git grep -e FALSE -e TRUE | awk 'BEGIN {FS = :} {print $1}' | sort | uniq
arch/arm/cpu/arm926ejs/spear/spear600.c
arch/arm/cpu/arm926ejs/spear/spl_boot.c
arch/m68k/lib/interrupts.c
arch/nds32/lib/interrupts.c
arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c
arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c
arch/powerpc/cpu/ppc4xx/44x_spd_ddr.c
arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c
Binary file tools/easylogo/linux_logo.tga matches
board/amcc/bamboo/bamboo.c
board/amcc/yucca/yucca.h
board/bf533-ezkit/flash.c
board/bf537-stamp/ide-cf.c
board/esd/common/lcd.c
board/esd/dasa_sim/cmd_dasa_sim.c
board/esd/pmc440/fpga.c
board/evb64260/eth_addrtbl.c
board/gen860t/fpga.c
board/matrix_vision/mvblx/mvblx.c
board/mousse/flash.c
board/mpl/common/isa.c
board/mpl/mip405/mip405.c
board/mpl/pip405/pip405.c
board/sacsng/clkinit.c
board/spear/x600/fpga.c
board/teejet/mt_ventoux/mt_ventoux.c
board/xilinx/common/xbasic_types.c
board/xilinx/common/xdma_channel.c
board/xilinx/common/xdma_channel_sg.c
board/xilinx/common/xipif_v1_23_b.h
board/xilinx/common/xpacket_fifo_v1_00_b.h
board/xilinx/common/xversion.c
common/bedbug.c
common/cmd_bedbug.c
common/cmd_fdc.c
common/cmd_scsi.c
drivers/bios_emulator/x86emu/debug.c
drivers/block/ahci.c
drivers/block/sata_dwc.c
drivers/block/sym53c8xx.c
drivers/dma/MCD_dmaApi.c
drivers/fpga/ACEX1K.c
drivers/fpga/altera.c
drivers/fpga/cyclon2.c
drivers/fpga/lattice.c
drivers/fpga/spartan2.c
drivers/fpga/spartan3.c
drivers/fpga/virtex2.c
drivers/fpga/xilinx.c
drivers/net/armada100_fec.c
drivers/net/e1000.c
drivers/net/e1000.h
drivers/net/e1000_spi.c
drivers/net/npe/include/IxAtmdAccCtrl.h
drivers/net/npe/include/IxEthAcc_p.h
drivers/net/npe/include/IxEthDB.h
drivers/net/npe/include/IxEthDB_p.h
drivers/net/npe/include/IxEthMii.h
drivers/net/npe/include/IxFeatureCtrl.h
drivers/net/npe/include/IxHssAcc.h
drivers/net/npe/include/IxNpeDl.h
drivers/net/npe/include/IxNpeDlNpeMgr_p.h
drivers/net/npe/include/IxNpeDlNpeMgrUtils_p.h
drivers/net/npe/include/IxNpeMhConfig_p.h
drivers/net/npe/include/IxOsal.h
drivers/net/npe/include/IxOsalTypes.h
drivers/net/npe/include/IxPerfProfAcc.h
drivers/net/npe/include/IxQMgrAqmIf_p.h
drivers/net/npe/include/IxTimeSyncAcc.h
drivers/net/npe/IxEthAcc.c
drivers/net/npe/IxEthAccCommon.c
drivers/net/npe/IxEthAccDataPlane.c
drivers/net/npe/IxEthAccMac.c
drivers/net/npe/IxEthDBAPI.c
drivers/net/npe/IxEthDBAPISupport.c
drivers/net/npe/IxEthDBCore.c
drivers/net/npe/IxEthDBEvents.c
drivers/net/npe/IxEthDBFeatures.c
drivers/net/npe/IxEthDBFirewall.c
drivers/net/npe/IxEthDBLearning.c
drivers/net/npe/IxEthDBNPEAdaptor.c
drivers/net/npe/IxEthDBPortUpdate.c
drivers/net/npe/IxEthDBReports.c
drivers/net/npe/IxEthDBSearch.c
drivers/net/npe/IxEthDBSpanningTree.c
drivers/net/npe/IxEthDBUtil.c
drivers/net/npe/IxEthDBVlan.c
drivers/net/npe/IxEthMii.c
drivers/net/npe/IxFeatureCtrl.c
drivers/net/npe/IxNpeDl.c
drivers/net/npe/IxNpeDlImageMgr.c
drivers/net/npe/IxNpeDlNpeMgr.c
drivers/net/npe/IxNpeMh.c
drivers/net/npe/IxNpeMhConfig.c
drivers/net/npe/IxNpeMhSend.c
drivers/net/npe/IxOsalOsSemaphore.c
drivers/net/npe/IxQMgrDispatcher.c
drivers/net/npe/IxQMgrInit.c
drivers/net/npe/IxQMgrQCfg.c
drivers/net/npe/npe.c
drivers/rtc/ds1374.c
drivers/serial/usbtty.c
drivers/video/da8xx-fb.c
drivers/video/mxc_ipuv3_fb.c
fs/ext4/ext4_journal.c
include/configs/bf537-stamp.h
include/dp83848.h
include/linux/fb.h
include/linux/mtd/nand.h
include/linux/types.h
include/MCD_dma.h
include/pcmcia/ti113x.h
include/radeon.h
include/sym53c8xx.h
include/usb_cdc_acm.h
include/usbdevice.h
README
tools/bddb/defs.php
-Allen
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mxs: mxsboot: Add support for SD card generation for i.MX23
The mxsboot now receives the SoC type as parameter to generate binary
compatible with the SoC. Currently the NAND support has not been add
for i.MX23 as it is not yet supported in U-Boot.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
doc/README.mx28_common | 4 +--
tools/mxsboot.c| 92 --
2 files changed, 83 insertions(+), 13 deletions(-)
diff --git a/doc/README.mx28_common b/doc/README.mx28_common
index 8bacaf8..f0a5112 100644
--- a/doc/README.mx28_common
+++ b/doc/README.mx28_common
@@ -134,7 +134,7 @@ The partition layout is ready, next the special partition
must be filled with
proper contents. The contents is generated by running the following command
(see chapter 2)):
- $ ./tools/mxsboot sd u-boot.sb u-boot.sd
+ $ ./tools/mxsboot mx28 sd u-boot.sb u-boot.sd
The resulting file, u-boot.sd, shall then be written to the partition. In
this
case, we assume the first partition of the SD card is /dev/mmcblk0p1:
@@ -162,7 +162,7 @@ There are two possibilities when preparing an image
writable to NAND flash.
there is a tool called mxsboot in the tools/ directory. The tool
is invoked on u-boot.sb file from chapter 2):
-$ ./tools/mxsboot nand u-boot.sb u-boot.nand
+$ ./tools/mxsboot mx28 nand u-boot.sb u-boot.nand
NOTE: The above invokation works for NAND flash with geometry of
2048b per page, 64b OOB data, 128kb erase size. If your chip
diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index 6c05aa4..e348877 100644
--- a/tools/mxsboot.c
+++ b/tools/mxsboot.c
@@ -1,7 +1,7 @@
/*
- * Freescale i.MX28 image generator
+ * Freescale i.MX23/i.MX28 image generator
*
- * Copyright (C) 2011 Marek Vasut marek.va...@gmail.com
+ * Copyright (C) 2011, 2013 Marek Vasut marek.va...@gmail.com
* on behalf of DENX Software Engineering GmbH
*
* See file CREDITS for list of people who contributed to this
@@ -49,6 +49,11 @@ uint32_t nand_oobsize = 64;
uint32_t nand_erasesize = 128 * 1024;
/*
+ * SoC type
+ */
+enum { MX23, MX28 } soc_type;
+
+/*
* Sector on which the SigmaTel boot partition (0x53) starts.
*/
uint32_t sd_sector = 2048;
@@ -125,6 +130,13 @@ struct mx28_nand_bbt {
uint32_tbadblock[510];
};
+struct mx23_sd_config_block {
+ uint32_treserved1[2];
+ uint32_tfirst_sector_number;
+ uint32_treserved2;
+ uint32_tsector_count;
+};
+
struct mx28_sd_drive_info {
uint32_tchip_num;
uint32_tdrive_type;
@@ -453,9 +465,10 @@ static int mx28_nand_write_firmware(struct mx28_nand_fcb
*fcb, int infd,
void usage(void)
{
printf(
- Usage: mxsboot [ops] type infile outfile\n
- Augment BootStream file with a proper header for i.MX28 boot\n
+ Usage: mxsboot [ops] soc type infile outfile\n
+ Augment BootStream file with a proper header for i.MX23/i.MX28
boot\n
\n
+ soc\mx23\ or \mx28\\n
type type of image:\n
\nand\ for NAND image\n
\sd\ for SD image\n
@@ -540,6 +553,50 @@ err0:
return ret;
}
+static int mx23_create_sd_image(int infd, int outfd)
+{
+ int ret = -1;
+ uint32_t *buf;
+ int size;
+ off_t fsize;
+ ssize_t wr_size;
+ ssize_t offset = 512 * 4;
+ struct mx23_sd_config_block *cb;
+
+ fsize = lseek(infd, 0, SEEK_END);
+ lseek(infd, 0, SEEK_SET);
+ size = fsize + offset;
+
+ buf = malloc(size);
+ if (!buf) {
+ printf(Can not allocate output buffer of %d bytes\n, size);
+ goto err0;
+ }
+
+ ret = read(infd, (uint8_t *)buf + offset, fsize);
+ if (ret != fsize) {
+ ret = -1;
+ goto err1;
+ }
+
+ cb = (struct mx23_sd_config_block *)buf;
+
+ cb-first_sector_number = sd_sector + 1;
+ cb-sector_count = (size - 1) / 512;
+ wr_size = write(outfd, buf, size);
+ if (wr_size != size) {
+ ret = -1;
+ goto err1;
+ }
+
+ ret = 0;
+
+err1:
+ free(buf);
+err0:
+ return ret;
+}
+
static int mx28_create_sd_image(int infd, int outfd)
{
int ret = -1;
@@ -576,7 +633,6 @@ static int mx28_create_sd_image(int infd, int outfd)
cb-drv_info[0].tag = 0x1;
cb-drv_info[0].first_sector_number = sd_sector + 1;
cb-drv_info[0].sector_count = (size - 1) / 512;
-
wr_size = write(outfd, buf, size);
if (wr_size != size) {
ret = -1;
@@ -606,7 +662,7 @@ int parse_ops(int argc, char **argv)
};
int type;
- if (argc 4)
+ if (argc 5)
return -1;
for (i = 1; i argc; i++) {
@@
Re: [U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux
Hi Lucas,
On Fri, Jan 25, 2013 at 5:48 AM, Lucas Stach d...@lynxeye.de wrote:
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
board/nvidia/seaboard/seaboard.c | 133
+--
include/configs/seaboard.h | 3 +
include/configs/ventana.h| 3 +
3 files changed, 121 insertions(+), 18 deletions(-)
This seems like a lot of code and presumably quite a bit of
duplication between boards. What sort of conflicts does this avoid,
and is it the only way of avoiding them?
Also, how does this deal with drivers that want to support different
configurations, such as 4/8 bit MMC, UART flow control, etc.? How does
this fit with what the device tree pinmux specifies in the kernel, and
why would we not move to using that?
Regards,
Simon
diff --git a/board/nvidia/seaboard/seaboard.c
b/board/nvidia/seaboard/seaboard.c
index 3e33da0..b5b4b31 100644
--- a/board/nvidia/seaboard/seaboard.c
+++ b/board/nvidia/seaboard/seaboard.c
@@ -1,6 +1,8 @@
/*
* (C) Copyright 2010,2011
* NVIDIA Corporation www.nvidia.com
+ * (C) Copyright 2013
+ * Lucas Stach
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -25,7 +27,6 @@
#include asm/io.h
#include asm/arch/tegra.h
#include asm/arch/clock.h
-#include asm/arch/funcmux.h
#include asm/arch/gpio.h
#include asm/arch/pinmux.h
#include asm/arch-tegra/mmc.h
@@ -47,29 +48,12 @@ void gpio_early_init_uart(void)
#endif
#ifdef CONFIG_TEGRA_MMC
-/*
- * Routine: pin_mux_mmc
- * Description: setup the pin muxes/tristate values for the SDMMC(s)
- */
-static void pin_mux_mmc(void)
-{
- funcmux_select(PERIPH_ID_SDMMC4, FUNCMUX_SDMMC4_ATB_GMA_GME_8_BIT);
- funcmux_select(PERIPH_ID_SDMMC3, FUNCMUX_SDMMC3_SDB_4BIT);
-
- /* For power GPIO PI6 */
- pinmux_tristate_disable(PINGRP_ATA);
- /* For CD GPIO PI5 */
- pinmux_tristate_disable(PINGRP_ATC);
-}
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
debug(board_mmc_init called\n);
- /* Enable muxes, etc. for SDMMC controllers */
- pin_mux_mmc();
-
debug(board_mmc_init: init eMMC\n);
/* init dev 0, eMMC chip, with 8-bit bus */
tegra_mmc_init(0, 8, -1, -1);
@@ -87,3 +71,116 @@ void pin_mux_usb(void)
/* For USB's GPIO PD0. For now, since we have no pinmux in fdt */
pinmux_tristate_disable(PINGRP_SLXK);
}
+static struct pingroup_config seaboard_pinmux[] = {
+ PINMUX_ENTRY(ATA, IDE, NORMAL, NORMAL), /* GPIO PI6 */
+ PINMUX_ENTRY(ATB, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(ATC, NAND, NORMAL, NORMAL), /* NAND, GPIO PI5 */
+ PINMUX_ENTRY(ATD, GMI, NORMAL, NORMAL), /* NAND, GPIO PH1,PH3 */
+ PINMUX_ENTRY(ATE, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV1, PLLA_OUT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CDEV2, PLLP_OUT4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CRTP, CRT, NORMAL, TRISTATE),
+ PINMUX_ENTRY(CSUS, VI_SENSOR_CLK, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP1, DAP1, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP2, DAP2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP3, DAP3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DAP4, DAP4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DDC, I2C2, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTA, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTB, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTC, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTD, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTE, VI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(DTF, I2C3, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMA, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(GMB, GMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GMC, UARTD, NORMAL, NORMAL), /* UART D */
+ PINMUX_ENTRY(GMD, SFLASH, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GME, SDIO4, NORMAL, NORMAL), /* SDMMC4 */
+ PINMUX_ENTRY(GPU, PWM, NORMAL, TRISTATE),
+ PINMUX_ENTRY(GPU7, RTCK, NORMAL, NORMAL), /* JTAG RTCK */
+ PINMUX_ENTRY(GPV, PCIE, NORMAL, TRISTATE),
+ PINMUX_ENTRY(HDINT, HDMI, NORMAL, TRISTATE),
+ PINMUX_ENTRY(I2CP, I2C, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRRX, UARTB, NORMAL, TRISTATE),
+ PINMUX_ENTRY(IRTX, UARTB, NORMAL, TRISTATE),
+ PINMUX_ENTRY(KBCA, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(KBCB, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(KBCC, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(KBCD, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(KBCE, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(KBCF, KBC, UP, NORMAL), /* KBC */
+ PINMUX_ENTRY(LCSN, RSVD4, NORMAL, TRISTATE),
+ PINMUX_ENTRY(LD0, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD1, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD2, DISPA, NORMAL, NORMAL), /* LCD */
+ PINMUX_ENTRY(LD3,
Re: [U-Boot] [Patch v3] Consolidate bool type
On 01/24/2013 09:34 AM, Allen Martin wrote:
On Wed, Jan 23, 2013 at 02:05:26PM -0800, York Sun wrote:
On 01/23/2013 02:02 PM, Scott Wood wrote:
On 01/23/2013 04:01:49 PM, York Sun wrote:
On 01/23/2013 01:52 PM, Scott Wood wrote:
On 01/23/2013 03:46:04 PM, York Sun wrote:
On 01/23/2013 01:41 PM, York Sun wrote:
I should put RFC in the subject as I am not able to compile all ARCH
myself.
So how do you see this patch becoming non-RFC? I think most people
don't have every single toolchain. You should at least get a toolchain
for a couple major architectures such as ARM. Usually RFC is for when
you know the patch has issues, and don't want it applied yet even if
nobody else finds fault with it.
I know this version has problem. I am hoping more people get involved
and test what they can. I tried the arm toolchain you pointed to me. I
couldn't run MAKEALL for arm.
Even before your patch, using USE_PRIVATE_LIBGCC? How many boards failed?
I don't know. Wolfgang brought it. Allen kindly offered help to verify
on tegra which uses USE_PRIVATE_LIBGCC.
Built and tested on tegra, no problems. I'm still seeing a lot of
references to TRUE/FALSE even after this patch though:
$ git grep -e FALSE -e TRUE | awk 'BEGIN {FS = :} {print $1}' | sort | uniq
Thanks, Allen. A long way to go.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mxs: mxsboot: Add support for SD card generation for i.MX23
Dear Otavio Salvador, The mxsboot now receives the SoC type as parameter to generate binary compatible with the SoC. Currently the NAND support has not been add for i.MX23 as it is not yet supported in U-Boot. Please fix the NAND support as well, then resubmit. The patch basically does dd if=u-boot.sb ... bs=512 seek=4 ; any kind of information can be stored in those first four blocks and the mx23 bootrom ignores it, so what's the gain of this? I wonder, will MX28 bootrom ignore them as well? Then maybe we can get rid of all this SD-specific junk. Furthermore, I'd like to see all of this reworked as another plugin for mkimage. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tegra: Move common clock code to arch/arm/cpu/tegra-common/clock.c
On Thu, Jan 24, 2013 at 11:33 AM, Tom Warren twarren.nvi...@gmail.com wrote: This 'commonizes' much of the clock/pll code. SoC-dependent code and tables are left in arch/cpu/tegraXXX-common/clock.c Some T30 tables needed whitespace fixes due to checkpatch complaints. Signed-off-by: Tom Warren twar...@nvidia.com Acked-by: Simon Glass s...@chromium.org Tom this is a big improvement, thank you. --- arch/arm/cpu/tegra-common/Makefile |2 +- arch/arm/cpu/tegra-common/clock.c| 560 + arch/arm/cpu/tegra20-common/clock.c | 605 +-- arch/arm/cpu/tegra30-common/clock.c | 712 -- arch/arm/include/asm/arch-tegra/clock.h | 59 ++- arch/arm/include/asm/arch-tegra20/clock-tables.h |4 + arch/arm/include/asm/arch-tegra20/tegra.h|2 + arch/arm/include/asm/arch-tegra30/tegra.h|2 + 8 files changed, 760 insertions(+), 1186 deletions(-) create mode 100644 arch/arm/cpu/tegra-common/clock.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mxs: mxsboot: Add support for SD card generation for i.MX23
On Thu, Jan 24, 2013 at 3:56 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, The mxsboot now receives the SoC type as parameter to generate binary compatible with the SoC. Currently the NAND support has not been add for i.MX23 as it is not yet supported in U-Boot. Please fix the NAND support as well, then resubmit. I won't work on NAND now; first I wish to fix the NAND driver support to later work in boot support. The patch basically does dd if=u-boot.sb ... bs=512 seek=4 ; any kind of information can be stored in those first four blocks and the mx23 bootrom ignores it, so what's the gain of this? Well, it works fine for users. A good gain in my opinion. I wonder, will MX28 bootrom ignore them as well? Then maybe we can get rid of all this SD-specific junk. Did not test but MX28 expects a BCB data structure (as said in 12.11.2 - MX28RM) while MX23 does not. So I think MX28 won't work without the BCB. Furthermore, I'd like to see all of this reworked as another plugin for mkimage. Yes; it would be a good long term solution but I don't want to hold it due any of above reasons. It works fine so improvements can be done later. Regards, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3] Consolidate bool type
On 01/24/2013 09:54 AM, York Sun wrote:
On 01/24/2013 09:34 AM, Allen Martin wrote:
On Wed, Jan 23, 2013 at 02:05:26PM -0800, York Sun wrote:
On 01/23/2013 02:02 PM, Scott Wood wrote:
On 01/23/2013 04:01:49 PM, York Sun wrote:
On 01/23/2013 01:52 PM, Scott Wood wrote:
On 01/23/2013 03:46:04 PM, York Sun wrote:
On 01/23/2013 01:41 PM, York Sun wrote:
I should put RFC in the subject as I am not able to compile all ARCH
myself.
So how do you see this patch becoming non-RFC? I think most people
don't have every single toolchain. You should at least get a toolchain
for a couple major architectures such as ARM. Usually RFC is for when
you know the patch has issues, and don't want it applied yet even if
nobody else finds fault with it.
I know this version has problem. I am hoping more people get involved
and test what they can. I tried the arm toolchain you pointed to me. I
couldn't run MAKEALL for arm.
Even before your patch, using USE_PRIVATE_LIBGCC? How many boards failed?
I don't know. Wolfgang brought it. Allen kindly offered help to verify
on tegra which uses USE_PRIVATE_LIBGCC.
Built and tested on tegra, no problems. I'm still seeing a lot of
references to TRUE/FALSE even after this patch though:
$ git grep -e FALSE -e TRUE | awk 'BEGIN {FS = :} {print $1}' | sort | uniq
Thanks, Allen. A long way to go.
I thought I have replaced all #define, enum, typedef. I have left alone
those FALSE, False, false but add define like this
+#include stdbool.h
+#define TRUE true
+#define FALSE false
+#define True true
+#define False false
Isn't that enough?
I did miss the #if TRUE != 1 part, as pointed out by Scott. Will fix in
next rev.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mxs: mxsboot: Add support for SD card generation for i.MX23
Dear Otavio Salvador, On Thu, Jan 24, 2013 at 3:56 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, The mxsboot now receives the SoC type as parameter to generate binary compatible with the SoC. Currently the NAND support has not been add for i.MX23 as it is not yet supported in U-Boot. Please fix the NAND support as well, then resubmit. I won't work on NAND now; first I wish to fix the NAND driver support to later work in boot support. The patch basically does dd if=u-boot.sb ... bs=512 seek=4 ; any kind of information can be stored in those first four blocks and the mx23 bootrom ignores it, so what's the gain of this? Well, it works fine for users. A good gain in my opinion. How is a simple documented dd if=... different? It's the same on imx, you have to dd u-boot.imx with some offset. I wonder, will MX28 bootrom ignore them as well? Then maybe we can get rid of all this SD-specific junk. Did not test but MX28 expects a BCB data structure (as said in 12.11.2 - MX28RM) while MX23 does not. So I think MX28 won't work without the BCB. Fabio? Furthermore, I'd like to see all of this reworked as another plugin for mkimage. Yes; it would be a good long term solution but I don't want to hold it due any of above reasons. It works fine so improvements can be done later. We already have a solution: dd if=u-boot.sb of=/dev/sdX1 bs=512 seek=4 I think this is enough for now, until all is fixed in proper sequence. That is, NAND driver and only after that, mxsboot for NAND _and_ SD . For now, let's hold off this patch, add the above dd stuff into documentation (doc/README.mx23) and then when all is ready, fix it all properly please. Regards, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] mx23: Fix transfer size setting for SPI
Dear Otavio Salvador,
NAK, this won't work. SSP0 DMA has this +1 offset in it's channel placement (so
SSP0 DMA channel is actually channel 1), check the MMC patch.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
drivers/spi/mxs_spi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
index bb865b7..10bf5aa 100644
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -167,8 +167,13 @@ static int mxs_spi_xfer_pio(struct mxs_spi_slave
*slave, mxs_spi_start_xfer(ssp_regs);
while (length--) {
+#if defined(CONFIG_MX23)
+ writel(SSP_CTRL0_XFER_COUNT_MASK, ssp_regs-hw_ssp_ctrl0_clr);
+ writel(1, ssp_regs-hw_ssp_ctrl0_set);
+#elif defined(CONFIG_MX28)
/* We transfer 1 byte */
writel(1, ssp_regs-hw_ssp_xfer_size);
+#endif
if ((flags SPI_XFER_END) !length)
mxs_spi_end_xfer(ssp_regs);
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3] Consolidate bool type
On 01/24/2013 12:03:49 PM, York Sun wrote:
On 01/24/2013 09:54 AM, York Sun wrote:
On 01/24/2013 09:34 AM, Allen Martin wrote:
On Wed, Jan 23, 2013 at 02:05:26PM -0800, York Sun wrote:
On 01/23/2013 02:02 PM, Scott Wood wrote:
On 01/23/2013 04:01:49 PM, York Sun wrote:
On 01/23/2013 01:52 PM, Scott Wood wrote:
On 01/23/2013 03:46:04 PM, York Sun wrote:
On 01/23/2013 01:41 PM, York Sun wrote:
I should put RFC in the subject as I am not able to compile
all ARCH
myself.
So how do you see this patch becoming non-RFC? I think most
people
don't have every single toolchain. You should at least get a
toolchain
for a couple major architectures such as ARM. Usually RFC is
for when
you know the patch has issues, and don't want it applied yet
even if
nobody else finds fault with it.
I know this version has problem. I am hoping more people get
involved
and test what they can. I tried the arm toolchain you pointed
to me. I
couldn't run MAKEALL for arm.
Even before your patch, using USE_PRIVATE_LIBGCC? How many
boards failed?
I don't know. Wolfgang brought it. Allen kindly offered help to
verify
on tegra which uses USE_PRIVATE_LIBGCC.
Built and tested on tegra, no problems. I'm still seeing a lot of
references to TRUE/FALSE even after this patch though:
$ git grep -e FALSE -e TRUE | awk 'BEGIN {FS = :} {print $1}' |
sort | uniq
Thanks, Allen. A long way to go.
I thought I have replaced all #define, enum, typedef. I have left
alone
those FALSE, False, false but add define like this
+#include stdbool.h
+#define TRUE true
+#define FALSE false
+#define True true
+#define False false
Isn't that enough?
It's enough to make it build, but it would be better to fix the users.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] mxs: dma: Fix APBH DMA driver for MX23
On 23/01/2013 02:01, Marek Vasut wrote:
The MX23 has less channels for the APBH DMA, sligtly different register
layout and some bits in those registers are placed differently. Reflect
this in the driver. This patch fixes MMC/DMA issue on MX23.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Stefano Babic sba...@denx.de
---
arch/arm/include/asm/arch-mxs/regs-apbh.h | 121
+
drivers/dma/apbh_dma.c| 10 ++-
2 files changed, 129 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-mxs/regs-apbh.h
b/arch/arm/include/asm/arch-mxs/regs-apbh.h
index e18e677..fcef4b8 100644
--- a/arch/arm/include/asm/arch-mxs/regs-apbh.h
+++ b/arch/arm/include/asm/arch-mxs/regs-apbh.h
@@ -29,6 +29,87 @@
#include asm/arch/regs-common.h
#ifndef __ASSEMBLY__
+
+#if defined(CONFIG_MX23)
+struct mxs_apbh_regs {
+ mxs_reg_32(hw_apbh_ctrl0)
+ mxs_reg_32(hw_apbh_ctrl1)
+ mxs_reg_32(hw_apbh_ctrl2)
+ mxs_reg_32(hw_apbh_channel_ctrl)
I see there are diffrent definitions, but why do not we set a common
name (as an alias) ?
Such as:
#define hw_ahph_ctrl_set hw_apbh_ctrl0
+#if defined(CONFIG_MX23)
+ uint32_t setreg = (uint32_t)(apbh_regs-hw_apbh_ctrl0_set);
+ uint32_t offset = APBH_CTRL0_RESET_CHANNEL_OFFSET;
and we could drop the #ifdef in the driver file.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux
Am Freitag, den 25.01.2013, 06:54 +1300 schrieb Simon Glass: Hi Lucas, On Fri, Jan 25, 2013 at 5:48 AM, Lucas Stach d...@lynxeye.de wrote: Init pinmux in one shot, in order to avoid any conflicts. Signed-off-by: Lucas Stach d...@lynxeye.de --- board/nvidia/seaboard/seaboard.c | 133 +-- include/configs/seaboard.h | 3 + include/configs/ventana.h| 3 + 3 files changed, 121 insertions(+), 18 deletions(-) This seems like a lot of code and presumably quite a bit of duplication between boards. What sort of conflicts does this avoid, and is it the only way of avoiding them? I don't see it as duplication, but as explicitly spelling out how the pinmux configuration should be set up on a certain board. Before this change we would leave some pads uninitialised in their (random) reset configuration. For example on the Colibri this leads to NAND not working as it's wired up to the KBC pads. If we only configure those, ATC will remain in it's reset state and would be also configured to the NAND function, which leads to fail. Having an explicit, known to be conflict free configuration for all pads avoids all those unpleasant surprises. Also, how does this deal with drivers that want to support different configurations, such as 4/8 bit MMC, UART flow control, etc.? How does this fit with what the device tree pinmux specifies in the kernel, and why would we not move to using that? This is just the pinmux. You have to make sure to match the pinmux with your driver configuration. This tablebased approach is the same thing as what is done with Tegra30 in U-Boot. It's not as runtime flexible as the pinmux used in the Linux kernel, but also quite a fair bit simpler. I don't see any platform that would need anything other than the default configuration in U-Boot, so we don't need the muxing stuff provided by the pinmux framework in the kernel. While running U-Boot we want to keep most of the pads in tristate and just enable the ones used by U-Boot itself (boot devices, GPIOs, LCD pins, etc.), so using the plain kernel pinmux config isn't going to work. So I think the table based approach is a good compromise between the need of having an comprehensively defined pinmux, simplicity and effort needed to define the pinmux. Regards, Lucas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3] Consolidate bool type
On 01/24/2013 10:14 AM, Scott Wood wrote: I thought I have replaced all #define, enum, typedef. I have left alone those FALSE, False, false but add define like this +#include stdbool.h +#define TRUE true +#define FALSE false +#define True true +#define False false Isn't that enough? It's enough to make it build, but it would be better to fix the users. Let me try to run a script to replace all of them to false and true. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] board: add support for amcore board
Dear Angelo Dureghello, In message 20130124161349.GA11311@sion.sysam you wrote: +/* reserve 128-4KB */ +#define CONFIG_SYS_MONITOR_BASE (CONFIG_SYS_FLASH_BASE + 0x400) +#define CONFIG_SYS_MONITOR_LEN ((128-4)*1024) Are you sure this is sufficient? For my board/case actually seems to be more than enough. I can still change this in the future. How big is your U-Boot image, then? I think it's a pretty long time since I haven't seen any image smaller than 128 kB... 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 There's nothing disgusting about it [the Companion]. It's just another life form, that's all. You get used to those things. -- McCoy, Metamorphosis, stardate 3219.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3] Consolidate bool type
On Thu, Jan 24, 2013 at 10:14:37AM -0800, Scott Wood wrote:
On 01/24/2013 12:03:49 PM, York Sun wrote:
On 01/24/2013 09:54 AM, York Sun wrote:
On 01/24/2013 09:34 AM, Allen Martin wrote:
On Wed, Jan 23, 2013 at 02:05:26PM -0800, York Sun wrote:
On 01/23/2013 02:02 PM, Scott Wood wrote:
On 01/23/2013 04:01:49 PM, York Sun wrote:
On 01/23/2013 01:52 PM, Scott Wood wrote:
On 01/23/2013 03:46:04 PM, York Sun wrote:
On 01/23/2013 01:41 PM, York Sun wrote:
I should put RFC in the subject as I am not able to compile
all ARCH
myself.
So how do you see this patch becoming non-RFC? I think most
people
don't have every single toolchain. You should at least get a
toolchain
for a couple major architectures such as ARM. Usually RFC is
for when
you know the patch has issues, and don't want it applied yet
even if
nobody else finds fault with it.
I know this version has problem. I am hoping more people get
involved
and test what they can. I tried the arm toolchain you pointed
to me. I
couldn't run MAKEALL for arm.
Even before your patch, using USE_PRIVATE_LIBGCC? How many
boards failed?
I don't know. Wolfgang brought it. Allen kindly offered help to
verify
on tegra which uses USE_PRIVATE_LIBGCC.
Built and tested on tegra, no problems. I'm still seeing a lot of
references to TRUE/FALSE even after this patch though:
$ git grep -e FALSE -e TRUE | awk 'BEGIN {FS = :} {print $1}' |
sort | uniq
Thanks, Allen. A long way to go.
I thought I have replaced all #define, enum, typedef. I have left
alone
those FALSE, False, false but add define like this
+#include stdbool.h
+#define TRUE true
+#define FALSE false
+#define True true
+#define False false
Isn't that enough?
It's enough to make it build, but it would be better to fix the users.
For code consistency I think it would be better to force everything to
use the lower case true/false. Otherwise this patch does nothing to
force new code to use the standardized version.
There may be some exception we want to make for unmodified 3rd party
libraries that are checked in, like lib/bzlib which uses True/False,
otherwise it makes it hard to take new code drops of those things.
-Allen
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3] Consolidate bool type
Dear York Sun, In message 51017785.9060...@freescale.com you wrote: I thought I have replaced all #define, enum, typedef. I have left alone those FALSE, False, false but add define like this +#include stdbool.h +#define TRUE true +#define FALSE false +#define True true +#define False false Arghh.. Isn't that enough? Please remove all such occurrences. Thanks. 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 1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mxs: mmc: Allow overriding default card detect implementation
On 23/01/2013 02:01, Marek Vasut wrote:
Some MXS based boards do not implement the card-detect signal. Allow
user to specify alternate card-detect implementation.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Stefano Babic sba...@denx.de
---
arch/arm/include/asm/arch-mxs/sys_proto.h |2 +-
board/bluegiga/apx4devkit/apx4devkit.c|2 +-
board/denx/m28evk/m28evk.c|2 +-
board/freescale/mx28evk/mx28evk.c |2 +-
board/schulercontrol/sc_sps_1/sc_sps_1.c |2 +-
drivers/mmc/mxsmmc.c | 16 ++--
6 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/arch-mxs/sys_proto.h
b/arch/arm/include/asm/arch-mxs/sys_proto.h
index 8aaf196..5bafde5 100644
--- a/arch/arm/include/asm/arch-mxs/sys_proto.h
+++ b/arch/arm/include/asm/arch-mxs/sys_proto.h
@@ -31,7 +31,7 @@ int mxs_wait_mask_clr(struct mxs_register_32 *reg,
uint32_t mask,
unsigned int timeout);
-int mxsmmc_initialize(bd_t *bis, int id, int (*wp)(int));
+int mxsmmc_initialize(bd_t *bis, int id, int (*wp)(int), int (*cd)(int));
#ifdef CONFIG_SPL_BUILD
diff --git a/board/bluegiga/apx4devkit/apx4devkit.c
b/board/bluegiga/apx4devkit/apx4devkit.c
index 029b973..5927693 100644
--- a/board/bluegiga/apx4devkit/apx4devkit.c
+++ b/board/bluegiga/apx4devkit/apx4devkit.c
@@ -69,7 +69,7 @@ int board_init(void)
#ifdef CONFIG_CMD_MMC
int board_mmc_init(bd_t *bis)
{
- return mxsmmc_initialize(bis, 0, NULL);
+ return mxsmmc_initialize(bis, 0, NULL, NULL);
I see, but it seems to me that mxs is doing different as other SOCs. If
there is nothing to set, cpu_mmc_init() should be used, dropping
board_mmc_init(). And we implement board_mmc_init() only for boards that
really need it, not for all.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] mxs: dma: Fix APBH DMA driver for MX23
Dear Stefano Babic,
On 23/01/2013 02:01, Marek Vasut wrote:
The MX23 has less channels for the APBH DMA, sligtly different register
layout and some bits in those registers are placed differently. Reflect
this in the driver. This patch fixes MMC/DMA issue on MX23.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Stefano Babic sba...@denx.de
---
arch/arm/include/asm/arch-mxs/regs-apbh.h | 121
+ drivers/dma/apbh_dma.c
| 10 ++-
2 files changed, 129 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-mxs/regs-apbh.h
b/arch/arm/include/asm/arch-mxs/regs-apbh.h index e18e677..fcef4b8
100644
--- a/arch/arm/include/asm/arch-mxs/regs-apbh.h
+++ b/arch/arm/include/asm/arch-mxs/regs-apbh.h
@@ -29,6 +29,87 @@
#include asm/arch/regs-common.h
#ifndef__ASSEMBLY__
+
+#if defined(CONFIG_MX23)
+struct mxs_apbh_regs {
+ mxs_reg_32(hw_apbh_ctrl0)
+ mxs_reg_32(hw_apbh_ctrl1)
+ mxs_reg_32(hw_apbh_ctrl2)
+ mxs_reg_32(hw_apbh_channel_ctrl)
I see there are diffrent definitions, but why do not we set a common
name (as an alias) ?
Such as:
#define hw_ahph_ctrl_set hw_apbh_ctrl0
+#if defined(CONFIG_MX23)
+ uint32_t setreg = (uint32_t)(apbh_regs-hw_apbh_ctrl0_set);
+ uint32_t offset = APBH_CTRL0_RESET_CHANNEL_OFFSET;
and we could drop the #ifdef in the driver file.
Oh this junk. On mx23, this bitfield is located in ctrl0 at offset 16 ; on mx28
there's a dedicated register for this bitfield (since mx28 has 16 dma channels,
mx23 has only 8).
So it's a bit confusing, but that's how it has to be done.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3] Consolidate bool type
On Thu, Jan 24, 2013 at 10:23:21AM -0800, York Sun wrote: On 01/24/2013 10:14 AM, Scott Wood wrote: I thought I have replaced all #define, enum, typedef. I have left alone those FALSE, False, false but add define like this +#include stdbool.h +#define TRUE true +#define FALSE false +#define True true +#define False false Isn't that enough? It's enough to make it build, but it would be better to fix the users. Let me try to run a script to replace all of them to false and true. York Try this: $ find . -type f -name \*.h -print | xargs perl -pi -e 's/(\b)FALSE(\b)/$1false$2/g' $ find . -type f -name \*.h -print | xargs perl -pi -e 's/(\b)TRUE(\b)/$1true$2/g' $ find . -type f -name \*.c -print | xargs perl -pi -e 's/(\b)FALSE(\b)/$1false$2/g' $ find . -type f -name \*.c -print | xargs perl -pi -e 's/(\b)TRUE(\b)/$1true$2/g' $ find . -type f -name \*.h -print | xargs perl -pi -e 's/(\b)False(\b)/$1false$2/g' $ find . -type f -name \*.h -print | xargs perl -pi -e 's/(\b)True(\b)/$1true$2/g' $ find . -type f -name \*.c -print | xargs perl -pi -e 's/(\b)False(\b)/$1false$2/g' $ find . -type f -name \*.c -print | xargs perl -pi -e 's/(\b)True(\b)/$1true$2/g' -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mxs: mmc: Allow overriding default card detect implementation
Dear Stefano Babic,
On 23/01/2013 02:01, Marek Vasut wrote:
Some MXS based boards do not implement the card-detect signal. Allow
user to specify alternate card-detect implementation.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Stefano Babic sba...@denx.de
---
arch/arm/include/asm/arch-mxs/sys_proto.h |2 +-
board/bluegiga/apx4devkit/apx4devkit.c|2 +-
board/denx/m28evk/m28evk.c|2 +-
board/freescale/mx28evk/mx28evk.c |2 +-
board/schulercontrol/sc_sps_1/sc_sps_1.c |2 +-
drivers/mmc/mxsmmc.c | 16 ++--
6 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/arch-mxs/sys_proto.h
b/arch/arm/include/asm/arch-mxs/sys_proto.h index 8aaf196..5bafde5
100644
--- a/arch/arm/include/asm/arch-mxs/sys_proto.h
+++ b/arch/arm/include/asm/arch-mxs/sys_proto.h
@@ -31,7 +31,7 @@ int mxs_wait_mask_clr(struct mxs_register_32 *reg,
uint32_t mask,
unsigned int timeout);
-int mxsmmc_initialize(bd_t *bis, int id, int (*wp)(int));
+int mxsmmc_initialize(bd_t *bis, int id, int (*wp)(int), int
(*cd)(int));
#ifdef CONFIG_SPL_BUILD
diff --git a/board/bluegiga/apx4devkit/apx4devkit.c
b/board/bluegiga/apx4devkit/apx4devkit.c index 029b973..5927693 100644
--- a/board/bluegiga/apx4devkit/apx4devkit.c
+++ b/board/bluegiga/apx4devkit/apx4devkit.c
@@ -69,7 +69,7 @@ int board_init(void)
#ifdef CONFIG_CMD_MMC
int board_mmc_init(bd_t *bis)
{
- return mxsmmc_initialize(bis, 0, NULL);
+ return mxsmmc_initialize(bis, 0, NULL, NULL);
I see, but it seems to me that mxs is doing different as other SOCs. If
there is nothing to set, cpu_mmc_init() should be used, dropping
board_mmc_init(). And we implement board_mmc_init() only for boards that
really need it, not for all.
That's also an option ... do you want subsequent patch or respin of the series?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mxs: mxsboot: Add support for SD card generation for i.MX23
On Thu, Jan 24, 2013 at 4:08 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, On Thu, Jan 24, 2013 at 3:56 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, The mxsboot now receives the SoC type as parameter to generate binary compatible with the SoC. Currently the NAND support has not been add for i.MX23 as it is not yet supported in U-Boot. Please fix the NAND support as well, then resubmit. I won't work on NAND now; first I wish to fix the NAND driver support to later work in boot support. The patch basically does dd if=u-boot.sb ... bs=512 seek=4 ; any kind of information can be stored in those first four blocks and the mx23 bootrom ignores it, so what's the gain of this? Well, it works fine for users. A good gain in my opinion. How is a simple documented dd if=... different? It's the same on imx, you have to dd u-boot.imx with some offset. I wonder, will MX28 bootrom ignore them as well? Then maybe we can get rid of all this SD-specific junk. Did not test but MX28 expects a BCB data structure (as said in 12.11.2 - MX28RM) while MX23 does not. So I think MX28 won't work without the BCB. Fabio? Furthermore, I'd like to see all of this reworked as another plugin for mkimage. Yes; it would be a good long term solution but I don't want to hold it due any of above reasons. It works fine so improvements can be done later. We already have a solution: dd if=u-boot.sb of=/dev/sdX1 bs=512 seek=4 I think this is enough for now, until all is fixed in proper sequence. That is, NAND driver and only after that, mxsboot for NAND _and_ SD . For now, let's hold off this patch, add the above dd stuff into documentation (doc/README.mx23) and then when all is ready, fix it all properly please. Well; you blocked olinuxino patch until mxsboot where ported and the dd with offset were not a solution for you, ... so ... I prefer to have this as is and share documentation with mx28. The NAND ought to be done providing same interface so one doc for it all. I think change it in next version is wrong and confuse users. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mxs: mmc: Allow overriding default card detect implementation
On 24/01/2013 19:29, Marek Vasut wrote: That's also an option ... do you want subsequent patch or respin of the series? If I can choose, I prefer a respin of series, but I will surely not block the patchset if you send subsequent patches... Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mxs: mmc: Allow overriding default card detect implementation
Dear Stefano Babic,
[...]
diff --git a/board/bluegiga/apx4devkit/apx4devkit.c
b/board/bluegiga/apx4devkit/apx4devkit.c index 029b973..5927693 100644
--- a/board/bluegiga/apx4devkit/apx4devkit.c
+++ b/board/bluegiga/apx4devkit/apx4devkit.c
@@ -69,7 +69,7 @@ int board_init(void)
#ifdef CONFIG_CMD_MMC
int board_mmc_init(bd_t *bis)
{
- return mxsmmc_initialize(bis, 0, NULL);
+ return mxsmmc_initialize(bis, 0, NULL, NULL);
I see, but it seems to me that mxs is doing different as other SOCs. If
there is nothing to set, cpu_mmc_init() should be used, dropping
board_mmc_init(). And we implement board_mmc_init() only for boards that
really need it, not for all.
That's also an option ... do you want subsequent patch or respin of the
series?
Actually, check how it's distributed:
$ git grep mxsmmc_initialize board | sed s@.*/@@
apx4devkit.c: return mxsmmc_initialize(bis, 0, NULL, NULL);
m28evk.c: return mxsmmc_initialize(bis, 0, m28_mmc_wp, NULL);
mx28evk.c: return mxsmmc_initialize(bis, 0, mx28evk_mmc_wp, NULL);
mx23_olinuxino.c: return mxsmmc_initialize(bis, 0, NULL, mx23_olx_mmc_cd);
sc_sps_1.c: return mxsmmc_initialize(bis, 0, NULL, NULL);
We have quite a bit of variance there. I wonder if using cpu_mmc_init() is
worth
it.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mxs: mxsboot: Add support for SD card generation for i.MX23
Dear Otavio Salvador,
On Thu, Jan 24, 2013 at 4:08 PM, Marek Vasut ma...@denx.de wrote:
Dear Otavio Salvador,
On Thu, Jan 24, 2013 at 3:56 PM, Marek Vasut ma...@denx.de wrote:
Dear Otavio Salvador,
The mxsboot now receives the SoC type as parameter to generate binary
compatible with the SoC. Currently the NAND support has not been add
for i.MX23 as it is not yet supported in U-Boot.
Please fix the NAND support as well, then resubmit.
I won't work on NAND now; first I wish to fix the NAND driver support
to later work in boot support.
The patch basically does dd if=u-boot.sb ... bs=512 seek=4 ; any kind
of information can be stored in those first four blocks and the mx23
bootrom ignores it, so what's the gain of this?
Well, it works fine for users. A good gain in my opinion.
How is a simple documented dd if=... different? It's the same on imx, you
have to dd u-boot.imx with some offset.
I wonder, will MX28 bootrom ignore them as well? Then maybe we can get
rid of all this SD-specific junk.
Did not test but MX28 expects a BCB data structure (as said in 12.11.2
- MX28RM) while MX23 does not. So I think MX28 won't work without the
BCB.
Fabio?
Furthermore, I'd like to see all of this reworked as another plugin
for mkimage.
Yes; it would be a good long term solution but I don't want to hold it
due any of above reasons. It works fine so improvements can be done
later.
We already have a solution:
dd if=u-boot.sb of=/dev/sdX1 bs=512 seek=4
I think this is enough for now, until all is fixed in proper sequence.
That is, NAND driver and only after that, mxsboot for NAND _and_ SD .
For now, let's hold off this patch, add the above dd stuff into
documentation (doc/README.mx23) and then when all is ready, fix it all
properly please.
Well; you blocked olinuxino patch until mxsboot where ported and the
dd with offset were not a solution for you, ... so ...
So, Fabio, can you please explain this to me? How does the SD boot work on mx23?
Does the inlined patch work on MX23 and MX28? We can use that as a temporary
workaround.
I prefer to have this as is and share documentation with mx28. The
NAND ought to be done providing same interface so one doc for it all.
I think change it in next version is wrong and confuse users.
Make a doc/README.mx23 with quirks needed for MX23. Once the issues are ironed
out, adjust the readme. No problem.
PATCH:
diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index 6c05aa4..d92c39f 100644
--- a/tools/mxsboot.c
+++ b/tools/mxsboot.c
@@ -551,7 +551,7 @@ static int mx28_create_sd_image(int infd, int outfd)
fsize = lseek(infd, 0, SEEK_END);
lseek(infd, 0, SEEK_SET);
- size = fsize + 512;
+ size = fsize + 4 * 512;
buf = malloc(size);
if (!buf) {
@@ -559,7 +559,7 @@ static int mx28_create_sd_image(int infd, int outfd)
goto err0;
}
- ret = read(infd, (uint8_t *)buf + 512, fsize);
+ ret = read(infd, (uint8_t *)buf + 4 * 512, fsize);
if (ret != fsize) {
ret = -1;
goto err1;
@@ -574,8 +574,8 @@ static int mx28_create_sd_image(int infd, int outfd)
cb-drv_info[0].chip_num = 0x0;
cb-drv_info[0].drive_type = 0x0;
cb-drv_info[0].tag = 0x1;
- cb-drv_info[0].first_sector_number = sd_sector + 1;
- cb-drv_info[0].sector_count = (size - 1) / 512;
+ cb-drv_info[0].first_sector_number = sd_sector + 4;
+ cb-drv_info[0].sector_count = (size - 4) / 512;
wr_size = write(outfd, buf, size);
if (wr_size != size) {
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mxs: mmc: Allow overriding default card detect implementation
Dear Stefano Babic, On 24/01/2013 19:29, Marek Vasut wrote: That's also an option ... do you want subsequent patch or respin of the series? If I can choose, I prefer a respin of series, but I will surely not block the patchset if you send subsequent patches... No, scrap this. See my other email please. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] powerpc/lib: unsafe register handling in wait_ticks
Hi, Hi Mats I would appreciate if you CC me directly on stuff I have been involved in. I don't read every mail on u-boot list(to many of them). It was just plain luck I saw this one. If watchdog is enabled, the arch/powerpc/lib/ticks.S::wait_ticks() function calls the function specified by the WATCHDOG_RESET macro. The wait_ticks function depends on the registers r0, r6 and r7 being preserved however that is not guaranteed if the reset function is a C function. The following patch changes to using r14+r15 instead of r6+r7 and saves all necessary registers on the stack. This adds some extra churn to the code that my patch didn't do. On the other hand your patch makes the function look more like how gcc would have done so I am fine with that. However, I am not sure r14 is a good fit, I cannot remember if there is some special purpose for r14. Hopefully somebody on the list knows. As I'm quite fresh to PowerPC assembly language I would appreciate any feedback on the implementation. On a side note, one could wonder why this function is not written in C language to start with. History I guess, once upon a time this function didn't need(or could not use) the stack. Now it would be quite possible to change it into C. Best regards, Mats Kärrman --- a/arch/powerpc/lib/ticks.S +++ b/arch/powerpc/lib/ticks.S @@ -50,19 +50,24 @@ wait_ticks: stwu r1, -16(r1) mflr r0 /* save link register */ stw r0, 20(r1) /* Use r0 or GDB will be unhappy */ - mr r7, r3 /* save tick count */ + stw r14, 12(r1) /* save used registers */ + stw r15, 8(r1) + mr r14, r3 /* save tick count */ bl get_ticks /* Get start time */ /* Calculate end time */ - addcr7, r4, r7 /* Compute end time lower */ - addze r6, r3 /* and end time upper */ + addcr14, r4, r14 /* Compute end time lower */ + addze r15, r3 /* and end time upper */ WATCHDOG_RESET /* Trigger watchdog, if needed */ 1: bl get_ticks /* Get current time */ - subfc r4, r4, r7 /* Subtract current time from end time */ - subfe. r3, r3, r6 + subfc r4, r4, r14 /* Subtract current time from end time */ + subfe. r3, r3, r15 bge 1b /* Loop until time expired */ - mtlr r0 /* restore link register */ + lwz r15, 8(r1) /* restore saved registers */ + lwz r14, 12(r1) + lwz r0, 20(r1) addi r1,r1,16 + mtlr r0 blr ___ 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] [PATCH] MAKEALL: add support for per architecture toolchains
Add support for per architecture CROSS_COMPILE toolchain definitions
via CROSS_COMPILE_ARCH where ARCH is any of the supported u-boot
architectures. This allows building every supported u-boot board in a
single pass of MAKEALL.
Signed-off-by: Allen Martin amar...@nvidia.com
---
MAKEALL | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 5b06c54..18b4e4d 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -35,6 +35,9 @@ usage()
Environment variables:
BUILD_NCPUS number of parallel make jobs (default: auto)
CROSS_COMPILEcross-compiler toolchain prefix (default: )
+ CROSS_COMPILE_ARM cross-compiler toolchain prefix for
+ architecture ARM. Substitute ARM for any
+ supported architecture (default: )
MAKEALL_LOGDIR output all logs to here (default: ./LOG/)
BUILD_DIRoutput build directory (default: ./)
BUILD_NBUILDSnumber of parallel targets (default: 1)
@@ -180,13 +183,6 @@ else
JOBS=
fi
-
-if [ ${CROSS_COMPILE} ] ; then
- MAKE=make CROSS_COMPILE=${CROSS_COMPILE}
-else
- MAKE=make
-fi
-
if [ ${MAKEALL_LOGDIR} ] ; then
LOG_DIR=${MAKEALL_LOGDIR}
else
@@ -585,6 +581,18 @@ get_target_maintainers() {
echo $mail
}
+get_target_arch() {
+ local target=$1
+
+ # Automatic mode
+ local line=`egrep -i ^[[:space:]]*${target}[[:space:]] boards.cfg`
+
+ if [ -z ${line} ] ; then echo ; return ; fi
+
+ set ${line}
+ echo $2
+}
+
list_target() {
if [ $PRINT_MAINTS != 'y' ] ; then
echo $1
@@ -655,6 +663,16 @@ build_target() {
export BUILD_DIR=${output_dir}
+ target_arch=$(get_target_arch ${target})
+ eval cross_toolchain=\$CROSS_COMPILE_${target_arch^^}
+ if [ ${cross_toolchain} ] ; then
+ MAKE=make CROSS_COMPILE=${cross_toolchain}
+ elif [ ${CROSS_COMPILE} ] ; then
+ MAKE=make CROSS_COMPILE=${CROSS_COMPILE}
+ else
+ MAKE=make
+ fi
+
${MAKE} distclean /dev/null
${MAKE} -s ${target}_config
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3] Consolidate bool type
On 01/24/2013 10:28 AM, Allen Martin wrote: On Thu, Jan 24, 2013 at 10:23:21AM -0800, York Sun wrote: On 01/24/2013 10:14 AM, Scott Wood wrote: I thought I have replaced all #define, enum, typedef. I have left alone those FALSE, False, false but add define like this +#include stdbool.h +#define TRUE true +#define FALSE false +#define True true +#define False false Isn't that enough? It's enough to make it build, but it would be better to fix the users. Let me try to run a script to replace all of them to false and true. York Try this: $ find . -type f -name \*.h -print | xargs perl -pi -e 's/(\b)FALSE(\b)/$1false$2/g' $ find . -type f -name \*.h -print | xargs perl -pi -e 's/(\b)TRUE(\b)/$1true$2/g' $ find . -type f -name \*.c -print | xargs perl -pi -e 's/(\b)FALSE(\b)/$1false$2/g' $ find . -type f -name \*.c -print | xargs perl -pi -e 's/(\b)TRUE(\b)/$1true$2/g' $ find . -type f -name \*.h -print | xargs perl -pi -e 's/(\b)False(\b)/$1false$2/g' $ find . -type f -name \*.h -print | xargs perl -pi -e 's/(\b)True(\b)/$1true$2/g' $ find . -type f -name \*.c -print | xargs perl -pi -e 's/(\b)False(\b)/$1false$2/g' $ find . -type f -name \*.c -print | xargs perl -pi -e 's/(\b)True(\b)/$1true$2/g' Thanks. I used xargs sed -i s/\bTrue\b/true/g following your git grep. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] help on mmc driver
Hi Jagannadha,
Hi,
I need some help on mmc driver development on u-boot.
Few questions:
1. is mmc framework in u-boot supports all type of card interfaces
like SD, MMC, and eMMC
Yes there is a generic framework for MMC. - ./drivers/mmc/ {mmc.c}
2. If I write a driver do I need to develop
the common driver for all or a separate drivers for individual cards.
This is a generic framework. Normally you only need to write MMC
controller specific code to use it.
3. Is there any drivers in current u-boot drivers/mmc have individual
card interfaces support (SD MMC eMMC)
AS fair as I know there aren't any special drivers for any particular
vendor.
4. is there any drivers in
current u-boot driver/mmc for common card intefaces (SD | MMC | eMMC)
Yes, you can refer to mmc.c
One good example is the sdhci.c code which serves for SD cards and eMMC
(at least for Samsung).
Request for help.
Thanks,
Jagan.
This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s) confidential information that may
be proprietary, privileged or copyrighted under applicable law. If
you are not the intended recipient, do not read, copy, or forward
this email message or any attachments. Delete this email message and
any attachments immediately.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Best regards,
Lukasz Majewski
Samsung RD Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC Patch v5] Consolidate bool type
On 01/24/2013 12:47:10 PM, York Sun wrote: diff --git a/tools/patman/checkpatch.py b/tools/patman/checkpatch.py index d831087..28b3240 100644 --- a/tools/patman/checkpatch.py +++ b/tools/patman/checkpatch.py @@ -48,12 +48,12 @@ def FindCheckPatch(): print 'Could not find checkpatch.pl' return None -def CheckPatch(fname, verbose=False): +def CheckPatch(fname, verbose=false): Run checkpatch.pl on a file. Returns: 4-tuple containing: -result: False=failure, True=ok +result: false=failure, true=ok problems: List of problems, each a dict: 'type'; error or warning 'msg': text message You should probably limit the change to C code. :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC Patch v5] Consolidate bool type
On 01/24/2013 11:09 AM, Scott Wood wrote: On 01/24/2013 12:47:10 PM, York Sun wrote: diff --git a/tools/patman/checkpatch.py b/tools/patman/checkpatch.py index d831087..28b3240 100644 --- a/tools/patman/checkpatch.py +++ b/tools/patman/checkpatch.py @@ -48,12 +48,12 @@ def FindCheckPatch(): print 'Could not find checkpatch.pl' return None -def CheckPatch(fname, verbose=False): +def CheckPatch(fname, verbose=false): Run checkpatch.pl on a file. Returns: 4-tuple containing: -result: False=failure, True=ok +result: false=failure, true=ok problems: List of problems, each a dict: 'type'; error or warning 'msg': text message You should probably limit the change to C code. :-) Nice catch. I forgot Python use True and False. Will fix. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] powerpc/lib: unsafe register handling in wait_ticks
Dear Joakim Tjernlund, In message of52c94a3d.c3bd2e6f-onc1257afd.005bafe0-c1257afd.00673...@transmode.se you wrote: This adds some extra churn to the code that my patch didn't do. On the other hand your patch makes the function look more like how gcc would have done so I am fine with that. However, I am not sure r14 is a good fit, I cannot remember if there is some special purpose for r14. Hopefully somebody on the list knows. This is documented in the README: | For PowerPC, the following registers have specific use: | R1: stack pointer | R2: reserved for system use | R3-R4: parameter passing and return values | R5-R10: parameter passing | R13:small data area pointer | R30:GOT pointer | R31:frame pointer | | (U-Boot also uses R12 as internal GOT pointer. r12 | is a volatile register so r12 needs to be reset when | going back and forth between asm and C) | | == U-Boot will use R2 to hold a pointer to the global data | 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] [RFC Patch v5] Consolidate bool type
On Thu, Jan 24, 2013 at 11:13:27AM -0800, York Sun wrote: On 01/24/2013 11:09 AM, Scott Wood wrote: On 01/24/2013 12:47:10 PM, York Sun wrote: diff --git a/tools/patman/checkpatch.py b/tools/patman/checkpatch.py index d831087..28b3240 100644 --- a/tools/patman/checkpatch.py +++ b/tools/patman/checkpatch.py @@ -48,12 +48,12 @@ def FindCheckPatch(): print 'Could not find checkpatch.pl' return None -def CheckPatch(fname, verbose=False): +def CheckPatch(fname, verbose=false): Run checkpatch.pl on a file. Returns: 4-tuple containing: -result: False=failure, True=ok +result: false=failure, true=ok problems: List of problems, each a dict: 'type'; error or warning 'msg': text message You should probably limit the change to C code. :-) Nice catch. I forgot Python use True and False. Will fix. Omit tools/bddb/defs.php as well. I'm still not clear what the policy should be regarding 3rd party libraries that are checked into u-boot, but my opinion is they should stay as close to the original source as much as possible, so we should exclude them from this cleanup: lib/bzlib.c| 76 +- lib/bzlib_decompress.c | 20 +-- lib/bzlib_huffman.c|8 +- lib/bzlib_private.h|3 - lib/lzma/LzmaDec.c |2 +- lib/lzma/Types.h |3 - -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC Patch v5] Consolidate bool type
Dear York Sun, In message 1359053230-18920-1-git-send-email-york...@freescale.com you wrote: 'bool' is defined in random places. This patch consolidates them into a single header file include/linux/types.h, using stdbool.h introduced in C99. All other #define, typedef and enum are removed. They are all consistent with true = 1, false = 0. Replace FALSE, False with false. Replace TRUE, True with true. This patch also includes some type conversions that are unrelated; these should be split off into a separate commit. diff --git a/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c b/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c index 00e1c11..4caf3fd 100644 --- a/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c +++ b/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c @@ -517,7 +517,7 @@ void fsl_serdes_init(void) size_t arglen; #endif #ifdef CONFIG_SYS_P4080_ERRATUM_SERDES_A001 - int need_serdes_a001; /* TRUE == need work-around for SERDES A001 */ + bool need_serdes_a001; /* true == need work-around for SERDES A001 */ Like this one... 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 seems intuitively obvious to me, which means that it might be wrong. -- Chris Torek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] board: add support for amcore board
Dear Wolfgang, On Thu, Jan 24, 2013 at 07:24:11PM +0100, Wolfgang Denk wrote: Dear Angelo Dureghello, In message 20130124161349.GA11311@sion.sysam you wrote: +/* reserve 128-4KB */ +#define CONFIG_SYS_MONITOR_BASE(CONFIG_SYS_FLASH_BASE + 0x400) +#define CONFIG_SYS_MONITOR_LEN ((128-4)*1024) Are you sure this is sufficient? For my board/case actually seems to be more than enough. I can still change this in the future. How big is your U-Boot image, then? I think it's a pretty long time since I haven't seen any image smaller than 128 kB... -rwxr-xr-x 1 angelo angelo 88556 gen 22 22:31 u-boot.bin Best regards, Angelo Dureghello ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] board: add support for amcore board
Dear Angelo Dureghello, In message 20130124200736.GA19171@sion.sysam you wrote: How big is your U-Boot image, then? I think it's a pretty long time since I haven't seen any image smaller than 128 kB... -rwxr-xr-x 1 angelo angelo 88556 gen 22 22:31 u-boot.bin Wow, that's just great :-) Thanks. 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 Living on Earth may be expensive, but it includes an annual free trip around the Sun. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] tegra: fdt: sort dts files
Sort nodes in dts files according the the following rules:
1) Any nodes that already exist in any /include/d file, in the order
they appear in the /include/d file.
2) Any nodes with a reg property, in order of their address.
3) Any nodes without a reg property, alphabetically by node name.
Signed-off-by: Allen Martin amar...@nvidia.com
Signed-off-by: Tom Warren twar...@nvidia.com
---
v2: Added back host1x node that got dropped from seaboard by mistake.
As an added precaution I verified each file touched by this patch by
running it through sort before and after the patch and confirmed they
are identical minus blank lines that were fixed up.
v1: split this out from SPI driver series
---
arch/arm/dts/tegra20.dtsi| 377 +++---
board/avionic-design/dts/tegra20-tec.dts | 22 +-
board/compal/dts/tegra20-paz00.dts | 22 +-
board/nvidia/dts/tegra20-harmony.dts | 20 +-
board/nvidia/dts/tegra20-seaboard.dts| 119 +-
5 files changed, 279 insertions(+), 281 deletions(-)
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index cc086b1..46e3785 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -4,10 +4,102 @@
compatible = nvidia,tegra20;
interrupt-parent = intc;
- tegra_car: clock@60006000 {
- compatible = nvidia,tegra20-car;
- reg = 0x60006000 0x1000;
- #clock-cells = 1;
+ host1x {
+ compatible = nvidia,tegra20-host1x, simple-bus;
+ reg = 0x5000 0x00024000;
+ interrupts = 0 65 0x04 /* mpcore syncpt */
+ 0 67 0x04; /* mpcore general */
+ status = disabled;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ ranges = 0x5400 0x5400 0x0400;
+
+ /* video-encoding/decoding */
+ mpe {
+ reg = 0x5404 0x0004;
+ interrupts = 0 68 0x04;
+ status = disabled;
+ };
+
+ /* video input */
+ vi {
+ reg = 0x5408 0x0004;
+ interrupts = 0 69 0x04;
+ status = disabled;
+ };
+
+ /* EPP */
+ epp {
+ reg = 0x540c 0x0004;
+ interrupts = 0 70 0x04;
+ status = disabled;
+ };
+
+ /* ISP */
+ isp {
+ reg = 0x5410 0x0004;
+ interrupts = 0 71 0x04;
+ status = disabled;
+ };
+
+ /* 2D engine */
+ gr2d {
+ reg = 0x5414 0x0004;
+ interrupts = 0 72 0x04;
+ status = disabled;
+ };
+
+ /* 3D engine */
+ gr3d {
+ reg = 0x5418 0x0004;
+ status = disabled;
+ };
+
+ /* display controllers */
+ dc@5420 {
+ compatible = nvidia,tegra20-dc;
+ reg = 0x5420 0x0004;
+ interrupts = 0 73 0x04;
+ status = disabled;
+
+ rgb {
+ status = disabled;
+ };
+ };
+
+ dc@5424 {
+ compatible = nvidia,tegra20-dc;
+ reg = 0x5424 0x0004;
+ interrupts = 0 74 0x04;
+ status = disabled;
+
+ rgb {
+ status = disabled;
+ };
+ };
+
+ /* outputs */
+ hdmi {
+ compatible = nvidia,tegra20-hdmi;
+ reg = 0x5428 0x0004;
+ interrupts = 0 75 0x04;
+ status = disabled;
+ };
+
+ tvo {
+ compatible = nvidia,tegra20-tvo;
+ reg = 0x542c 0x0004;
+ interrupts = 0 76 0x04;
+ status = disabled;
+ };
+
+ dsi {
+ compatible = nvidia,tegra20-dsi;
+ reg = 0x5430 0x0004;
+ status = disabled;
+ };
};
intc: interrupt-controller@50041000 {
@@ -18,44 +110,33 @@
0x50040100 0x0100 ;
};
- i2c@7000c000 {
- #address-cells = 1;
- #size-cells = 0;
- compatible = nvidia,tegra20-i2c;
- reg = 0x7000C000 0x100;
- interrupts = 70 ;
-
Re: [U-Boot] [PATCH 2/5] lcd: add option for board specific splash screen preparation
Hello Igor, On 01/24/2013 09:35 AM, Igor Grinberg wrote: On 01/24/13 00:13, Jeroen Hofstee wrote: Hello Nikita, On 01/23/2013 09:31 AM, Nikita Kiryanov wrote: On 01/21/2013 09:14 PM, Jeroen Hofstee wrote: mmm, I am not so sure I agree that loading a bitmap in lcd_enable is a _problem_, while loading it in show logo and requiring a CONFIG_* is _natural_. Well, it is a problem. If we don't respect the abstractions we create then things like function names become meaningless. A function called lcd_enable should do just that- enable lcd. Not load stuff from storage to memory or manipulate BMPs. my point is that lcd_clear will e.g. call lcd_logo. Although I haven't tested it, it seems you're make a side effect of a function only called once a side effect of another function (which could be called multiple times). So you make things even worse (loading an bitmap while the function is just named to display it). So what's your point? Do you think we should add a splash screen specific callback inside the board.c U-Boot boot flow? no. Please, be more specific, as both approaches are not suitable according to what was said above... lets see, drv_lcd_init calls lcd_init. which does lcd_ctrl_init(lcdbase); lcd_is_enabled = 1; lcd_clear(); lcd_enable(); After this patch, lcd_clear calls lcd_logo which calls board_splash_screen_prepare in its turn. In my mind this still leaves allot of side effects. If you want to prepare for displaying and not have it as a side effect of a function which is named to do something else, it should be in between lcd_ctrl_init and lcd_clear in my mind. But anyway, can't this at least be changed to a __weak function, so the CONFIG and ifdef stuff can be dropped? The motivation behind the CONFIG was to make it a documentable user setting, rather than an undocumented feature buried in the code. then document the callback... Sorry, may be I've missed something, but I can't see any callback being documented in the README file... I don't see the improvement of this patch.. What does that suppose to mean? Either be constructive or don't bother... This means, as I hopefully explained a bit more clearly now, that the patch makes the loading of a bitmap a side effect of lcd_clear, while the intention was to make it a more natural call sequence. (which can simply be done by putting it somewhere else as mentioned above) btw, I think, loading the image in lcd_enable() won't even work since lcd_enable is actually before lcd_clear. Scanning some boards which load in lcd_enable, they seem to call bmp_display manually. So that makes this patch no longer optional, but is actually required and is an improvement I'd like to hear Anatolij's opinion on this. yes, me too. I like the __weak far more than requiring a CONFIG_to enable a callback. I cannot think of a reason why these __weak functions cannot be documented. So that's up to Anatolij. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] powerpc/85xx: select -mcpu=8540 to match -Wa, e500
On 01/24/2013 02:07:29 AM, Andy Fleming wrote: Scott, I reverted this patch, and it fixed some build errors: 20001122-1.c:1:0: error: E500 and FPRs not supported 20010114-2.c:1:0: error: E500 and FPRs not supported make[2]: *** [/local/afleming/u-boot/build/P2020DS/post/lib_powerpc/fpu/20001122-1.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [/local/afleming/u-boot/build/P2020DS/post/lib_powerpc/fpu/20010114-2.o] Error 1 make[1]: *** [postdeps] Error 2 make: *** [/local/afleming/u-boot/build/P2020DS/post/libpost.o] Error 2 make: INTERNAL: Exiting with 4 jobserver tokens available; should be 3! Sigh. Patch coming to use -mcpu=e500mc when appropriate, but... Similar errors were seen on all these boards: P2041RDB_SRIO_PCIE_BOOT P5020DS P3041DS P5020DS_NAND P2020DS P3041DS_NAND P5020DS_SDCARD P2020DS_36BIT P3041DS_SDCARD P5020DS_SECURE_BOOT P2020DS_DDR2 P3041DS_SECURE_BOOT P5020DS_SPIFLASH P2020DS_SDCARDP3041DS_SPIFLASH P5020DS_SRIO_PCIE_BOOT P2020DS_SPIFLASH P3041DS_SRIO_PCIE_BOOT P5040DS P2041RDB P4080DS xpedite520x P2041RDB_NAND P4080DS_SDCARD xpedite537x P2041RDB_SDCARD P4080DS_SECURE_BOOT xpedite550x P2041RDB_SECURE_BOOT P4080DS_SPIFLASH P2041RDB_SPIFLASH P4080DS_SRIO_PCIE_BOOT ...not all of these are e500mc derivatives (P2020DS and xpedite). So it seems this patch found a bug in that some e500v2 boards are building normal FP code. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH v3 0/7] Initial IPv6 support
From: Chris Packham chris.pack...@alliedtelesis.co.nz Now we have something functional. With this you can do something like 'setenv ipaddr6 3ffe::2' and 'ping6 3ffe::1' should work. I seem to have a problem that when you send a ping6 for a non-existent address that ends up stuck and the next non-ipv6 net operation tries to resolve it. I suspect this is because the pending neighbor discovery information isn't cleaned up properly. I'm sending this out now because I'll be away at a conference next week so probably won't have any time to work on this but I did want to say hey ping6 works. When I get back I'll start tackling tftp over ipv6. Changes in v3: -Fix a what should have been a glaringly obvious omission that cause all addresses to be interpreted as 0. Made even stricter so that v6 addresses that start with numbers aren't accepted. -return -1 with the input string is null. Changes in v2: - use __be16/__be32 - add ipv6_addr_v4mapped and ipv6_addr_is_isatap inline functions Changes in v3 - Add reviewed-by from Kim Phillips to Initial net6.h - Add support for printing mapped and ISATAP addresses Chris Packham (7): Initial net6.h lib/vsprintf.c: add IPv6 compressed format %pI6c lib/net_utils.c: make string_to_ip stricter lib/net_utils.c: add string_to_ip6 common.h: add getenv_IP6addr tsec: enable promiscuous mode for IPv6 net: ipv6 support common/cmd_net.c | 27 + drivers/net/tsec.c | 4 + include/common.h | 6 + include/net.h | 5 +- include/net6.h | 267 lib/net_utils.c| 128 +++- lib/vsprintf.c | 143 +++--- net/Makefile | 6 + net/ndisc.c| 276 ++ net/ndisc.h| 29 + net/net.c | 38 ++ net/net6.c | 349 + net/ping6.c| 115 ++ 13 files changed, 1366 insertions(+), 27 deletions(-) create mode 100644 include/net6.h create mode 100644 net/ndisc.c create mode 100644 net/ndisc.h create mode 100644 net/net6.c create mode 100644 net/ping6.c -- 1.7.12.rc2.16.g034161a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH v3 1/7] Initial net6.h
From: Chris Packham chris.pack...@alliedtelesis.co.nz
Has the definition of an IPv6 address and IPv6 header. It may make sense
to separate the v4 support from net.h (or to include this in net.h).
Signed-off-by: Chris Packham chris.pack...@alliedtelesis.co.nz
---
Changes in v3:
- add reviewed-by from Kim Phillips
Changes in v2:
- use __be16/__be32
- add ipv6_addr_v4mapped and ipv6_addr_is_isatap inline functions
include/net6.h | 43 +++
1 file changed, 43 insertions(+)
create mode 100644 include/net6.h
diff --git a/include/net6.h b/include/net6.h
new file mode 100644
index 000..03bccb2
--- /dev/null
+++ b/include/net6.h
@@ -0,0 +1,43 @@
+/**
+ * Simple IPv6 network layer implementation.
+ *
+ * Based and/or adapted from the IPv4 network layer in net.[hc]
+ *
+ * (C) Copyright 2013 Allied Telesis Labs NZ
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+#ifndef __NET6_H__
+#define __NET6_H__
+
+typedef union ip6addr_t {
+ __u8u6_addr8[16];
+ __be16 u6_addr16[8];
+ __be32 u6_addr32[4];
+} IP6addr_t;
+
+/**
+ * struct ipv6hdr - Internet Protocol V6 (IPv6) header.
+ *
+ * IPv6 packet header as defined in RFC 2460.
+ */
+struct ip6_hdr {
+#if defined(__LITTLE_ENDIAN_BITFIELD)
+ __u8priority:4,
+ version:4;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+ __u8version:4,
+ priority:4;
+#else
+#error Please fix asm/byteorder.h
+#endif
+ __u8flow_lbl[3];
+ __be16 payload_len;
+ __u8nexthdr;
+ __u8hop_limit;
+ IP6addr_t saddr;
+ IP6addr_t daddr;
+};
+
+#endif /* __NET6_H__ */
--
1.7.12.rc2.16.g034161a
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
