[U-Boot] [PATCH] ubi: reset mtd_devs when ubi part fail
if ubi part fails, reset also mtd_devs to 0, as further ubi part would use wrong mtd_devs. Signed-off-by: Heiko Schocher h...@denx.de --- This issue was posted from Andrew here: http://patchwork.ozlabs.org/patch/410507/ Patchwork [U-Boot] ubi: reset relevant globals in ubi_exit() Could this produce with current mainline also now, and fixed it in ubi_init() in the error path too. Andrew: could you test this patch? (Should I add your Signed-off-by ?) drivers/mtd/ubi/build.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 584cf5f..290d524 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -1358,6 +1358,10 @@ out_version: out_class: class_destroy(ubi_class); out: +#ifdef __UBOOT__ + /* Reset any globals that the driver depends on being zeroed */ + mtd_devs = 0; +#endif ubi_err(cannot initialize UBI, error %d, err); return err; } @@ -1384,6 +1388,10 @@ void ubi_exit(void) misc_deregister(ubi_ctrl_cdev); class_remove_file(ubi_class, ubi_version); class_destroy(ubi_class); +#ifdef __UBOOT__ + /* Reset any globals that the driver depends on being zeroed */ + mtd_devs = 0; +#endif } module_exit(ubi_exit); -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12] sunxi: Move setting of CPU system control register SMP bit to save_boot_params
On Mon, 2015-01-19 at 20:04 +0100, Hans de Goede wrote: Hi, On 17-01-15 23:51, Ian Campbell wrote: On Thu, 2015-01-15 at 15:52 +0100, Hans de Goede wrote: According to the Cortex-A7 MPCore Technical Reference Manual: You must ensure this bit is set to 1 before the caches and MMU are enabled, or any cache and TLB maintenance operations are performed. Given that this is a feature of the Cortex-A7 (actually, I believe it applies to at least Cortex-A15 too) and not really specific to sunxi, perhaps we can make this more generic? Strange enough the bit is different between the A7 and A15, for the A7 the docs say it must be set before doing anything with caches, on the A15 it only needs to be set for the core to accept cache management operations from other cpu cores (or so the docs say), which is likely why it is not in the standard init sequence yet, as for u-boot it seems to only be necessary to do this on a Cortex A7. I agree that it would be good to move this to the generic start.S though, Albert ? Since arch/arm/cpu/armv7/start.S: cpu_init_cp15 does several cache operations, we should thus enable the SMP bit earlier, and the only chance to do that is to do it at save_boot_params time. Would it be so terrible to add an ifdef CORTEX_A7 here, or to call out to (or call as a macro) a soc_init_cp15? From my pov no that would not be too terrible, but ... I'm cc-ing Albert for input these questions. That indeed is Albert's call. Note that solving this still leaves the A80 magic sram controller poke which also needs to happen really really early or otherwise the entire SoC just resets as if the watchdog has triggered, I'm fine with using save_boot_params for that, it is not its intended purpose, but it works fine for it, so I see no reason to complicate things with yet another callback. Ideally it would be possible to do it in the same hook as sets up the ACTLR.SMP bit. In general I'm not a big fan of reusing unrelated hooks just because they happen to be in a convenient location -- it leads to surprises when you are reading through/modifying the calling code. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/12] sun9i: Basic sun9i (A80) support
On Mon, 2015-01-19 at 20:44 +0100, Hans de Goede wrote: Hi, On 17-01-15 23:59, Ian Campbell wrote: On Thu, 2015-01-15 at 15:52 +0100, Hans de Goede wrote: Add initial sun9i (A80) support, only uart + mmc are supported for now. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk +#define CONFIG_SYS_PROMPT sun9i# Should we make all these say sunxi# in the common header instead (the precise SoC is printed in the banner anyhow), Yeah that sounds like a good idea, care to submit a patch for that ? Yep, will do once this one hits #next so I don't need to rebase etc. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] add README.distro file
On Mon, 2015-01-19 at 10:55 -0700, Stephen Warren wrote: * Indicate that boot.scr is fully supported, not a legacy option. Still, recommend use of extlinux.conf over boot.scr. Thanks for this. The bits around that look fine now. One thing I happened to spot while skimming: +handled by U-Boot's syslinux (disk) or pxe boot (network). This is roughly +as specified at: + +http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ + +... with the exceptions that: + +* That document prescribes a separate configuration per boot menu option, + whereas U-Boot lumps all options into a single extlinux.conf file. Hence, + U-Boot searches for /extlinux/extlinux.conf then + /boot/extlinux/extlinux.conf on disk, or pxelinux.cfg/default over the + network. + +* Does not document the fdtdir option, which automatically selects the DTB to + pass to the kernel. This second bullet doesn't work, either in isolation or when combined with the sentence fragment which introduces the list. Perhaps the first few words of the first bullet should be moved to the intro fragment, e.g. with the exception that the BootLoaderSpec document: * prescribes a sep... * does not document ... ? Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf and R9 in ARM architecture
Hello Dashi Cao, On Tue, 20 Jan 2015 14:12:35 +0800, Da Shi Cao dscao...@gmail.com wrote: In standalone applications, it seems that the execution of printf function in U-Boot is dependent on the value of register R9, which is setup in app_startup. But r9 can be used by your program at the decision of gcc compilation which is not aware of this dependence. This is especially the case if +O2 is used! U-Boot follows the ARM EABI, in which The role of register r9 is platform specific. In U-Boot r9 is specifically used for the global data structure, and the standalone programs must follow this EABI. If your standalone program is built with the same options as U-Boot example standalone programs are (see hellow_world), then it should have gcc option -ffixed-r9 which will prevent the compiler from ever touching r9. How exactly do you build your standalone application? My version is U-Boot 2014.10 Regards, Dashi Cao Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: video: Use frontend for dma on sun4i to fix memory bandwidth problems
On Mon, 2015-01-19 at 11:29 +0100, Hans de Goede wrote: Testing has shown that on sun4i the display backend engine does not have deep enough fifo-s causing flickering / tearing in full-hd mode due to fifo underruns. On sun4i use the display frontend engine to do the dma from memory, as the frontend does have deep enough fifo-s. As added advantage of this is that it results in much better memory bandwidth as it reduces the amount of dram bank switches, for more details see: http://ssvb.github.io/2014/11/11/revisiting-fullhd-x11-desktop-performance-of-the-allwinner-a10.html Note that this changes the pipeline searched for in the simplefb node, we can get away with doing this now, since no kernel has yet shipped with simplefb dtb nodes, and I will make sure to get a simplefb node with the new pipeline into 3.19 before it ships. Looks good, there was discussion around the kernel patch, looks like it has resolved in favour of the patch though? Is it preferable to use the front or the backend (assuming sufficient fifo's etc)? IOW do we want to do this for all sun*i eventually, or only when the backend is insufficient for some reason? +#ifdef CONFIG_MACH_SUN4I Perhaps another comment here, but in any case: Acked-by: Ian Campbell i...@hellion.org.uk +#define PIPELINE_PREFIX de_fe0- +#else +#define PIPELINE_PREFIX +#endif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm, imx6, aristainetos: board updates
- use linux display timing settings
- change backlight duty cycle 500ns
- some defaultenvironment changes
- change fit_addr_r to 0x1400 as needed if
MAX_LOCKDEP_SUBCLASSES in linux gets increased.
- Environment now at 0xd in nand flash
Signed-off-by: Heiko Schocher h...@denx.de
---
board/aristainetos/aristainetos.c | 8 +-
include/configs/aristainetos.h| 167 +-
2 files changed, 97 insertions(+), 78 deletions(-)
diff --git a/board/aristainetos/aristainetos.c
b/board/aristainetos/aristainetos.c
index 67ac260..8330bb6 100644
--- a/board/aristainetos/aristainetos.c
+++ b/board/aristainetos/aristainetos.c
@@ -321,8 +321,8 @@ static void enable_lvds(struct display_info_t const *dev)
/* enable backlight PWM 3 */
if (pwm_init(2, 0, 0))
goto error;
- /* duty cycle 200ns, period: 3000ns */
- if (pwm_config(2, 200, 3000))
+ /* duty cycle 500ns, period: 3000ns */
+ if (pwm_config(2, 500, 3000))
goto error;
if (pwm_enable(2))
goto error;
@@ -350,8 +350,8 @@ struct display_info_t const displays[] = {
.right_margin = 88,
.upper_margin = 10,
.lower_margin = 10,
- .hsync_len = 25,
- .vsync_len = 1,
+ .hsync_len = 80,
+ .vsync_len = 25,
.sync = 0,
.vmode = FB_VMODE_NONINTERLACED
}
diff --git a/include/configs/aristainetos.h b/include/configs/aristainetos.h
index e6a08df..3066fd0 100644
--- a/include/configs/aristainetos.h
+++ b/include/configs/aristainetos.h
@@ -1,4 +1,5 @@
/*
+ * (C) Copyright 2015
* (C) Copyright 2014
* Heiko Schocher, DENX Software Engineering, h...@denx.de.
*
@@ -24,8 +25,7 @@
#include asm/imx-common/gpio.h
#define CONFIG_MACH_TYPE 4501
-#define CONFIG_MMCROOT /dev/mmcblk0p2
-#define CONFIG_DEFAULT_FDT_FILEaristainetos.dtb
+#define CONFIG_MMCROOT /dev/mmcblk0p1
#define CONFIG_HOSTNAMEaristainetos
#define PHYS_SDRAM_SIZE(1u * 1024 * 1024 * 1024)
@@ -81,7 +81,6 @@
#define CONFIG_SF_DEFAULT_SPEED2000
#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
#define CONFIG_SYS_SPI_ST_ENABLE_WP_PIN
-
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
#define CONFIG_CONS_INDEX 1
@@ -101,84 +100,108 @@
#define CONFIG_SYS_TEXT_BASE 0x1780
#define CONFIG_EXTRA_ENV_SETTINGS \
- uimage=uImage\0 \
- fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
- fdt_addr_r=0x1100\0 \
- kernel_addr_r=0x1200\0 \
- kernel_file=uImage\0 \
- boot_fdt=try\0 \
- ip_dyn=yes\0 \
+ script=u-boot.scr\0 \
+ fit_file=/boot/system.itb\0 \
+ loadaddr=0x1200\0 \
+ fit_addr_r=0x1400\0 \
+ uboot=/boot/u-boot.imx\0 \
+ uboot_sz=d\0 \
+ rescue_sys_addr=f\0 \
+ rescue_sys_length=f1\0 \
+ board_type=aristainetos7@1\0 \
+ panel=lb07wv8\0 \
+ splashpos=m,m\0 \
console= CONFIG_CONSOLE_DEV \0 \
fdt_high=0x\0 \
initrd_high=0x\0 \
+ mtdids=nand0=gpmi-nand,nor0=spi3.0\0 \
+ mtdparts=mtdparts=spi3.0:832k(u-boot),64k(env),64k(env-red), \
+ -(rescue-system);gpmi-nand:-(ubi)\0 \
+ addmisc=setenv bootargs ${bootargs} consoleblank=0\0 \
+ addmtd=setenv bootargs ${bootargs} ${mtdparts}\0 \
+ set_fit_default=fdt addr ${fit_addr_r};fdt set /configurations \
+ default ${board_type}\0 \
+ get_env=mw ${loadaddr} 0 0x2; \
+ mmc rescan; \
+ ext2load mmc ${mmcdev}:${mmcpart} ${loadaddr} env.txt; \
+ env import -t ${loadaddr}\0 \
+ default_env=mw ${loadaddr} 0 0x2; \
+ env export -t ${loadaddr} serial# ethaddr eth1addr \
+ board_type panel; \
+ env default -a; \
+ env import -t ${loadaddr}\0 \
+ loadbootscript= \
+ ext2load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
+ bootscript=echo Running bootscript from mmc ...; \
+ source\0 \
mmcpart=1\0 \
- mmcdev= __stringify(CONFIG_SYS_MMC_ENV_DEV) \0 \
+ mmcdev=0\0 \
mmcroot= CONFIG_MMCROOT rootwait rw\0 \
mmcargs=setenv bootargs console=${console},${baudrate} \
root=${mmcroot}\0 \
- loadimage=fatload mmc ${mmcdev}:${mmcpart} ${kernel_addr_r} \
- ${uimage}\0 \
- loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr_r} \
- ${fdt_file}\0 \
mmcboot=echo Booting from mmc ...; \
- run mmcargs;run loadimage loadfdt fdt_setup; \
- bootm ${kernel_addr_r} -
Re: [U-Boot] [linux-sunxi] [u-boot 2/2] sun5i: bump DEBE priority (useful on a10s only)
On Mon, 19 Jan 2015 06:29:47 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 04-01-15 20:19, Michal Suchanek wrote: Setting magic 'reserved' hpcr bit on sun5i DEBE seems required for smooth HDMI scanout of large frambuffer (eg. 1080p). This fix comes at the cost of some overall memory bandwidth so it might be appropriate to detect a10s and only apply there (and not a13). Hmm, Sairhei is the expert on this, adding him to the Cc. Sairhei, what do you think of the proposed change ? I don't have A10s hardware, so have no idea and can't test anything myself. It would be great to have a better description of what exactly is happening before the patch. And precisely how the patch is helping. A description of the test setup and benchmark numbers would be appreciated. And it would be perfect if somebody else could reproduce the test and confirm the results. I may try to check A20 with the bus width artificially reduced to 16 bits (not a totally unrealistic configuration, since A20-OLinuXino-LIME board exists). If sun5i and sun7i are similar enough, then the magic reserved bit may have some effect there too. But that's a different hardware either way. Done these tests with A20. Ironically, now the tables have turned and A10 seems to be doing a better job than A20 at low DRAM clock speeds (~408MHz) and 16-bit bus width when dealing with full-hd monitors. Just like Michal observed on A10s, setting 0x5031 as DEFE host port config makes things much worse on A20. Overall, the test results look in the following way on A20 with 16-bit DRAM clocked at 408MHz (yes, none of the real boards uses such a slow DRAM setup) while running lima-memtester and driving 1920x1080-32@60Hz monitor: 0x1035 - The screen regularly blanks, but comes back again instantly. 0x1037 - The screen regularly blanks, but comes back again instantly. 0x5031 - Severe screen shaking. Unlike A10, there does not seem to be any difference between using DEBE or DEFE for framebuffer scanout on A20, so using DEBE has the same effect as listed above. Setting the magic 'reserved' hpcr bit 1 (0x1037 value) does not seem to have any effect on sun7i. It is great that it is apparently helping on sun5i/A10s though. But enough about A20. As Hans already mentioned, the submitted A10s patch is tweaking the DEFE host port settings (not DEBE, contrary to what the summary says). Michal, could you please run a few more tests and check whether there is any observable difference between DEBE and DEFE on A10s (fb0_scaler_mode_enable=0 vs. fb0_scaler_mode_enable=1 in fex)? If they behave in the same way and the magic 'reserved' bit fixes both of them, then IMHO the patch should just tweak both. Thanks for working on this! -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] sunxi: Stop differentiating between 512M and 1G variants of the same board
On Mon, 2015-01-19 at 15:35 +0100, Hans de Goede wrote:
Siarhei, thanks for bringing this topic up once again, I agree that this
is ideally something which we should fix. The problem is that the only
way to know that any new settings which we do are actually good, is to
test them on lots of boards, and I do not mean one of each board, but
at least 10 of each board or some such.
I agree. Having settings which are optimal for Hans' board but untested
elsewhere would not be a good idea IMHO.
Still I would like to get this sorted, so I would like to move to the
recommended timings for the generic JEDEC speed bins, you rightfully
point out that those may not be 100% optimal, but given that we're
dealing with a lot of cheap boards, I think that those are our best bet.
Agreed. In the absence of an ability to test lots of boards this is
probably the best we can do.
An alternative would be to use the settings from the factory firmware,
but I don't think we have any real reason to think these will be any
better in general than the JEDEC timings, at least not without lots of
testing (see previous paragraph).
The plan would be for you to submit a patch for that, and then I'll add
that to my sunxi-wip branch right away, this way all the testing I do,
as well as all the testing people using my sunxi-wip branch do will use
the new timings, and then once v2015.04 stabilizes a bit we can add
that patch to u-boot-sunxi/next, getting it ready for v2015.07 .
Does that sound like a plan ?
Ian, what do you think about this ?
Go for it.
This way we will not grow the spl, and keep an easy editable set of
dram_para in the spl for people who like to hexedit the spl ...
At the start of the #ifdef chain you could add
#ifdef CONFIG...CUSTOM_DRAM_SETTINGS
static struct dram_para dram_para = {
CONFIG_...CUSTOM_DRAM_SETTINGS
};
#elif ...
along with a corresponding Kconfig entry (perhaps depends on EXPERT?).
Then people who really want to tweak things could enter
CONFIG=.clock=XXX,.type=YYY,.. in their .config (menuconfig etc)
or defconfig to their heart's content. (only question is what the
character limit on a config option is...)
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf and R9 in ARM architecture
On Tuesday, January 20, 2015 at 07:12:35 AM, Da Shi Cao wrote: In standalone applications, it seems that the execution of printf function in U-Boot is dependent on the value of register R9, which is setup in app_startup. But r9 can be used by your program at the decision of gcc compilation which is not aware of this dependence. This is especially the case if +O2 is used! +CC the experts who probably broke it ;-) Shouldn't you compile your standalone application with something like -ffixed-r9 ? 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/2] mtd:mxs:nand support oobsize bigger than 512
On Friday, December 19, 2014 at 05:39:13 AM, Peng Fan wrote: If ecc chunk data size is 512 and oobsize is bigger than 512, there is a chance that block_mark_bit_offset conflicts with bch ecc area. The following graph is modified from kernel gpmi-nand.c driver with each data block 512 bytes. We can see that Block Mark conflicts with ecc area from bch view. We can enlarge the ecc chunk size to avoid this problem to those oobsize which is larger than 512. What exactly is the impact of this patch for current installations of U-Boot? Does the NAND need to be rewritten with new content? Is the format introduced by this patch compatible with Linux? Thanks! 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] board_f: save malloc_base from zeroing in case of CONFIG_SYS_MALLOC_F_LEN
Hi Albert, On Tue, 2015-01-20 at 08:07 +0100, Albert ARIBAUD wrote: Hello Alexey, On Mon, 19 Jan 2015 20:55:03 +0300, Alexey Brodkin alexey.brod...@synopsys.com wrote: In case of CONFIG_SYS_MALLOC_F_LEN malloc_base is used for early start-up code and is set very early, typically in start.S or crt1.S. There is no crt1.S in U-Boot. Did you mean crt0.S? Indeed I meant crt0.S In current implementation in case of CONFIG_SYS_GENERIC_GLOBAL_DATA all global data gets zeroed on board_init_f entry. But by that time malloc_base could have been set already, which means it will be zeroed and subsequent C-code will be executed improperly (if executed at all - if there's no memory mapped to 0 or it is read-only then on some arches there will be an exception and others will quetly die). To work-around described situation we just need to make sure malloc_base is saved prior zeroing global data and recovered afterwards. Keeping data from being zeroed etc is usually done through GD. Could malloc_base be placed there instead of creating a specific exemption for it? Unfortunately I didn't understand your suggestion here. malloc_base is already in global data structure. But the point is global data structure also requires zeroing sometime on early start-up. This is required to make sure we don't have any garbage in GD (for example left-overs from lower-level bootloader or previously executed kernel etc). So other option is to zero GD earlier in start-up code. This is essentially doable but it will be done on per-architecture or even per-CPU basis in their start.S - which means we'll have duplication of the same functionality and maintenance will be difficult then. Probably I just didn't get you point so then could you please clarify what did you mean. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12] sunxi: Move setting of CPU system control register SMP bit to save_boot_params
Hello Hans, On Mon, 19 Jan 2015 20:04:58 +0100, Hans de Goede hdego...@redhat.com wrote: Hi, On 17-01-15 23:51, Ian Campbell wrote: On Thu, 2015-01-15 at 15:52 +0100, Hans de Goede wrote: According to the Cortex-A7 MPCore Technical Reference Manual: You must ensure this bit is set to 1 before the caches and MMU are enabled, or any cache and TLB maintenance operations are performed. Given that this is a feature of the Cortex-A7 (actually, I believe it applies to at least Cortex-A15 too) and not really specific to sunxi, perhaps we can make this more generic? Strange enough the bit is different between the A7 and A15, for the A7 the docs say it must be set before doing anything with caches, on the A15 it only needs to be set for the core to accept cache management operations from other cpu cores (or so the docs say), which is likely why it is not in the standard init sequence yet, as for u-boot it seems to only be necessary to do this on a Cortex A7. I agree that it would be good to move this to the generic start.S though, Albert ? [...] Since arch/arm/cpu/armv7/start.S: cpu_init_cp15 does several cache operations, we should thus enable the SMP bit earlier, and the only chance to do that is to do it at save_boot_params time. Would it be so terrible to add an ifdef CORTEX_A7 here, or to call out to (or call as a macro) a soc_init_cp15? From my pov no that would not be too terrible, but ... I'm cc-ing Albert for input these questions. That indeed is Albert's call. I don't like the idea of #ifdef'ing that much. OTOH, if we do introduce soc_init_cp15, then we end up with two CP15 init functions, soc_init_cp15 and cpu_init_cp15, with all sorts of questions on which should be called first and whether one could break the other's work, and what happens in-between, etc. Either way, setting CP15 registers is something that all ARM CPUs, and SoCs require, not just armv7. It's just that other start.S files touch cp15 directly. I'm leaning toward grouping all CP15 inits (including cache(s) and TLB disabling and maybe VBAR setting) in a single CP15 call to a single soc_init_cp15 function. Now, SoCs with the same CPU will have a common CP15 init part, and that part could go into a cpu_init_cp15 function which soc_init_cp15 would call. Of course, since we're doing this way before we have any stack, we will have to handle nested calls by saving and restoring LR in intermediate function contexts. Note that solving this still leaves the A80 magic sram controller poke which also needs to happen really really early or otherwise the entire SoC just resets as if the watchdog has triggered, I'm fine with using save_boot_params for that, it is not its intended purpose, but it works fine for it, so I see no reason to complicate things with yet another callback. Maybe we could turn soc_init_cp15 into a more general soc_init function which would do whatever is needed, on cp15 or otherwise. (I see there is one soc_init defined, for spear600, but it is actually empty and could/should be removed. Patch anyone?) Regards, Hans Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf and R9 in ARM architecture
Hello Thomas, On Tue, 20 Jan 2015 19:34:32 +0800, Da Shi Cao dscao...@gmail.com wrote: No, I didn't use that option. This option should fix it. Please also look at other options used for hello_world, as you might hit other compatibility-related issues if you're not using the same ones. Thanks a lot. No problem. Thomas Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: pci: Permit use of reg property for setting device address
Hi Simon,
On Tue, Jan 20, 2015 at 11:19 AM, Simon Glass s...@chromium.org wrote:
In commit a62e84d the old functionality of obtaining a PCI address from the
'reg' property was lost. Add it back, so we can support both a compatible
string list and a 'reg' property.
This patch fixes PCIe ethernet on Tegra boards.
Signed-off-by: Simon Glass s...@chromium.org
---
lib/fdtdec.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 89dac4c..0488607 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -219,8 +219,14 @@ int fdtdec_get_pci_bdf(const void *blob, int node,
/* get vendor id device id from the compatible string */
ret = fdtdec_get_pci_vendev(blob, node, dt_vendor, dt_device);
- if (ret)
- return ret;
+ if (ret) {
+ /* Fall back to using the 'reg' property */
+ ret = fdtdec_get_int(blob, node, reg, -1);
+ if (ret == -1)
+ return -ENOENT;
+ *bdf = ret 0xff;
+ return 0;
+ }
/* extract the bdf from fdt_pci_addr */
*bdf = addr-phys_hi 0x00;
--
How is 'reg' encodeded in Tegra's dts? I feel we should start using
standard bindings instead of custom one.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/5] common/board_r: manual relocation for cmd table
Hi Simon, On Mon, 2015-01-19 at 16:34 -0700, Simon Glass wrote: Hi Andreas, Why do you need manual reloc? Is this a toolchain bug? From my experience the only way to escape manual relocation is to use PIE (Position Independent Executable), but this might not be supported in a toolchain for AVR (or it doesn't actually work good enough - this I understood from this message https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574716) -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mtd:mxs:nand calculate ecc strength dynamically
On Friday, December 19, 2014 at 05:39:12 AM, Peng Fan wrote: Calculate ecc strength according oobsize, but not hardcoded which is not aligned with kernel driver Signed-off-by: Peng Fan peng@freescale.com Signed-off-by: Ye.Li b37...@freescale.com Reviewed-by: Marek Vasut ma...@denx.de 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 1/2] mtd:mxs:nand calculate ecc strength dynamically
On Tuesday, January 20, 2015 at 07:35:26 AM, Peng Fan wrote: Hi Marek, Since you are familiar with this driver, would you please help review this patch? Hi! I commented on both. Next time, please CC me and Stefano, since the patches might slip just like this one did. Thank you for this work ! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf and R9 in ARM architecture
No, I didn't use that option. This option should fix it. Thanks a lot. Thomas On Tue, Jan 20, 2015 at 5:37 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Dashi Cao, On Tue, 20 Jan 2015 14:12:35 +0800, Da Shi Cao dscao...@gmail.com wrote: In standalone applications, it seems that the execution of printf function in U-Boot is dependent on the value of register R9, which is setup in app_startup. But r9 can be used by your program at the decision of gcc compilation which is not aware of this dependence. This is especially the case if +O2 is used! U-Boot follows the ARM EABI, in which The role of register r9 is platform specific. In U-Boot r9 is specifically used for the global data structure, and the standalone programs must follow this EABI. If your standalone program is built with the same options as U-Boot example standalone programs are (see hellow_world), then it should have gcc option -ffixed-r9 which will prevent the compiler from ever touching r9. How exactly do you build your standalone application? My version is U-Boot 2014.10 Regards, Dashi Cao Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 4/5] avr32: add generic board support
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
arch/avr32/config.mk|3 +++
arch/avr32/cpu/u-boot.lds |2 ++
arch/avr32/include/asm/config.h |1 +
arch/avr32/include/asm/u-boot.h |7 +++
arch/avr32/lib/Makefile |2 ++
arch/avr32/lib/interrupts.c |5 +
common/board_f.c| 13 ++---
common/board_r.c| 22 --
include/asm-generic/u-boot.h|4
9 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/arch/avr32/config.mk b/arch/avr32/config.mk
index 469185e..8252f59 100644
--- a/arch/avr32/config.mk
+++ b/arch/avr32/config.mk
@@ -9,6 +9,9 @@ ifeq ($(CROSS_COMPILE),)
CROSS_COMPILE := avr32-linux-
endif
+# avr32 has generic board support
+__HAVE_ARCH_GENERIC_BOARD := y
+
CONFIG_STANDALONE_LOAD_ADDR ?= 0x
PLATFORM_RELFLAGS += -ffixed-r5 -fPIC -mno-init-got -mrelax
diff --git a/arch/avr32/cpu/u-boot.lds b/arch/avr32/cpu/u-boot.lds
index cb29a22..b0180e3 100644
--- a/arch/avr32/cpu/u-boot.lds
+++ b/arch/avr32/cpu/u-boot.lds
@@ -48,9 +48,11 @@ SECTIONS
_edata = .;
.bss (NOLOAD) : {
+ __bss_start = .;
*(.bss)
*(.bss.*)
}
. = ALIGN(8);
__bss_end = .;
+ __init_end = .;
}
diff --git a/arch/avr32/include/asm/config.h b/arch/avr32/include/asm/config.h
index 63056a4..529fe22 100644
--- a/arch/avr32/include/asm/config.h
+++ b/arch/avr32/include/asm/config.h
@@ -8,5 +8,6 @@
#define _ASM_CONFIG_H_
#define CONFIG_NEEDS_MANUAL_RELOC
+#define CONFIG_SYS_GENERIC_GLOBAL_DATA
#endif
diff --git a/arch/avr32/include/asm/u-boot.h b/arch/avr32/include/asm/u-boot.h
index 2387f8a..0f7 100644
--- a/arch/avr32/include/asm/u-boot.h
+++ b/arch/avr32/include/asm/u-boot.h
@@ -6,6 +6,11 @@
#ifndef __ASM_U_BOOT_H__
#define __ASM_U_BOOT_H__ 1
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include asm-generic/u-boot.h
+#else
+
typedef struct bd_info {
unsigned char bi_phy_id[4];
unsigned long bi_board_number;
@@ -22,6 +27,8 @@ typedef struct bd_info {
#define bi_memstart bi_dram[0].start
#define bi_memsize bi_dram[0].size
+#endif
+
/* For image.h:image_check_target_arch() */
#define IH_ARCH_DEFAULT IH_ARCH_AVR32
diff --git a/arch/avr32/lib/Makefile b/arch/avr32/lib/Makefile
index bb45cbe..d5cb8b2 100644
--- a/arch/avr32/lib/Makefile
+++ b/arch/avr32/lib/Makefile
@@ -8,6 +8,8 @@
#
obj-y += memset.o
+ifndef CONFIG_SYS_GENERIC_BOARD
obj-y += board.o
+endif
obj-$(CONFIG_CMD_BOOTM) += bootm.o
obj-y += interrupts.o
diff --git a/arch/avr32/lib/interrupts.c b/arch/avr32/lib/interrupts.c
index bacb2d1..5f3a49e 100644
--- a/arch/avr32/lib/interrupts.c
+++ b/arch/avr32/lib/interrupts.c
@@ -7,6 +7,11 @@
#include asm/sysreg.h
+int interrupt_init(void)
+{
+ return 0;
+}
+
void enable_interrupts(void)
{
asm volatile(csrf %0 : : n(SYSREG_GM_OFFSET));
diff --git a/common/board_f.c b/common/board_f.c
index 3a4b32c..b5eb81e 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -174,7 +174,7 @@ static int announce_dram_init(void)
return 0;
}
-#if defined(CONFIG_MIPS) || defined(CONFIG_PPC)
+#if defined(CONFIG_MIPS) || defined(CONFIG_PPC) || defined(CONFIG_AVR32)
static int init_func_ram(void)
{
#ifdef CONFIG_BOARD_TYPES
@@ -268,6 +268,8 @@ static int setup_mon_len(void)
gd-mon_len = (ulong)_end - (ulong)_init;
#elif defined(CONFIG_BLACKFIN) || defined(CONFIG_NIOS2)
gd-mon_len = CONFIG_SYS_MONITOR_LEN;
+#elif defined(CONFIG_AVR32)
+ gd-mon_len = (ulong)__bss_end - (ulong)_text;
#else
/* TODO: use (ulong)__bss_end - (ulong)__text_start; ? */
gd-mon_len = (ulong)__bss_end - CONFIG_SYS_MONITOR_BASE;
@@ -581,7 +583,7 @@ static int reserve_stacks(void)
gd-irq_sp = gd-start_addr_sp;
# endif
#else
-# ifdef CONFIG_PPC
+# if defined(CONFIG_PPC) || defined(CONFIG_AVR32)
ulong *s;
# endif
@@ -611,6 +613,11 @@ static int reserve_stacks(void)
s = (ulong *) gd-start_addr_sp;
*s = 0; /* Terminate back chain */
*++s = 0; /* NULL return address */
+# elif defined(CONFIG_AVR32)
+ gd-arch.stack_end = gd-start_addr_sp;
+ s = (ulong *)gd-start_addr_sp;
+ *s = 0;
+ *--s = 0;
# endif /* Architecture specific code */
return 0;
@@ -906,7 +913,7 @@ static init_fnc_t init_sequence_f[] = {
#if defined(CONFIG_ARM) || defined(CONFIG_X86)
dram_init, /* configure available RAM banks */
#endif
-#if defined(CONFIG_MIPS) || defined(CONFIG_PPC)
+#if defined(CONFIG_MIPS) || defined(CONFIG_PPC) || defined(CONFIG_AVR32)
init_func_ram,
#endif
#ifdef CONFIG_POST
diff --git a/common/board_r.c b/common/board_r.c
index e712902..4d2000d 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -459,6 +459,16 @@ static int
Re: [U-Boot] [linux-sunxi] [u-boot 2/2] sun5i: bump DEBE priority (useful on a10s only)
Hi, On 20-01-15 09:16, Siarhei Siamashka wrote: On Mon, 19 Jan 2015 06:29:47 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 04-01-15 20:19, Michal Suchanek wrote: Setting magic 'reserved' hpcr bit on sun5i DEBE seems required for smooth HDMI scanout of large frambuffer (eg. 1080p). This fix comes at the cost of some overall memory bandwidth so it might be appropriate to detect a10s and only apply there (and not a13). Hmm, Sairhei is the expert on this, adding him to the Cc. Sairhei, what do you think of the proposed change ? I don't have A10s hardware, so have no idea and can't test anything myself. It would be great to have a better description of what exactly is happening before the patch. And precisely how the patch is helping. A description of the test setup and benchmark numbers would be appreciated. And it would be perfect if somebody else could reproduce the test and confirm the results. I may try to check A20 with the bus width artificially reduced to 16 bits (not a totally unrealistic configuration, since A20-OLinuXino-LIME board exists). If sun5i and sun7i are similar enough, then the magic reserved bit may have some effect there too. But that's a different hardware either way. Done these tests with A20. Ironically, now the tables have turned and A10 seems to be doing a better job than A20 at low DRAM clock speeds (~408MHz) and 16-bit bus width when dealing with full-hd monitors. Just like Michal observed on A10s, setting 0x5031 as DEFE host port config makes things much worse on A20. Overall, the test results look in the following way on A20 with 16-bit DRAM clocked at 408MHz (yes, none of the real boards uses such a slow DRAM setup) while running lima-memtester and driving 1920x1080-32@60Hz monitor: 0x1035 - The screen regularly blanks, but comes back again instantly. 0x1037 - The screen regularly blanks, but comes back again instantly. 0x5031 - Severe screen shaking. Unlike A10, there does not seem to be any difference between using DEBE or DEFE for framebuffer scanout on A20, so using DEBE has the same effect as listed above. Setting the magic 'reserved' hpcr bit 1 (0x1037 value) does not seem to have any effect on sun7i. It is great that it is apparently helping on sun5i/A10s though. Thanks for running these tests, this makes me more confident that I only need to enable DEFE in u-boot on A10, and can directly use DEBE on the others. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] video: Add support for Hitachi tx18d42vm LVDS LCD panels
Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a
lcd controller which needs to be initialized over SPI, once that is
done they work like a regular LVDS panel.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/video/Kconfig | 15 +--
drivers/video/Makefile| 1 +
drivers/video/hitachi_tx18d42vm_lcd.c | 81 +++
drivers/video/hitachi_tx18d42vm_lcd.h | 9
4 files changed, 103 insertions(+), 3 deletions(-)
create mode 100644 drivers/video/hitachi_tx18d42vm_lcd.c
create mode 100644 drivers/video/hitachi_tx18d42vm_lcd.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d9d4afc..ccbd7e2 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -36,9 +36,18 @@ config VIDEO_LCD_SSD2828_RESET
The reset pin of SSD2828 chip. This takes a string in the format
understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
+config VIDEO_LCD_HITACHI_TX18D42VM
+ bool Hitachi tx18d42vm LVDS LCD panel support
+ depends on VIDEO
+ default n
+ ---help---
+ Support for Hitachi tx18d42vm LVDS LCD panels, these panels have a
+ lcd controller which needs to be initialized over SPI, once that is
+ done they work like a regular LVDS panel.
+
config VIDEO_LCD_SPI_CS
string SPI CS pin for LCD related config job
- depends on VIDEO_LCD_SSD2828
+ depends on VIDEO_LCD_SSD2828 || VIDEO_LCD_HITACHI_TX18D42VM
default
---help---
This is one of the SPI communication pins, involved in setting up a
@@ -48,7 +57,7 @@ config VIDEO_LCD_SPI_CS
config VIDEO_LCD_SPI_SCLK
string SPI SCLK pin for LCD related config job
- depends on VIDEO_LCD_SSD2828
+ depends on VIDEO_LCD_SSD2828 || VIDEO_LCD_HITACHI_TX18D42VM
default
---help---
This is one of the SPI communication pins, involved in setting up a
@@ -58,7 +67,7 @@ config VIDEO_LCD_SPI_SCLK
config VIDEO_LCD_SPI_MOSI
string SPI MOSI pin for LCD related config job
- depends on VIDEO_LCD_SSD2828
+ depends on VIDEO_LCD_SSD2828 || VIDEO_LCD_HITACHI_TX18D42VM
default
---help---
This is one of the SPI communication pins, involved in setting up a
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 3629868..c3fcf45 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_VIDEO_COREBOOT) += coreboot_fb.o
obj-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o
obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
obj-$(CONFIG_VIDEO_IMX25LCDC) += imx25lcdc.o videomodes.o
+obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
obj-$(CONFIG_VIDEO_MB86R0xGDC) += mb86r0xgdc.o videomodes.o
diff --git a/drivers/video/hitachi_tx18d42vm_lcd.c
b/drivers/video/hitachi_tx18d42vm_lcd.c
new file mode 100644
index 000..1ce4a8c
--- /dev/null
+++ b/drivers/video/hitachi_tx18d42vm_lcd.c
@@ -0,0 +1,81 @@
+/*
+ * Hitachi tx18d42vm LVDS LCD panel driver
+ *
+ * (C) Copyright 2015 Hans de Goede hdego...@redhat.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+
+#include asm/gpio.h
+#include errno.h
+
+/*
+ * Very simple write only SPI support, this does not use the generic SPI infra
+ * because that assumes R/W SPI, requiring a MISO pin. Also the necessary glue
+ * code alone would be larger then this minimal version.
+ */
+static void lcd_panel_spi_write(int cs, int clk, int mosi,
+ unsigned int data, int bits)
+{
+ int i, offset;
+
+ gpio_direction_output(cs, 0);
+ for (i = 0; i bits; i++) {
+ gpio_direction_output(clk, 0);
+ offset = (bits - 1) - i;
+ gpio_direction_output(mosi, (data offset) 1);
+ udelay(2);
+ gpio_direction_output(clk, 1);
+ udelay(2);
+ }
+ gpio_direction_output(cs, 1);
+ udelay(2);
+}
+
+int hitachi_tx18d42vm_init(void)
+{
+ const u16 init_data[] = {
+ 0x0029, /* reset */
+ 0x0025, /* standby */
+ 0x0840, /* enable normally black */
+ 0x0430, /* enable FRC/dither */
+ 0x385f, /* enter test mode(1) */
+ 0x3ca4, /* enter test mode(2) */
+ 0x3409, /* enable SDRRS, enlarge OE width */
+ 0x4041, /* adopt 2 line / 1 dot */
+ };
+ int i, cs, clk, mosi, ret = 0;
+
+ cs = name_to_gpio(CONFIG_VIDEO_LCD_SPI_CS);
+ clk = name_to_gpio(CONFIG_VIDEO_LCD_SPI_SCLK);
+ mosi = name_to_gpio(CONFIG_VIDEO_LCD_SPI_MOSI);
+
+ if (cs == -1 || clk == -1 || mosi == 1) {
+ printf(Error tx18d42vm spi gpio config is invalid\n);
+
[U-Boot] [PATCH v2 2/2] sunxi: video: Add support for Hitachi tx18d42vm LVDS LCD panels
Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a
lcd controller which needs to be initialized over SPI, once that is
done they work like a regular LVDS panel.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
board/sunxi/Kconfig | 7 +++
drivers/video/sunxi_display.c | 12
2 files changed, 19 insertions(+)
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 76d190b..97f900b 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -359,6 +359,13 @@ config VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828
---help---
7.85 768x1024 LCD panels, such as LG LP079X01 or AUO B079XAN01.0
+config VIDEO_LCD_PANEL_HITACHI_TX18D42VM
+ bool Hitachi tx18d42vm LCD panel
+ select VIDEO_LCD_HITACHI_TX18D42VM
+ select VIDEO_LCD_IF_LVDS
+ ---help---
+7.85 1024x768 Hitachi tx18d42vm LCD panel support
+
endchoice
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index a6e3778..5a77a70 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -20,6 +20,7 @@
#include fdt_support.h
#include video_fb.h
#include videomodes.h
+#include hitachi_tx18d42vm_lcd.h
#include ssd2828.h
DECLARE_GLOBAL_DATA_PTR;
@@ -976,6 +977,14 @@ static int sunxi_ssd2828_init(const struct ctfb_res_modes
*mode)
}
#endif /* CONFIG_VIDEO_LCD_SSD2828 */
+#ifdef CONFIG_VIDEO_LCD_HITACHI_TX18D42VM
+static void sunxi_hitachi_tx18d42vm_init(void)
+{
+ mdelay(50); /* Wait for lcd controller power on */
+ hitachi_tx18d42vm_init();
+}
+#endif
+
static void sunxi_engines_init(void)
{
sunxi_composer_init();
@@ -1004,6 +1013,9 @@ static void sunxi_mode_set(const struct ctfb_res_modes
*mode,
break;
case sunxi_monitor_lcd:
sunxi_lcdc_panel_enable();
+#ifdef CONFIG_VIDEO_LCD_HITACHI_TX18D42VM
+ sunxi_hitachi_tx18d42vm_init();
+#endif
sunxi_composer_mode_set(mode, address);
sunxi_lcdc_tcon0_mode_set(mode);
sunxi_composer_enable();
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] video: Add support for Hitachi tx18d42vm LVDS LCD
Hi Anatolij, Here is v2 of my Hitachi tx18d42vm LVDS LCD support patches. You already acked v1, but v1 was sunxi specific and following the example of the ssd2828 patches I've decided to respin the patch to make the hitachi tx18d42vm bits generic so that they can be used by non sunxi boards too. Can you please review this version ? If you're ok with it I'll queue it up for merging un u-boot-sunxi/next . Thanks Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mtd:mxs:nand calculate ecc strength dynamically
Hi, Marek On 1/20/2015 7:04 PM, Marek Vasut wrote: On Tuesday, January 20, 2015 at 07:35:26 AM, Peng Fan wrote: Hi Marek, Since you are familiar with this driver, would you please help review this patch? Hi! I commented on both. Next time, please CC me and Stefano, since the patches might slip just like this one did. Thank you for this work ! Sorry for this and thanks for this tip. Best regards, Marek Vasut Best regards, Peng. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Enable journal replay for UBIFS
Hello Heiko Thank you fro the review. I added atomic_long_read in ubifs.h as for other atomic operations. I hope (but I can't garantee) by this time the mail is well formed. If not please tell me again. During mount_ubifs the ubifs_replay_journal was disabled. This patch enables it again and fix some unrecoverable UBIFS volumes. Signed-off-by: Anton Habegger anton.habeg...@delta-es.com --- fs/ubifs/Makefile | 2 +- fs/ubifs/gc.c | 987 ++ fs/ubifs/replay.c | 4 - fs/ubifs/super.c | 8 +- fs/ubifs/tnc.c| 2 - fs/ubifs/ubifs.h | 1 + 6 files changed, 990 insertions(+), 14 deletions(-) create mode 100644 fs/ubifs/gc.c diff --git a/fs/ubifs/Makefile b/fs/ubifs/Makefile index 8c8c6ac..5efb349 100644 --- a/fs/ubifs/Makefile +++ b/fs/ubifs/Makefile @@ -12,4 +12,4 @@ obj-y := ubifs.o io.o super.o sb.o master.o lpt.o obj-y += lpt_commit.o scan.o lprops.o obj-y += tnc.o tnc_misc.o debug.o crc16.o budget.o -obj-y += log.o orphan.o recovery.o replay.o +obj-y += log.o orphan.o recovery.o replay.o gc.o diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c new file mode 100644 index 000..159ee67 --- /dev/null +++ b/fs/ubifs/gc.c @@ -0,0 +1,987 @@ +/* + * This file is part of UBIFS. + * + * Copyright (C) 2006-2008 Nokia Corporation. + * + * 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. + * + * 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., 51 + * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * + * Authors: Adrian Hunter + * Artem Bityutskiy (Битюцкий Артём) + */ + +/* + * This file implements garbage collection. The procedure for garbage collection + * is different depending on whether a LEB as an index LEB (contains index + * nodes) or not. For non-index LEBs, garbage collection finds a LEB which + * contains a lot of dirty space (obsolete nodes), and copies the non-obsolete + * nodes to the journal, at which point the garbage-collected LEB is free to be + * reused. For index LEBs, garbage collection marks the non-obsolete index nodes + * dirty in the TNC, and after the next commit, the garbage-collected LEB is + * to be reused. Garbage collection will cause the number of dirty index nodes + * to grow, however sufficient space is reserved for the index to ensure the + * commit will never run out of space. + * + * Notes about dead watermark. At current UBIFS implementation we assume that + * LEBs which have less than @c-dead_wm bytes of free + dirty space are full + * and not worth garbage-collecting. The dead watermark is one min. I/O unit + * size, or min. UBIFS node size, depending on what is greater. Indeed, UBIFS + * Garbage Collector has to synchronize the GC head's write buffer before + * returning, so this is about wasting one min. I/O unit. However, UBIFS GC can + * actually reclaim even very small pieces of dirty space by garbage collecting + * enough dirty LEBs, but we do not bother doing this at this implementation. + * + * Notes about dark watermark. The results of GC work depends on how big are + * the UBIFS nodes GC deals with. Large nodes make GC waste more space. Indeed, + * if GC move data from LEB A to LEB B and nodes in LEB A are large, GC would + * have to waste large pieces of free space at the end of LEB B, because nodes + * from LEB A would not fit. And the worst situation is when all nodes are of + * maximum size. So dark watermark is the amount of free + dirty space in LEB + * which are guaranteed to be reclaimable. If LEB has less space, the GC might + * be unable to reclaim it. So, LEBs with free + dirty greater than dark + * watermark are good LEBs from GC's point of few. The other LEBs are not so + * good, and GC takes extra care when moving them. + */ +#ifndef __UBOOT__ +#include linux/slab.h +#include linux/pagemap.h +#include linux/list_sort.h +#endif +#include ubifs.h + +#ifndef __UBOOT__ +/* + * GC may need to move more than one LEB to make progress. The below constants + * define soft and hard limits on the number of LEBs the garbage collector + * may move. + */ +#define SOFT_LEBS_LIMIT 4 +#define HARD_LEBS_LIMIT 32 + +/** + * switch_gc_head - switch the garbage collection journal head. + * @c: UBIFS file-system description object + * @buf: buffer to write + * @len: length of the buffer to write + * @lnum: LEB number written is returned here + * @offs: offset written is returned here + * + * This function switch the GC head to the next LEB which is reserved in + * @c-gc_lnum. Returns %0 in case of success,
Re: [U-Boot] [PATCH] sunxi: Add Gemei G9 (Allwinner A10/sun4i) tablet
Hi, On 19-01-15 21:16, Priit Laes wrote: Gemei G9 is an A10 based tablet, with 1G RAM, 16G NAND, 1024x768 IPS LCD display, stereo speakers, 1.3MP front camera and 5 MP rear camera, 8000mAh battery, GT901 2+1 touchscreen, Bosch BMA250 accelerometer and RTL8188CUS USB wifi. It also has MicroSD slot, miniHDMI, 1 x MicroUSB OTG port and 1 x MicroUSB host port and 3.5mm headphone jack. More details are available at: http://linux-sunxi.org/Gemei_G9 Signed-off-by: Priit Laes pl...@plaes.org Thanks, queued up in u-boot-sunxi/next for merging into v2015.04 Regards, Hans --- board/sunxi/MAINTAINERS | 5 + configs/sunxi_Gemei_G9_defconfig | 20 2 files changed, 25 insertions(+) create mode 100644 configs/sunxi_Gemei_G9_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index ff53c46..ef7d493 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -61,6 +61,11 @@ M: Maxime Ripard maxime.rip...@free-electrons.com S:Maintained F:configs/Colombus_defconfig +GEMEI-G9 TABLET +M: Priit Laes pl...@plaes.org +S: Maintained +F: configs/sunxi_Gemei_G9_defconfig + HUMMINIGBIRD-A31 BOARD M:Chen-Yu Tsai w...@csie.org S:Maintained diff --git a/configs/sunxi_Gemei_G9_defconfig b/configs/sunxi_Gemei_G9_defconfig new file mode 100644 index 000..a85db2a --- /dev/null +++ b/configs/sunxi_Gemei_G9_defconfig @@ -0,0 +1,20 @@ +# Gemei G9 is an A10 based tablet, with 1G RAM, 16G NAND, +# 1024x768 IPS LCD display, stereo speakers, 1.3MP front camera and 5 MP +# rear camera, 8000mAh battery, GT901 2+1 touchscreen, Bosch BMA250 +# accelerometer and RTL8188CUS USB wifi. It also has MicroSD slot, MiniHDMI, +# 1 x MicroUSB OTG port and 1 x MicroUSB host port and 3.5mm headphone jack. +# More details are available at: http://linux-sunxi.org/Gemei_G9 +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,USB_EHCI +CONFIG_FDTFILE=sun4i-gemei-g9.dtb +CONFIG_VIDEO_LCD_MODE=x:1024,y:768,depth:18,pclk_khz:10,le:799,ri:260,up:15,lo:16,hs:1,vs:1,sync:3,vmode:0 +CONFIG_VIDEO_LCD_PANEL_LVDS=y +CONFIG_VIDEO_LCD_POWER=PH8 +CONFIG_VIDEO_LCD_BL_EN=PH7 +CONFIG_VIDEO_LCD_BL_PWM=PB2 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN4I=y ++S:CONFIG_DRAM_CLK=432 ++S:CONFIG_DRAM_ZQ=123 ++S:CONFIG_DRAM_EMR1=4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mtd:mxs:nand support oobsize bigger than 512
Hi, Marek On 1/20/2015 7:03 PM, Marek Vasut wrote: On Friday, December 19, 2014 at 05:39:13 AM, Peng Fan wrote: If ecc chunk data size is 512 and oobsize is bigger than 512, there is a chance that block_mark_bit_offset conflicts with bch ecc area. The following graph is modified from kernel gpmi-nand.c driver with each data block 512 bytes. We can see that Block Mark conflicts with ecc area from bch view. We can enlarge the ecc chunk size to avoid this problem to those oobsize which is larger than 512. What exactly is the impact of this patch for current installations of U-Boot? Does the NAND need to be rewritten with new content? Is the format introduced by this patch compatible with Linux? The patch does not affect current installations of U-boot. The NAND will not be rewritten with new content for chips whose oobsize is smaller than 512. To chips whose oobsize is bigger than 512, new format(saying gf_len is 14 and ecc chunk data size is 1024) introduced in this patch will be used. This patch is to support nand chips whose oobsize bigger than 512, since the current mxs nand driver only supports oobisze smaller than 512. Data maybe corrupted if oobsize is bigger than 512 while ecc chunk data size is still 512, this is what this patch is try to fix. Yeah the format is compatible with gpmi-nand.c in linux. Thanks! Best regards, Marek Vasut Thanks, Peng. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dm:gpio:mxc add DT support
On 01/20/15 09:15, Peng Fan wrote:
This patch add DT support for mxc gpio driver.
Include a bank_index entry in platdata. This can avoid using
`plat - mxc_plat` to calculate bank number. Also this can simplify code.
Although, I don't insist, but I would recommend to split the patch into 2:
the bank_index rework and the DT support addition.
There are two places still using CONFIG_OF_CONTROL macro, just to
shrink code size if only support DM but not support DT.
1. The U_BOOT_DEVICES and mxc_plat array are complied out. To DT,
platdata is alloced using calloc, so there is no need to use mxc_plat.
2. add a function mxc_get_gpio_addr to get reg property if DT support.
If no DT, this function just returns NULL.
I have some comments on this one, please see below...
The following situations are tested:
1. with DM, without DT
2. with DM and DT
3. without DM
Since device tree has not been upstreamed, if want to test this patch.
The followings need to be done.
+ pieces of code does not gpio_request when using gpio_direction_xxx and
etc, need to request gpio.
+ move the gpio settings from board_early_init_f to board_init
+ define CONFIG_DM ,CONFIG_DM_GPIO and CONFIG_OF_CONTROL
+ Add device tree file and do related configuration in
`make ARCH=arm menuconfig`
These will be done in future patches by step.
Signed-off-by: Peng Fan peng@freescale.com
---
Changes v2:
1. remove uneccessary #ifdef
2. add more stuff in commit log
3. include a new function mxc_get_gpio_addr to get register base.
This function is different for DT and not DT, by `#ifdef`.
If using one implementation for DT and not DT, final image will be big.
4. include a new entry in platdata, named bank_index. it can simplify DT
support. To no DT, bank_index is static initilized; to DT, bank_index
is get from device's req_seq.
drivers/gpio/mxc_gpio.c | 89
+++--
1 file changed, 71 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
index 8bb9e39..5826620 100644
--- a/drivers/gpio/mxc_gpio.c
+++ b/drivers/gpio/mxc_gpio.c
@@ -23,6 +23,7 @@ enum mxc_gpio_direction {
#define GPIO_PER_BANK32
struct mxc_gpio_plat {
+ int bank_index;
struct gpio_regs *regs;
};
@@ -150,6 +151,9 @@ int gpio_direction_output(unsigned gpio, int value)
#endif
#ifdef CONFIG_DM_GPIO
+#include fdtdec.h
+DECLARE_GLOBAL_DATA_PTR;
+
static int mxc_gpio_is_output(struct gpio_regs *regs, int offset)
{
u32 val;
@@ -258,23 +262,6 @@ static const struct dm_gpio_ops gpio_mxc_ops = {
.get_function = mxc_gpio_get_function,
};
-static const struct mxc_gpio_plat mxc_plat[] = {
- { (struct gpio_regs *)GPIO1_BASE_ADDR },
- { (struct gpio_regs *)GPIO2_BASE_ADDR },
- { (struct gpio_regs *)GPIO3_BASE_ADDR },
-#if defined(CONFIG_MX25) || defined(CONFIG_MX27) || defined(CONFIG_MX51) || \
- defined(CONFIG_MX53) || defined(CONFIG_MX6)
- { (struct gpio_regs *)GPIO4_BASE_ADDR },
-#endif
-#if defined(CONFIG_MX27) || defined(CONFIG_MX53) || defined(CONFIG_MX6)
- { (struct gpio_regs *)GPIO5_BASE_ADDR },
- { (struct gpio_regs *)GPIO6_BASE_ADDR },
-#endif
-#if defined(CONFIG_MX53) || defined(CONFIG_MX6)
- { (struct gpio_regs *)GPIO7_BASE_ADDR },
-#endif
-};
-
static int mxc_gpio_probe(struct udevice *dev)
{
struct mxc_bank_info *bank = dev_get_priv(dev);
@@ -283,7 +270,7 @@ static int mxc_gpio_probe(struct udevice *dev)
int banknum;
char name[18], *str;
- banknum = plat - mxc_plat;
+ banknum = plat-bank_index;
sprintf(name, GPIO%d_, banknum + 1);
str = strdup(name);
if (!str)
@@ -295,12 +282,77 @@ static int mxc_gpio_probe(struct udevice *dev)
return 0;
}
+#ifdef CONFIG_OF_CONTROL
+static struct gpio_regs *mxc_get_gpio_addr(struct udevice *device)
+{
+ fdt_addr_t addr;
+ addr = fdtdec_get_addr(gd-fdt_blob, device-of_offset, reg);
+ if (addr == FDT_ADDR_T_NONE)
+ return NULL;
+ else
+ return (struct gpio_regs *)addr;
+}
+#else
+static struct gpio_regs *mxc_get_gpio_addr(struct udevice *device)
+{
+ return NULL;
+}
+#endif
In general, I'm fine with this concept, but I believe we should implement
a stub for fdtdec_get_addr() function in the fdtdec.h (say just returning
FDT_ADDR_T_NONE), as otherwise we might end up with multiple drivers
implementing the same noop callback just to work around a poor fdtdec_*()
interface.
+
+static int mxc_gpio_bind(struct udevice *device)
+{
+ struct mxc_gpio_plat *plat = device-platdata;
+ struct gpio_regs *regs;
+
+ if (plat)
+ return 0;
+
+ regs = mxc_get_gpio_addr(device);
+ if (!regs)
+ return -ENXIO;
+
+ plat = calloc(1, sizeof(*plat));
+ if (!plat)
+
Re: [U-Boot] Standalone API examples on the P4080DS
Thank you very much for this Peter, it's much appreciated, and should hopefully stop anyone else falling into the same trap! Thanks! Dave George On 16/01/2015 17:08, Peter Tyser wrote: Hi David, It looks like the entry point is 0x4. Why does the tutorial state that the example needs to be run from a 4 byte offset? In this case this will result in a failure to create a stack frame for hello_world. For PowerPC the entry point used to be non-deterministic, but was generally 0x40004 which is where the wiki value came from. The following 2 patches made the entry point consistently 0x4: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=620bbba524fbaa26971a5004793010b169824f1b http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=c91d456c055237bdadb99a80e198748b8cf32595 I updated the wiki to match the newer 0x4 address, which is valid for PowerPC boards with a comment to check out CONFIG_STANDALONE_LOAD_ADDR for other architectures. Peter Stay informed by joining the Rapita Systems mailing list http://www.rapitasystems.com/contact/mailing_list For real-time verifications issues and discussion, follow the Rapita Systems blog http://www.rapitasystems.com/blog ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: spl: Allow board_init_r() to run with a larger stack
Hello Simon, On Mon, 19 Jan 2015 12:39:34 -0700, Simon Glass s...@chromium.org wrote: Hi Albert, On 18 January 2015 at 23:54, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Simon, On Sun, 18 Jan 2015 11:55:36 -0700, Simon Glass s...@chromium.org wrote: At present SPL uses a single stack, either CONFIG_SPL_STACK or CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and environment) require a lot of stack, some boards set CONFIG_SPL_STACK to point into SDRAM. They then set up SDRAM very early, before board_init_f(), so that the larger stack can be used. This is an abuse of lowlevel_init(). That function should only be used for essential start-up code which cannot be delayed. An example of a valid use is when only part of the SPL code is visible/executable, and the SoC must be set up so that board_init_f() can be reached. It should not be used for SDRAM init, console init, etc. Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new address before board_init_r() is called in SPL. The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is now: Execution starts with start.S. Two main functions can be provided by the board implementation. The purpose and limitations of each is described below. After that, the common board_init_r() is called to perform the SPL task. lowlevel_init(): - purpose: essential init to permit execution to reach board_init_f() - no global_data, but there is a stack - must not set up SDRAM or use console - must only do the bare minimum to allow execution to continue to board_init_f() - this is almost never needed - return normally from this function board_init_f(): - purpose: set up the machine ready for running board_init_r(): i.e. SDRAM and serial UART - global_data is available - preloader_console_init() can be called here in extremis - stack is in SRAM - should set up SDRAM, and anything needed to make the UART work - these is no need to clear BSS, it will be done by crt0.S - must return normally from this function (don't call board_init_r() directly) Here the BSS is cleared. If CONFIG_SPL_STACK_R is defined, then at this point the stack and global_data are relocated to below that address. board_init_r(): - purpose: main execution, common code - global_data is available - SDRAM is available - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is defined and points into SDRAM - preloader_console_init() can be called here - typically this is done by defining CONFIG_SPL_BOARD_INIT and then supplying a spl_board_init() function containing this call - loads U-Boot or (in falcon mode) Linux Seems to me that now SPL and non-SPL boot sequences are mostly similar in the name, order and purpose of the functions called (which is a good thing!) so maybe this sequence should be described in a single document rather than in doc/README.SPL? Just opening the discussion; I have no strong opinion on this. Yes that is the idea. Yes I think it would be good to documentation this more generally, although I wonder if we should wait until some boards actually support this? :-) Not sure I'm getting your point: waiting for a board to support this may be a strongly preferred prerequisite for a custodian to apply the patchset (it would be for me if that landed in my custody, at least); but that does not prevent posting a v2 with a more complete boot sequence documentation in a dedicated file. Regards, Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/5] avr32: add generic board
On 01/20/2015 12:29 AM, Andreas Bießmann wrote: This is the first attempt to add generic board support to avr32 architecture. It has at least one relevant part for other manual reloc architectures. This series is currently runtime tested on grasshhopper only. I expect some changes regarding LCD support when testing the code on atstk1002. The DMA stuff is not tested yet but I expect no serios things here. The code is not run through checkpatch nor buildman at the time of writing. It seems MMC is not working properly yet! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot tools and build system
Hi, I'm working on the improvement of the recipes of u-boot in the Poky reference system of Yocto project. To do this, I need to fully understand the build system used in u-boot, mainly the u-boot tools (tools, env ..). My questions are: - what is the build system used in u-boot? - Does this build system change for building the tools? - What do I need to change when compiling the tools for the host architecture and for the target? - Can you pinpoint some documentation for me? Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 0/5] avr32: add generic board
This is the first attempt to add generic board support to avr32 architecture. It has at least one relevant part for other manual reloc architectures. This series is currently runtime tested on grasshhopper only. I expect some changes regarding LCD support when testing the code on atstk1002. The DMA stuff is not tested yet but I expect no serios things here. The code is not run through checkpatch nor buildman at the time of writing. Comments welcome! Especially for the TLB stuff placed in board_init_r. Andreas Bießmann Andreas Bießmann (5): avr32: use dlmalloc for DMA buffers avr32: rename cpu_init() - arch_cpu_init() common/board_r: manual relocation for cmd table avr32: add generic board support grasshopper: enable generic board arch/avr32/config.mk |3 ++ arch/avr32/cpu/cpu.c |2 +- arch/avr32/cpu/u-boot.lds|2 ++ arch/avr32/include/asm/config.h |1 + arch/avr32/include/asm/dma-mapping.h |7 - arch/avr32/include/asm/u-boot.h |9 ++ arch/avr32/lib/Makefile |2 ++ arch/avr32/lib/board.c | 53 +- arch/avr32/lib/interrupts.c |5 common/board_f.c | 13 +++-- common/board_r.c | 34 -- include/asm-generic/u-boot.h |4 +++ include/configs/atngw100.h |1 - include/configs/atngw100mkii.h |1 - include/configs/atstk1002.h |1 - include/configs/atstk1006.h |1 - include/configs/favr-32-ezkit.h |1 - include/configs/grasshopper.h|5 +++- include/configs/hammerhead.h |1 - include/configs/mimc200.h|1 - 20 files changed, 80 insertions(+), 67 deletions(-) -- 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] fdt: pci: Permit use of reg property for setting device address
+Thierry
Hi Bin,
On 20 January 2015 at 05:59, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Tue, Jan 20, 2015 at 11:19 AM, Simon Glass s...@chromium.org wrote:
In commit a62e84d the old functionality of obtaining a PCI address from the
'reg' property was lost. Add it back, so we can support both a compatible
string list and a 'reg' property.
This patch fixes PCIe ethernet on Tegra boards.
Signed-off-by: Simon Glass s...@chromium.org
---
lib/fdtdec.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 89dac4c..0488607 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -219,8 +219,14 @@ int fdtdec_get_pci_bdf(const void *blob, int node,
/* get vendor id device id from the compatible string */
ret = fdtdec_get_pci_vendev(blob, node, dt_vendor, dt_device);
- if (ret)
- return ret;
+ if (ret) {
+ /* Fall back to using the 'reg' property */
+ ret = fdtdec_get_int(blob, node, reg, -1);
+ if (ret == -1)
+ return -ENOENT;
+ *bdf = ret 0xff;
+ return 0;
+ }
/* extract the bdf from fdt_pci_addr */
*bdf = addr-phys_hi 0x00;
--
How is 'reg' encodeded in Tegra's dts? I feel we should start using
standard bindings instead of custom one.
This is as per the 'Numerical Representation' of the Physical Address
Formats (in pci supplement v2.1). It seems just as valid as the
textual ones.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12] sunxi: Move setting of CPU system control register SMP bit to save_boot_params
Hi, On 20-01-15 11:22, Albert ARIBAUD wrote: Hello Hans, On Mon, 19 Jan 2015 20:04:58 +0100, Hans de Goede hdego...@redhat.com wrote: Hi, On 17-01-15 23:51, Ian Campbell wrote: On Thu, 2015-01-15 at 15:52 +0100, Hans de Goede wrote: According to the Cortex-A7 MPCore Technical Reference Manual: You must ensure this bit is set to 1 before the caches and MMU are enabled, or any cache and TLB maintenance operations are performed. Given that this is a feature of the Cortex-A7 (actually, I believe it applies to at least Cortex-A15 too) and not really specific to sunxi, perhaps we can make this more generic? Strange enough the bit is different between the A7 and A15, for the A7 the docs say it must be set before doing anything with caches, on the A15 it only needs to be set for the core to accept cache management operations from other cpu cores (or so the docs say), which is likely why it is not in the standard init sequence yet, as for u-boot it seems to only be necessary to do this on a Cortex A7. I agree that it would be good to move this to the generic start.S though, Albert ? [...] Since arch/arm/cpu/armv7/start.S: cpu_init_cp15 does several cache operations, we should thus enable the SMP bit earlier, and the only chance to do that is to do it at save_boot_params time. Would it be so terrible to add an ifdef CORTEX_A7 here, or to call out to (or call as a macro) a soc_init_cp15? From my pov no that would not be too terrible, but ... I'm cc-ing Albert for input these questions. That indeed is Albert's call. I don't like the idea of #ifdef'ing that much. OTOH, if we do introduce soc_init_cp15, then we end up with two CP15 init functions, soc_init_cp15 and cpu_init_cp15, with all sorts of questions on which should be called first and whether one could break the other's work, and what happens in-between, etc. Either way, setting CP15 registers is something that all ARM CPUs, and SoCs require, not just armv7. It's just that other start.S files touch cp15 directly. I'm leaning toward grouping all CP15 inits (including cache(s) and TLB disabling and maybe VBAR setting) in a single CP15 call to a single soc_init_cp15 function. Now, SoCs with the same CPU will have a common CP15 init part, and that part could go into a cpu_init_cp15 function which soc_init_cp15 would call. Of course, since we're doing this way before we have any stack, we will have to handle nested calls by saving and restoring LR in intermediate function contexts. Note that solving this still leaves the A80 magic sram controller poke which also needs to happen really really early or otherwise the entire SoC just resets as if the watchdog has triggered, I'm fine with using save_boot_params for that, it is not its intended purpose, but it works fine for it, so I see no reason to complicate things with yet another callback. Maybe we could turn soc_init_cp15 into a more general soc_init function which would do whatever is needed, on cp15 or otherwise. (I see there is one soc_init defined, for spear600, but it is actually empty and could/should be removed. Patch anyone?) Hmm, so if I'm reading the above correctly, then I think you want to do the following: 1) Rename cpu_init_cp15 to cpu_init_cp15_common 2) Add a new soc_init function, with a weak default which just calls cpu_init_cp15_common 3) Add a a7_init_cp15 which sets the smp bit 4) Have Cortex A7 SoCs override soc_init with one which first calls a7_init_cp15 and then calls cpu_init_cp15_common 5) And on SoC's which need to do something special before or after cp15 init, they can do so by overriding soc_init and do what ever they need to do there before *or* after calling cpu_init_cp15_common Have I got that right ? If so I can try to write a patch-set for this, my arm asm is a bit weak, but I should be able to cobble this together using existing code as an example. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: video: Use frontend for dma on sun4i to fix memory bandwidth problems
Hi, On 20-01-15 10:14, Ian Campbell wrote: On Mon, 2015-01-19 at 11:29 +0100, Hans de Goede wrote: Testing has shown that on sun4i the display backend engine does not have deep enough fifo-s causing flickering / tearing in full-hd mode due to fifo underruns. On sun4i use the display frontend engine to do the dma from memory, as the frontend does have deep enough fifo-s. As added advantage of this is that it results in much better memory bandwidth as it reduces the amount of dram bank switches, for more details see: http://ssvb.github.io/2014/11/11/revisiting-fullhd-x11-desktop-performance-of-the-allwinner-a10.html Note that this changes the pipeline searched for in the simplefb node, we can get away with doing this now, since no kernel has yet shipped with simplefb dtb nodes, and I will make sure to get a simplefb node with the new pipeline into 3.19 before it ships. Looks good, there was discussion around the kernel patch, looks like it has resolved in favour of the patch though? Correct. Is it preferable to use the front or the backend (assuming sufficient fifo's etc)? IOW do we want to do this for all sun*i eventually, or only when the backend is insufficient for some reason? It is better to use the backend usually, as we need to have the backend enabled anyways (so only using it uses less power), it supports more formats, has 4 layers, where as we only have 1 frontend, etc. But on A10 using the backend does not work well due to fifo / DRAM access issues. +#ifdef CONFIG_MACH_SUN4I Perhaps another comment here, but in any case: Acked-by: Ian Campbell i...@hellion.org.uk Thanks, I've queued this one up in next. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mmc: fsl_esdhc: Add support for DDR mode
Add support of the DDR mode for eSDHC driver.
Enable it for i.MX6 SoC family only.
Change-Id: Ie27a945c9fe79d044cc886e269b60747f1744116
Signed-off-by: Volodymyr Riazantsev volodymyr.riazant...@globallogic.com
---
drivers/mmc/fsl_esdhc.c | 8 ++--
include/configs/mx6_common.h | 2 ++
include/fsl_esdhc.h | 1 +
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index c55eb28..f5d2ccb 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -319,7 +319,8 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct
mmc_data *data)
esdhc_write32(regs-cmdarg, cmd-cmdarg);
#if defined(CONFIG_FSL_USDHC)
esdhc_write32(regs-mixctrl,
- (esdhc_read32(regs-mixctrl) 0xFF80) | (xfertyp 0x7F));
+ (esdhc_read32(regs-mixctrl) 0xFF80) | (xfertyp 0x7F)
+ | (mmc-ddr_mode ? XFERTYP_DDREN : 0));
esdhc_write32(regs-xfertyp, xfertyp 0x);
#else
esdhc_write32(regs-xfertyp, xfertyp);
@@ -442,7 +443,7 @@ static void set_sysctl(struct mmc *mmc, uint clock)
if ((sdhc_clk / (div * pre_div)) = clock)
break;
- pre_div = 1;
+ pre_div = mmc-ddr_mode ? 2 : 1;
div -= 1;
clk = (pre_div 8) | (div 4);
@@ -601,6 +602,9 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg
*cfg)
}
cfg-cfg.host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT | MMC_MODE_HC;
+#ifdef CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
+ cfg-cfg.host_caps |= MMC_MODE_DDR_52MHz;
+#endif
if (cfg-max_bus_width 0) {
if (cfg-max_bus_width 8)
diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h
index e0528ce..29b72b2 100644
--- a/include/configs/mx6_common.h
+++ b/include/configs/mx6_common.h
@@ -28,6 +28,8 @@
#define CONFIG_SYS_PL310_BASE L2_PL310_BASE
#endif
+#define CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
+
#define CONFIG_MP
#define CONFIG_MXC_GPT_HCLK
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index c1b6648..313fa1e 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -108,6 +108,7 @@
#define XFERTYP_RSPTYP_48_BUSY 0x0003
#define XFERTYP_MSBSEL 0x0020
#define XFERTYP_DTDSEL 0x0010
+#define XFERTYP_DDREN 0x0008
#define XFERTYP_AC12EN 0x0004
#define XFERTYP_BCEN 0x0002
#define XFERTYP_DMAEN 0x0001
--
2.2.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fsl_esdhc: Add support for DDR mode
Hi Pantelis,
On Mon, Jan 19, 2015 at 10:47 AM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
Hi Volodymyr,
On Jan 14, 2015, at 22:46 , Volodymyr Riazantsev
volodymyr.riazant...@globallogic.com wrote:
Add support of the DDR mode for eSDHC driver.
Enable it for i.MX6 SoC family only.
Change-Id: Ie27a945c9fe79d044cc886e269b60747f1744116
Signed-off-by: Volodymyr Riazantsev volodymyr.riazant...@globallogic.com
---
drivers/mmc/fsl_esdhc.c | 8 ++--
include/fsl_esdhc.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index c55eb28..abec45f 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -319,7 +319,8 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
esdhc_write32(regs-cmdarg, cmd-cmdarg);
#if defined(CONFIG_FSL_USDHC)
esdhc_write32(regs-mixctrl,
- (esdhc_read32(regs-mixctrl) 0xFF80) | (xfertyp 0x7F));
+ (esdhc_read32(regs-mixctrl) 0xFF80) | (xfertyp 0x7F)
+ | (mmc-ddr_mode ? XFERTYP_DDREN : 0));
esdhc_write32(regs-xfertyp, xfertyp 0x);
#else
esdhc_write32(regs-xfertyp, xfertyp);
@@ -442,7 +443,7 @@ static void set_sysctl(struct mmc *mmc, uint clock)
if ((sdhc_clk / (div * pre_div)) = clock)
break;
- pre_div = 1;
+ pre_div = mmc-ddr_mode ? 2 : 1;
div -= 1;
clk = (pre_div 8) | (div 4);
@@ -601,6 +602,9 @@ int fsl_esdhc_initialize(bd_t *bis, struct
fsl_esdhc_cfg *cfg)
}
cfg-cfg.host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT | MMC_MODE_HC;
+#ifdef CONFIG_MX6
+ cfg-cfg.host_caps |= MMC_MODE_DDR_52MHz;
+#endif
if (cfg-max_bus_width 0) {
if (cfg-max_bus_width 8)
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index c1b6648..313fa1e 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -108,6 +108,7 @@
#define XFERTYP_RSPTYP_48_BUSY0x0003
#define XFERTYP_MSBSEL0x0020
#define XFERTYP_DTDSEL0x0010
+#define XFERTYP_DDREN0x0008
#define XFERTYP_AC12EN0x0004
#define XFERTYP_BCEN 0x0002
#define XFERTYP_DMAEN 0x0001
--
2.2.0
The patch is OK, but I don’t like the use of CONFIG_MX6 for enabling it.
The meaning is that the MMC IP block in MX6 supports DDR mode, so make it a
quirk
that’s enabled for MX6.
Subsequent SoCs might use the same mode, so I don’t like having to do endless
defines
of SoC families.
Please rework.
Regards
— Pantelis
Thank you for the comments,
I've reworked patch for get ability to enable this feature via
separate configuration flag. I put that flag into common mx6
header, otherwise we have to enable it for each separate mx6 board.
I didn't found way to run-time check for this feature on the
initialization path.
Best regards,
Volodymyr.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pci: tegra: Fix port information parsing
commit a62e84d7b1824a202dd incorrectly changed the tegra pci code to the
new fdtdec pci helpers. To get the device index of the root port, the
reg property should be parsed from the dtb (as was previously the
case).
With this patch i can successfully network boot my jetson tk1
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/pci/pci_tegra.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
index f9e05ad..67b5fdf 100644
--- a/drivers/pci/pci_tegra.c
+++ b/drivers/pci/pci_tegra.c
@@ -459,7 +459,6 @@ static int tegra_pcie_parse_port_info(const void *fdt, int
node,
unsigned int *lanes)
{
struct fdt_pci_addr addr;
- pci_dev_t bdf;
int err;
err = fdtdec_get_int(fdt, node, nvidia,num-lanes, 0);
@@ -470,13 +469,13 @@ static int tegra_pcie_parse_port_info(const void *fdt,
int node,
*lanes = err;
- err = fdtdec_get_pci_bdf(fdt, node, addr, bdf);
+ err = fdtdec_get_pci_addr(fdt, node, 0, reg, addr);
if (err 0) {
error(failed to parse \reg\ property);
return err;
}
- *index = PCI_DEV(bdf) - 1;
+ *index = PCI_DEV(addr.phys_hi) - 1;
return 0;
}
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] usb: musb-new: omap2430: Reset the MUSB controller early
On Mon, Jan 19, 2015 at 06:33:43PM +0100, Paul Kocialkowski wrote: When booting from USB peripheral boot, the bootrom will not properly deinit the MUSB controller, which doesn't clearly indicate an USB disconnection to the host and leaves U-Boot to deal with the state of the previous USB session. On some host controller drivers (e.g. xhci_hcd), this ends up in a failure during set address, caused by the lack of proper disconnection notification. Resetting the controller early in U-Boot notifies the host of the disconnection and doesn't hurt other use cases. Signed-off-by: Paul Kocialkowski cont...@paulk.fr Reviewed-by: Tom Rini tr...@ti.com -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/25] tegra: Add eDP support for nyan-big
Hi Tom,
On 1 December 2014 at 17:48, Simon Glass s...@chromium.org wrote:
This series adds eDP support for nyan-bg so that the display works.
Nyan-big is based on tegra124.
Some support is added for new clocks to make this work. The drm_dp_helper.h
file is brought in from Linux since many of the DisplayPort constants are
generic. A very simple uclass is added for DisplayPort, and the Tegra
driver makes use of that. The U-Boot EDID support is enhanced to read some
additional information (detailed timings).
There is existing video support for Tegra20, but I don't think it works for
Tegra30/114 (is this correct?). This series relies on detecting the display
at run-time as I cannot find a good device tree binding for things like
display depth. But if we could resolve that then it might be possible to
move Tegra20 over to use the same driver, etc. There is clearly a lot in
common with the display controllers - I have exploited this with the header
file but not with the C file.
HDMI is not supported at present. If this is easy and there is an existing
driver to follow along with then I might be able to incorporate it later.
This series is available at u-boot-dm/nyan-working
Does this series look OK?
Simon Glass (25):
dm: tegra: config: Increase pre-reloc malloc() to 6KB
fdt: Add binding decode function for display-timings
tegra: Move the pww into tegra-common
tegra: pwm: Allow the clock rate to be left as is
tegra: Move checkboard() into the board code
tegra: Add a board ID function
power: Export register access functions from as3722
tegra: Provide a function to allow LCD PMIC setup
tegra: Add support for setting up a as3722 PMIC
tegra: nyan-big: Add LCD PMIC init and board ID
tegra124: dts: Add host1x node to provide display information
tegra: config: Use CONFIG_LCD to detect LCD presence
tegra: clock: Add checking for invalid clock IDs
tegra: clock: Split the clock source code into a separate function
tegra124: clock: Add display clocks and functions
tegra: Move display controller header into common
video: Add drm_dp_helper.h
edid: Add a function to read detailed monitor timings
dm: video: Add a uclass for display port
tegra: dts: nyan-big: Add definitions for eDP display
tegra: video: Support serial output resource (SOR) on tegra124
tegra: video: Add Embedded DisplayPort driver
tegra: video: support eDP displays on Tegra124 devices
tegra: config: nyan-big: Enable LCD
tegra124: video: Add full link training for eDP
arch/arm/cpu/armv7/tegra-common/Makefile |1 +
arch/arm/cpu/armv7/{tegra20 = tegra-common}/pwm.c |5 +-
arch/arm/cpu/armv7/tegra20/Makefile|1 -
arch/arm/cpu/armv7/tegra20/display.c |2 +-
arch/arm/cpu/tegra-common/board.c |8 -
arch/arm/cpu/tegra-common/clock.c | 83 +-
arch/arm/cpu/tegra124-common/clock.c | 141 +-
arch/arm/dts/tegra124-nyan-big.dts | 47 +
arch/arm/dts/tegra124.dtsi | 84 ++
arch/arm/include/asm/arch-tegra/clk_rst.h | 15 +-
arch/arm/include/asm/arch-tegra/clock.h| 14 +
.../include/asm/{arch-tegra20 = arch-tegra}/dc.h | 63 +-
arch/arm/include/asm/arch-tegra/pwm.h | 60 +
arch/arm/include/asm/arch-tegra/sys_proto.h| 19 +-
arch/arm/include/asm/arch-tegra124/clock-tables.h |3 +-
arch/arm/include/asm/arch-tegra124/clock.h | 21 +
arch/arm/include/asm/arch-tegra124/display.h | 58 +
arch/arm/include/asm/arch-tegra124/pwm.h | 14 +
arch/arm/include/asm/arch-tegra20/display.h|2 +-
arch/arm/include/asm/arch-tegra20/pwm.h| 54 +-
board/nvidia/common/board.c| 40 +-
board/nvidia/nyan-big/nyan-big.c | 34 +-
common/edid.c | 106 ++
configs/nyan-big_defconfig |2 +
.../gpu/nvidia,tegra20-host1x.txt | 372 +
doc/device-tree-bindings/video/display-timing.txt | 110 ++
drivers/power/as3722.c | 16 +-
drivers/video/Kconfig | 14 +
drivers/video/Makefile |6 +
drivers/video/dp-uclass.c | 34 +
drivers/video/tegra124/Makefile| 10 +
drivers/video/tegra124/display.c | 354 +
drivers/video/tegra124/displayport.h | 412 ++
drivers/video/tegra124/dp.c| 1500
drivers/video/tegra124/sor.c | 951 +
drivers/video/tegra124/sor.h | 913
drivers/video/tegra124/tegra124-lcd.c | 94 ++
include/configs/nyan-big.h | 13 +
Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address
(Corrected the u-boot list address in the cc of this thread and added Kevin hilman who is also quite interested in this topic) On Tue, 2015-01-20 at 10:36 +0100, Sjoerd Simons wrote: Hey Suriyan, I just noticed the patchset Akshay Saraswat sent (Add support for booting multiple cores), which would hopefully fix some issues wrt. booting secondary cores we've seen on the XU3 thusfar. Unfortunately, those fixes need to be applied in the SPL stage, hence coming back to the BL2 story :). Any updates you can share? Separately i do wonder if getting a (very basic?) signed BL2 to chainload an unsigned SPL might not be the best way forward here. Would allow us to fix SPL issues in u-boot without having to ask hardkernel to sign every time ? :/ On Fri, 2014-12-19 at 15:45 -0800, Suriyan Ramasami wrote: Just to close the loop. For the XU3, scanning memory, I found the signed BL2 loaded at address 0x02027000. Regards - Suriyan PS: Any pointers with regards to mem_ctrl_init() is appreciated. On Fri, Dec 19, 2014 at 12:43 PM, Suriyan Ramasami suriya...@gmail.com wrote: Hello All, Greetings! I have been dabbling with trying to get mainline SPL working on the Odroid XU3. The issue that I am facing is that currently I do not know what address the BL1 loads and passes control to the SPL (signed BL2). Of course, I could get another SPL signed from Hard kernel and have the address written out in some memory address, but I thought if someone has access to the documents it might be faster to get this information. As an update ... So far, I have successfully gotten an Hardkernel based SPL to chain load an unsigned SPL from mainline. I am hitting some issues in mem_ctrl_init() or so I think. I was wondering if the issues were cause of it being initialized twice (one from the signed BL2) and the other from the mainline SPL that is chain loaded. Thanks - Suriyan smime.p7s Description: S/MIME cryptographic signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB
Sorry, missed this. Yes, looks good to me. I can apply it to u-boot-tegra/master, or TomR can take it in to master U-Boot directly. Tom -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Monday, January 19, 2015 3:57 PM To: u-boot@lists.denx.de; Simon Glass; Tom Warren; Stephen Warren Cc: Tom Rini Subject: Re: [U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB On 12/23/2014 10:34 AM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Some systems have so much RAM that the end of RAM is beyond 4GB. An example would be a Tegra124 system (where RAM starts at 2GB physical) that has more than 2GB of RAM. In this case, we can gd-ram_size to represent the actual RAM size, so that the actual RAM size is passed to the OS. This is useful if the OS implements LPAE, and can actually use the extra RAM. However, U-Boot does not implement LPAE and so must deal with 32-bit physical addresses. To this end, we enhance board_get_usable_ram_top() to detect the over-sized case, and limit the relocation addres so that it fits into 32-bits of physical address space. TomW, TomR, does this series look good? --- 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/3] common: board: support systems with where RAM ends beyond 4GB
I've merged that patch series w/u-boot-tegra/next and /master, done a MAKEALL -s tegra, and rebased against ARM /master and pushed to denx.de. Stephen - please test and if it looks OK, I'll prepare a PR. -Original Message- From: Tom Warren Sent: Tuesday, January 20, 2015 8:28 AM To: 'Stephen Warren'; u-boot@lists.denx.de; Simon Glass; Stephen Warren Cc: Tom Rini Subject: RE: [U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB Sorry, missed this. Yes, looks good to me. I can apply it to u-boot- tegra/master, or TomR can take it in to master U-Boot directly. Tom -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Monday, January 19, 2015 3:57 PM To: u-boot@lists.denx.de; Simon Glass; Tom Warren; Stephen Warren Cc: Tom Rini Subject: Re: [U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB On 12/23/2014 10:34 AM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Some systems have so much RAM that the end of RAM is beyond 4GB. An example would be a Tegra124 system (where RAM starts at 2GB physical) that has more than 2GB of RAM. In this case, we can gd-ram_size to represent the actual RAM size, so that the actual RAM size is passed to the OS. This is useful if the OS implements LPAE, and can actually use the extra RAM. However, U-Boot does not implement LPAE and so must deal with 32-bit physical addresses. To this end, we enhance board_get_usable_ram_top() to detect the over-sized case, and limit the relocation addres so that it fits into 32-bits of physical address space. TomW, TomR, does this series look good? --- 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] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address
Hello Kevin, On Tue, Jan 20, 2015 at 3:38 PM, Suriyan Ramasami suriya...@gmail.com wrote: Hello Kevin, On Tue, Jan 20, 2015 at 3:29 PM, Suriyan Ramasami suriya...@gmail.com wrote: Hello Kevin, On Tue, Jan 20, 2015 at 2:43 PM, Kevin Hilman khil...@kernel.org wrote: Suriyan Ramasami suriya...@gmail.com writes: Hello Kevin, These are the changes that would be necessary in uboot mainline for SPL: arch/arm/cpu/armv7/exynos/Kconfig - select OF_CONTROL + select SUPPORT_SPL + select OF_CONTROL if !SPL_BUILD configs/odroid-xu3_defconfig +CONFIG_SPL=y include/configs/odroid_xu3.h #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x02027000 #undef CONFIG_SEC_FW_SIZE #define CONFIG_SEC_FW_SIZE (15 10) /* 15 KB */ Thanks. With those changes, a build gives me: ./include/common.h:355:73: fatal error: asm/u-boot-sandbox.h: No such file or directory Sorry for the dumb questions, but I'm not very familiar with u-boot. I'm more comofortable in the kernel. The above used to work (a month ago). I shall check with current mainline uboot and report back. Sorry for the snafu. I t was my mistake. The correct diff for the configs is as below: diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 7fcb5d2..39953e4 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -26,7 +26,8 @@ config TARGET_ODROID config TARGET_ODROID_XU3 bool Exynos5422 Odroid board - select OF_CONTROL + select SUPPORT_SPL + select OF_CONTROL if !SPL_BUILD config TARGET_ARNDALE bool Exynos5250 Arndale board diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig index 74aa0cf..6000ec1 100644 --- a/configs/odroid-xu3_defconfig +++ b/configs/odroid-xu3_defconfig @@ -1,4 +1,5 @@ -CONFIG_ARM=y -CONFIG_ARCH_EXYNOS=y -CONFIG_TARGET_ODROID_XU3=y +CONFIG_SPL=y ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_EXYNOS=y ++S:CONFIG_TARGET_ODROID_XU3=y CONFIG_DEFAULT_DEVICE_TREE=exynos5422-odroidxu3 FWICT, mainline uboot does not have code to handle secure firmware. For instance when secure firmware is present the address to poke a jump address for the CPU is different (nsram +1c etc). This stems from lowlevel_init.S being moved over to the NS area. This is also missing in uboot mainline or so I think. Hmm, it seems the XU3 has secure firmware so I guess this wont' be useful for me yet? It should be relevant to you, as mainline uboot does not overlay the NS area with a bootstrap code from lowlevel_init.S. At least I have seen mainline linux src code using this address for waking up the CPUs (so does XEN). I just checked the patch you were referring to, and Akshay has indeed pulled in the the .S file I was referring to. https://patchwork.ozlabs.org/patch/429425/ (sec_boot.s) Hence, things should be more doable - Suriyan Curious what platforms you're testing this on? And are any of them using secure firmware? I am currently working only on the XU3 (I thought there was no interest, so I let it slide). I probably should say that the Exynos secure firmware support needs to be tweaked in U-Boot. Maybe other SoCs are supported? I am not sure. Also, I'm still a bit unsure where the switch from secure to NS world happens. Is that in BL1? or somewhere in BL2? If it's in BL2, have you tried switching secure mode off? I know for sure that the signed BL2 does switch from Hyp to NS. This BL2 that I am referring to is HK's nomenclature, which translates to BL1 (SPL) in UBoot lingo. Hence, this adds some confusion in the discussions! The blobs are as follows: (possibly listed in the HK web pages) BL0 (signed encrypted blob from Samsung). This loads HK's signed BL2 (this is U-Boot SPL) This loads U-Boot (U-Boot BL2) and the Trustzone Also, no matter what mode the odroid xu3 is in, the linux kernel from what I can tell depending on the secure-firmware dts entry (which is present) will use the NS + 1c area when powering on the CPU. Hence, its mandatory to have code there. I hope this helps you out. Well, it's certainly a step in the right direction, but not sure yet if I can use it on the odroid-xu3 as I'm still trying to understand the boot sequence. Kevin The ddr init functions seem to be not correct for the 5422 (or so I think). I do not have access to any of the Samsung docs, hence, one solution was to copy over HKs ddr init function, and then the mainline SPL runs. Regards - Suriyan On Tue, Jan 20, 2015 at 1:30 PM, Kevin Hilman khil...@kernel.org wrote: Hello Suriyan, Suriyan Ramasami suriya...@gmail.com writes: Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The
Re: [U-Boot] Please pull u-boot-arc master
On Thu, Jan 15, 2015 at 08:39:45PM +, Alexey Brodkin wrote: Dear Tom, The following changes since commit 28c4dae114c9b94b2ad81d4da716e9fc2cba: Merge branch 'next' of git://git.denx.de/u-boot-video (2015-01-14 16:26:15 -0500) are available in the git repository at: git://git.denx.de/u-boot-arc.git for you to fetch changes up to fdff23702a361e89a15333231af4d00d6e2a: arc: rename arc700 in arcv1 (2015-01-15 22:40:50 +0300) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-mmc 19012015
On Mon, Jan 19, 2015 at 05:50:26PM +0200, Pantelis Antoniou wrote: The following changes since commit ab77f24119e80257de4ab017b877f92f96980562: Merge branch 'master' of git://git.denx.de/u-boot-ti (2015-01-16 10:25:01 -0500) are available in the git repository at: git://git.denx.de/u-boot-mmc.git master for you to fetch changes up to fc5b32fbf3bd43dabaf409e424e0bfb9a1b4df26: mmc: Skip changing bus width for MMC cards earlier than version 4.0 (2015-01-19 17:41:52 +0200) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,PULL] u-boot-usb/master
On Sun, Jan 18, 2015 at 12:33:47PM +0100, Marek Vasut wrote: The following changes since commit ab77f24119e80257de4ab017b877f92f96980562: Merge branch 'master' of git://git.denx.de/u-boot-ti (2015-01-16 10:25:01 -0500) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 119339759266b81af1aa8883702b6b651d7752dd: usb: eth: asix88179: add ability to modify MAC address (2015-01-18 12:31:36 +0100) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] usb: fastboot: implement fastboot
- add bcm_usb_gadget.c
- implement fastboot on 'bcm28155_ap' boards
Signed-off-by: Steve Rae s...@broadcom.com
---
drivers/usb/gadget/Makefile | 2 +
drivers/usb/gadget/bcm_usb_gadget.c | 240
include/configs/bcm28155_ap.h | 20 ++-
3 files changed, 261 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/gadget/bcm_usb_gadget.c
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 70bb550..8b55c1f 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -20,6 +20,8 @@ obj-$(CONFIG_USBDOWNLOAD_GADGET) += g_dnl.o
obj-$(CONFIG_DFU_FUNCTION) += f_dfu.o
obj-$(CONFIG_USB_GADGET_MASS_STORAGE) += f_mass_storage.o
obj-$(CONFIG_CMD_FASTBOOT) += f_fastboot.o
+obj-$(CONFIG_BCM_UDC_OTG) += bcm_usb_gadget.o
+obj-$(CONFIG_BCM_UDC_OTG) += bcm_udc_otg.o
endif
ifdef CONFIG_USB_ETHER
obj-y += ether.o
diff --git a/drivers/usb/gadget/bcm_usb_gadget.c
b/drivers/usb/gadget/bcm_usb_gadget.c
new file mode 100644
index 000..cc7e182
--- /dev/null
+++ b/drivers/usb/gadget/bcm_usb_gadget.c
@@ -0,0 +1,240 @@
+/*
+ * Copyright 2015 Broadcom Corporation.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include config.h
+#include common.h
+#include malloc.h
+
+#include linux/usb/ch9.h
+#include linux/usb/gadget.h
+
+#include bcm_udc_otg.h
+
+/* fwd declarations */
+static struct usb_request *in_req;
+static struct usb_request *out_req;
+
+#define RESPONSE_LEN (64 + 1)
+
+/*
+ * usb_ep_ops: stub callback functions
+ */
+
+static int stub_enable(struct usb_ep *ep,
+ const struct usb_endpoint_descriptor *desc)
+{
+ printf(called: %s\n, __func__);
+ return 0;
+}
+
+static int stub_disable(struct usb_ep *ep)
+{
+ printf(called: %s\n, __func__);
+ return 0;
+}
+
+static struct usb_request *stub_alloc_request(struct usb_ep *ep,
+ gfp_t gfp_flags)
+{
+ printf(called: %s\n, __func__);
+ return NULL;
+}
+
+static void stub_free_request(struct usb_ep *ep, struct usb_request *req)
+{
+ printf(called: %s\n, __func__);
+}
+
+/*
+ * static int stub_queue(struct usb_ep *ep, struct usb_request *request,
+ * gfp_t gfp_flags)
+ */
+
+static int stub_dequeue(struct usb_ep *ep, struct usb_request *request)
+{
+ printf(called: %s\n, __func__);
+ return 0;
+}
+
+static int stub_set_halt(struct usb_ep *ep, int value)
+{
+ printf(called: %s\n, __func__);
+ return 0;
+}
+
+static int stub_fifo_status(struct usb_ep *ep)
+{
+ printf(called: %s\n, __func__);
+ return 0;
+}
+
+static void stub_fifo_flush(struct usb_ep *ep)
+{
+ printf(called: %s\n, __func__);
+}
+
+/*
+ * usb_ep_ops: implement callback functions
+ */
+
+static int queue_bulk_in_ep(struct usb_ep *ep, struct usb_request *req,
+ gfp_t gfp_flags)
+{
+ int ret;
+ /* verify: only send requests (in_req) on this bulk endpoint */
+ if (req != in_req) {
+ error(fatal %p %p, req, in_req);
+ return -1;
+ }
+
+ /* send a packet via the bulk endpoint */
+ ret = usb_send_bulk_otg(req-buf, strlen(req-buf));
+ if (ret)
+ printf(%s: usb_send_bulk_otg() returned: %d\n, __func__, ret);
+
+ if (req-complete)
+ req-complete(ep, req);
+ else
+ printf(%s: skipping complete()\n, __func__);
+
+ return ret;
+}
+
+static int queue_bulk_out_ep(struct usb_ep *ep, struct usb_request *req,
+gfp_t gfp_flags)
+{
+ /* verify: only receive requests (out_req) on this bulk endpoint */
+ if (req != out_req) {
+ error(fatal %p %p, req, out_req);
+ return -1;
+ }
+
+ /* calling req-complete causes infinite loop, therefore, do nothing */
+
+ return 0;
+}
+
+/* initial values for USB Endpoint Operations */
+static const struct usb_ep_ops out_ep_ops = {
+ .enable = stub_enable,
+ .disable= stub_disable,
+ .alloc_request = stub_alloc_request,
+ .free_request = stub_free_request,
+ .queue = queue_bulk_out_ep,
+ .dequeue= stub_dequeue,
+ .set_halt = stub_set_halt,
+ .fifo_status= stub_fifo_status,
+ .fifo_flush = stub_fifo_flush
+};
+
+static const struct usb_ep_ops in_ep_ops = {
+ .enable = stub_enable,
+ .disable= stub_disable,
+ .alloc_request = stub_alloc_request,
+ .free_request = stub_free_request,
+ .queue = queue_bulk_in_ep,
+ .dequeue= stub_dequeue,
+ .set_halt = stub_set_halt,
+ .fifo_status= stub_fifo_status,
+ .fifo_flush = stub_fifo_flush
+};
+
+/* initial values for USB Endpoints */
+static struct usb_ep in_ep_init = {
+ .name = in_ep,
+ .ops= in_ep_ops,
+
Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address
Suriyan Ramasami suriya...@gmail.com writes: Hello Kevin, These are the changes that would be necessary in uboot mainline for SPL: arch/arm/cpu/armv7/exynos/Kconfig - select OF_CONTROL + select SUPPORT_SPL + select OF_CONTROL if !SPL_BUILD configs/odroid-xu3_defconfig +CONFIG_SPL=y include/configs/odroid_xu3.h #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x02027000 #undef CONFIG_SEC_FW_SIZE #define CONFIG_SEC_FW_SIZE (15 10) /* 15 KB */ Thanks. With those changes, a build gives me: ./include/common.h:355:73: fatal error: asm/u-boot-sandbox.h: No such file or directory Sorry for the dumb questions, but I'm not very familiar with u-boot. I'm more comofortable in the kernel. FWICT, mainline uboot does not have code to handle secure firmware. For instance when secure firmware is present the address to poke a jump address for the CPU is different (nsram +1c etc). This stems from lowlevel_init.S being moved over to the NS area. This is also missing in uboot mainline or so I think. Hmm, it seems the XU3 has secure firmware so I guess this wont' be useful for me yet? Curious what platforms you're testing this on? And are any of them using secure firmware? Also, I'm still a bit unsure where the switch from secure to NS world happens. Is that in BL1? or somewhere in BL2? If it's in BL2, have you tried switching secure mode off? I hope this helps you out. Well, it's certainly a step in the right direction, but not sure yet if I can use it on the odroid-xu3 as I'm still trying to understand the boot sequence. Kevin The ddr init functions seem to be not correct for the 5422 (or so I think). I do not have access to any of the Samsung docs, hence, one solution was to copy over HKs ddr init function, and then the mainline SPL runs. Regards - Suriyan On Tue, Jan 20, 2015 at 1:30 PM, Kevin Hilman khil...@kernel.org wrote: Hello Suriyan, Suriyan Ramasami suriya...@gmail.com writes: Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows: BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625. I'm currently running mainline u-boot, and hoping to test the series that powers down secondary cores on the odroid-xu3. That series applies and builds with mainline u-boot (v2015.01-rc3), but for it to work correctly, IIUC, I'll also need to build an SPL from mainline. Can you share your changes to mainline u-boot that enable the building of SPL? I'd like to try that using your BL2 that will load an unsigned BL2. Thanks, Kevin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/11] Add support for booting multiple cores
Akshay Saraswat aksha...@samsung.com writes: This patch series introduces changes for booting secondary CPUs on Exynos5420 and Exynos5800. Thanks for this series. I think this should help get the odroid-xu3 behave better with the mainline linux kernel (assuming I can get it working with mainline u-boot/SPL.) Are you testing this on mainline u-boot? Can you describe what platforms you've tested this on and whether or not those platforms are using secure firmware? Kevin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot warnings on Nokia N900
On Thu, Jan 15, 2015 at 10:18:01AM +0100, Pali Rohár wrote: On Thursday 15 January 2015 10:07:05 Pali Rohár wrote: Hello, when starting U-Boot (from git master) on Nokia N900 it show lot of these lines on N900 screen: Timed out in wait_for_event: status= Check if pads/pull-ups of bus 1 are properly configured Timed out in wait_for_event: status= Check if pads/pull-ups of bus 1 are properly configured ... i2c_read (addr phase): pads on bus 1 probably not configured (status=0x10) i2c_write: timeout writing last byte! But booting linux kernel working without problem. What above warning messages means? They were not in U-Boot 2013.04 version. Ok, these warning/error lines are generated by this code: /* reset lp5523 led */ i2c_set_bus_num(1); state = 0xff; i2c_write(0x32, 0x3d, 1, state, 1); i2c_set_bus_num(0); in function misc_init_r() in file board/nokia/rx51/rx51.c Above code worked fine in U-Boot 2013.04 and now in U-Boot from git master it generates warnings/errors. Why? Sadly I think you'll have to git bisect to see just when things changed. This area of code is a bit finicky to say the least. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] This series implements fastboot on the bcm28155_ap boards.
Since a complete gadget implementation is not available yet, this series provides a method for interfacing the existing gadget code with the UDC driver code. Steve Rae (4): usb: gadget: fastboot: add CONFIG_FASTBOOT_NO_GADGET support usb: add 'bcm_udc_otg' support usb: update 'sysmap.h' usb: fastboot: implement fastboot arch/arm/include/asm/arch-bcm281xx/sysmap.h | 141 drivers/usb/gadget/Makefile |2 + drivers/usb/gadget/bcm_udc_otg.c| 1193 +++ drivers/usb/gadget/bcm_udc_otg.h| 19 + drivers/usb/gadget/bcm_usb_gadget.c | 240 ++ drivers/usb/gadget/f_fastboot.c | 39 + include/configs/bcm28155_ap.h | 20 +- 7 files changed, 1653 insertions(+), 1 deletion(-) create mode 100644 drivers/usb/gadget/bcm_udc_otg.c create mode 100644 drivers/usb/gadget/bcm_udc_otg.h create mode 100644 drivers/usb/gadget/bcm_usb_gadget.c -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address
Hello Suriyan, Suriyan Ramasami suriya...@gmail.com writes: Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows: BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625. I'm currently running mainline u-boot, and hoping to test the series that powers down secondary cores on the odroid-xu3. That series applies and builds with mainline u-boot (v2015.01-rc3), but for it to work correctly, IIUC, I'll also need to build an SPL from mainline. Can you share your changes to mainline u-boot that enable the building of SPL? I'd like to try that using your BL2 that will load an unsigned BL2. Thanks, Kevin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address
Hello Kevin, On Tue, Jan 20, 2015 at 3:29 PM, Suriyan Ramasami suriya...@gmail.com wrote: Hello Kevin, On Tue, Jan 20, 2015 at 2:43 PM, Kevin Hilman khil...@kernel.org wrote: Suriyan Ramasami suriya...@gmail.com writes: Hello Kevin, These are the changes that would be necessary in uboot mainline for SPL: arch/arm/cpu/armv7/exynos/Kconfig - select OF_CONTROL + select SUPPORT_SPL + select OF_CONTROL if !SPL_BUILD configs/odroid-xu3_defconfig +CONFIG_SPL=y include/configs/odroid_xu3.h #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x02027000 #undef CONFIG_SEC_FW_SIZE #define CONFIG_SEC_FW_SIZE (15 10) /* 15 KB */ Thanks. With those changes, a build gives me: ./include/common.h:355:73: fatal error: asm/u-boot-sandbox.h: No such file or directory Sorry for the dumb questions, but I'm not very familiar with u-boot. I'm more comofortable in the kernel. The above used to work (a month ago). I shall check with current mainline uboot and report back. Sorry for the snafu. I t was my mistake. The correct diff for the configs is as below: diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 7fcb5d2..39953e4 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -26,7 +26,8 @@ config TARGET_ODROID config TARGET_ODROID_XU3 bool Exynos5422 Odroid board - select OF_CONTROL + select SUPPORT_SPL + select OF_CONTROL if !SPL_BUILD config TARGET_ARNDALE bool Exynos5250 Arndale board diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig index 74aa0cf..6000ec1 100644 --- a/configs/odroid-xu3_defconfig +++ b/configs/odroid-xu3_defconfig @@ -1,4 +1,5 @@ -CONFIG_ARM=y -CONFIG_ARCH_EXYNOS=y -CONFIG_TARGET_ODROID_XU3=y +CONFIG_SPL=y ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_EXYNOS=y ++S:CONFIG_TARGET_ODROID_XU3=y CONFIG_DEFAULT_DEVICE_TREE=exynos5422-odroidxu3 FWICT, mainline uboot does not have code to handle secure firmware. For instance when secure firmware is present the address to poke a jump address for the CPU is different (nsram +1c etc). This stems from lowlevel_init.S being moved over to the NS area. This is also missing in uboot mainline or so I think. Hmm, it seems the XU3 has secure firmware so I guess this wont' be useful for me yet? It should be relevant to you, as mainline uboot does not overlay the NS area with a bootstrap code from lowlevel_init.S. At least I have seen mainline linux src code using this address for waking up the CPUs (so does XEN). Curious what platforms you're testing this on? And are any of them using secure firmware? I am currently working only on the XU3 (I thought there was no interest, so I let it slide). I probably should say that the Exynos secure firmware support needs to be tweaked in U-Boot. Maybe other SoCs are supported? I am not sure. Also, I'm still a bit unsure where the switch from secure to NS world happens. Is that in BL1? or somewhere in BL2? If it's in BL2, have you tried switching secure mode off? I know for sure that the signed BL2 does switch from Hyp to NS. This BL2 that I am referring to is HK's nomenclature, which translates to BL1 (SPL) in UBoot lingo. Hence, this adds some confusion in the discussions! The blobs are as follows: (possibly listed in the HK web pages) BL0 (signed encrypted blob from Samsung). This loads HK's signed BL2 (this is U-Boot SPL) This loads U-Boot (U-Boot BL2) and the Trustzone Also, no matter what mode the odroid xu3 is in, the linux kernel from what I can tell depending on the secure-firmware dts entry (which is present) will use the NS + 1c area when powering on the CPU. Hence, its mandatory to have code there. I hope this helps you out. Well, it's certainly a step in the right direction, but not sure yet if I can use it on the odroid-xu3 as I'm still trying to understand the boot sequence. Kevin The ddr init functions seem to be not correct for the 5422 (or so I think). I do not have access to any of the Samsung docs, hence, one solution was to copy over HKs ddr init function, and then the mainline SPL runs. Regards - Suriyan On Tue, Jan 20, 2015 at 1:30 PM, Kevin Hilman khil...@kernel.org wrote: Hello Suriyan, Suriyan Ramasami suriya...@gmail.com writes: Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows: BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625. I'm currently running mainline
Re: [U-Boot] [PATCHv1 01/22] arm: socfpga: spl: Add main sdram code
On 01/14/2015 05:34 PM, Marek Vasut wrote: On Wednesday, January 14, 2015 at 05:40:41 PM, dingu...@opensource.altera.com wrote: From: Dinh Nguyen dingu...@opensource.altera.com Hi! This adds the code to configure the SDRAM controller that is found in the SoCFGPA Cyclone5 and Arria5 platforms. Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com --- arch/arm/cpu/armv7/socfpga/config.mk |3 +- board/altera/socfpga/Makefile |1 + board/altera/socfpga/sdram/Makefile| 12 + board/altera/socfpga/sdram/sdram_config.h | 100 + board/altera/socfpga/sdram/sdram_io.h | 44 + board/altera/socfpga/sdram/sequencer.c | 7993 A general remark: SDRAM stuff should most likely reside in drivers/ddr/ , don't you think so ? Yes, I suppose. Move it to drivers/ddr/altera? board/altera/socfpga/sdram/sequencer.h | 504 ++ board/altera/socfpga/sdram/sequencer_auto.h| 216 + .../altera/socfpga/sdram/sequencer_auto_ac_init.c | 88 + snip @@ -0,0 +1,44 @@ +/* + * Copyright Altera Corporation (C) 2012-2014. All rights reserved + * + * SPDX-License-Identifier:BSD-3-Clause Any chance we can get these files under GPL-2.0+ ? It's not a showstopper, but it'd be nice :) + */ + +#include asm/io.h + +#ifdef CONFIG_SPL_SERIAL_SUPPORT +#define HPS_HW_SERIAL_SUPPORT Are these redundant definitions really needed ? Probably not, but I can check again. +#endif + +#define HPS_SDR_BASESOCFPGA_SDR_ADDRESS This here as well, just use SOCFPGA_SDR_ADDRESS in the code. Besides, it'd be nice to consistently use space after #define keyword. +#define MGR_SELECT_MASK 0xf8000 + +#define APB_BASE_SCC_MGRSDR_PHYGRP_SCCGRP_ADDRESS +#define APB_BASE_PHY_MGRSDR_PHYGRP_PHYMGRGRP_ADDRESS +#define APB_BASE_RW_MGR SDR_PHYGRP_RWMGRGRP_ADDRESS +#define APB_BASE_DATA_MGR SDR_PHYGRP_DATAMGRGRP_ADDRESS +#define APB_BASE_REG_FILE SDR_PHYGRP_REGFILEGRP_ADDRESS +#define APB_BASE_MMRSDR_CTRLGRP_ADDRESS More redundancy here. Will fix in v2. +#define __AVL_TO_APB(ADDR) \ +ADDR) MGR_SELECT_MASK) == (BASE_PHY_MGR)) ? \ +(APB_BASE_PHY_MGR) | (((ADDR) (14-6)) (0x16)) | \ +((ADDR) 0x3f) : \ +(((ADDR) MGR_SELECT_MASK) == (BASE_RW_MGR)) ? \ +(APB_BASE_RW_MGR) | ((ADDR) 0x1fff) : \ +(((ADDR) MGR_SELECT_MASK) == (BASE_DATA_MGR)) ? \ +(APB_BASE_DATA_MGR) | ((ADDR) 0x7ff) : \ +(((ADDR) MGR_SELECT_MASK) == (BASE_SCC_MGR)) ? \ +(APB_BASE_SCC_MGR) | ((ADDR) 0xfff) : \ +(((ADDR) MGR_SELECT_MASK) == (BASE_REG_FILE)) ? \ +(APB_BASE_REG_FILE) | ((ADDR) 0x7ff) : \ +(((ADDR) MGR_SELECT_MASK) == (BASE_MMR)) ? \ +(APB_BASE_MMR) | ((ADDR) 0xfff) : -1) + This stuff here should be a function, to get a proper typechecking on it. Ok. +#define IOWR_32DIRECT(BASE, OFFSET, DATA) \ +writel(DATA, HPS_SDR_BASE + __AVL_TO_APB((uint32_t)((BASE) + \ +(OFFSET + +#define IORD_32DIRECT(BASE, OFFSET) \ +readl(HPS_SDR_BASE + __AVL_TO_APB((uint32_t)((BASE) + (OFFSET OK, these macros look really questionable. You might want to make them into a function too, but before you do so, I'd rather suggest you rethink this entire _AVL_TO_APB usage and make this entire section more readable. The code is really confusing here. Will look to fix in V2. + diff --git a/board/altera/socfpga/sdram/sequencer.c b/board/altera/socfpga/sdram/sequencer.c new file mode 100644 index 000..c0ba0e5 --- /dev/null +++ b/board/altera/socfpga/sdram/sequencer.c @@ -0,0 +1,7993 @@ +/* + * Copyright Altera Corporation (C) 2012-2014. All rights reserved + * + * SPDX-License-Identifier:BSD-3-Clause + */ + +#include common.h +#include asm/io.h +#include asm/arch/sdram.h +#include sdram_io.h +#include sequencer.h +#include sequencer_auto.h +#include sequencer_defines.h +#include system.h + +static void scc_mgr_load_dqs_for_write_group(uint32_t write_group); +static void rw_mgr_mem_dll_lock_wait(void); + +/* * + ** + ** NOTE: Special Rules for Globale Variables ** + ** ** + ** All global variables that are explicitly initialized (including ** + ** explicitly initialized to zero), are only initialized once, during ** + ** configuration time, and not again on reset. This means that they** + ** preserve their current contents across resets, which is needed for some ** + ** special cases involving communication with external modules. In ** + ** addition, this avoids paying the
Re: [U-Boot] [U-Boot,3/9] sunxi: Drop use of lowlevel_init()
On Tue, Dec 23, 2014 at 12:04:53PM -0700, Simon Glass wrote: This does nothing now, so drop it. We have SPL anyway to do our low-level init. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Ian Campbell i...@hellion.org.uk Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,5/9] zynq: Remove reference to gdata
On Tue, Dec 23, 2014 at 12:04:55PM -0700, Simon Glass wrote: The global_data pointer (gd) has already been set before board_init_f() is called. We should not assign it again. We should also not use gdata since it is going away. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,7/9] imx: woodburn: Remove reference to gdata
On Tue, Dec 23, 2014 at 12:04:57PM -0700, Simon Glass wrote: The global_data pointer (gd) has already been set before board_init_f() is called. We should not assign it again. We should also not use gdata since it is going away. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Stefano Babic sba...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, RFT, 1/2] TI ARMv7: Don't use GD before crt0.S has set it
On Fri, Dec 19, 2014 at 04:53:24PM -0500, Tom Rini wrote: Prior to this change we set the gd pointer early so that we can store data in it. This becomes problematic for DM changes as well as being odd in general. Re-work the code paths so that we don't need to set the gd pointer so early and instead can rely upon the normal setting of it. In order to do this we do need to move certain calls from s_init into spl_board_init(), mainly preloader_console_init and save_omap_boot_params. Tested on: Beaglebone Black, AM43xx GP EVM, Beagleboard, Beagleboard xM, OMAP5 uEVM, DRA7xx EVM Signed-off-by: Tom Rini tr...@ti.com Tested-by: Simon Glass s...@chromium.org Reviewed-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,8/9] imx: ls102xa: Remove reference to gdata
On Tue, Dec 23, 2014 at 12:04:58PM -0700, Simon Glass wrote: The global_data pointer (gd) has already been set before board_init_f() is called. We should not assign it again. We should also not use gdata since it is going away. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use generic board architecture for MPC837xERDB
On Sat, Jan 17, 2015 at 02:09:13AM -0500, Sinan Akman wrote: Signed-off-by: Sinan Akman si...@writeme.com Cc: kim.phill...@freescale.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: Only compile board.o for CONFIG_SPL_BUILD
All of the code in arch/arm/cpu/armv7/sunxi/board.c was under a check for CONFIG_SPL_BUILD so instead only build for SPL. This lets us drop a hunk of code that was never enabled. Cc: Hans de Goede hdego...@redhat.com Cc: Ian Campbell i...@hellion.org.uk Signed-off-by: Tom Rini tr...@ti.com --- arch/arm/cpu/armv7/sunxi/Makefile |2 +- arch/arm/cpu/armv7/sunxi/board.c | 15 --- 2 files changed, 1 insertion(+), 16 deletions(-) diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile index 1720f7d..1fbfb6c 100644 --- a/arch/arm/cpu/armv7/sunxi/Makefile +++ b/arch/arm/cpu/armv7/sunxi/Makefile @@ -8,7 +8,6 @@ # SPDX-License-Identifier: GPL-2.0+ # obj-y += timer.o -obj-y += board.o obj-y += clock.o obj-y += cpu_info.o obj-y += pinmux.o @@ -30,6 +29,7 @@ endif endif ifdef CONFIG_SPL_BUILD +obj-y += board.o obj-$(CONFIG_MACH_SUN4I) += dram_sun4i.o obj-$(CONFIG_MACH_SUN5I) += dram_sun4i.o obj-$(CONFIG_MACH_SUN6I) += dram_sun6i.o diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c index f4a580a..5998548 100644 --- a/arch/arm/cpu/armv7/sunxi/board.c +++ b/arch/arm/cpu/armv7/sunxi/board.c @@ -15,9 +15,7 @@ #include netdev.h #include miiphy.h #include serial.h -#ifdef CONFIG_SPL_BUILD #include spl.h -#endif #include asm/gpio.h #include asm/io.h #include asm/arch/clock.h @@ -27,10 +25,6 @@ #include linux/compiler.h -#ifdef CONFIG_SPL_BUILD -/* Pointer to the global data structure for SPL */ -DECLARE_GLOBAL_DATA_PTR; - /* The sunxi internal brom will try to loader external bootloader * from mmc0, nand flash, mmc2. * Unfortunately we can't check how SPL was loaded so assume @@ -92,14 +86,6 @@ void board_init_f(ulong dummy) * access gets messed up (seems cache related) */ setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800); #endif -#if !defined CONFIG_SPL_BUILD (defined CONFIG_MACH_SUN7I || \ - defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I) - /* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */ - asm volatile( - mrc p15, 0, r0, c1, c0, 1\n - orr r0, r0, #1 6\n - mcr p15, 0, r0, c1, c0, 1\n); -#endif clock_init(); timer_init(); @@ -186,4 +172,3 @@ int cpu_eth_init(bd_t *bis) return 0; } -#endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MAINTAINERS: add me as the maintainer of mpc837xerdb
On Sat, Jan 17, 2015 at 06:54:52PM -0500, Sinan Akman wrote: Signed-off-by: Sinan Akman si...@writeme.com Cc: Tom Rini tr...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,6/9] imx: cm_fx6: Remove reference to gdata
On Tue, Dec 23, 2014 at 12:04:56PM -0700, Simon Glass wrote: The global_data pointer (gd) has already been set before board_init_f() is called. We should not assign it again. We should also not use gdata since it is going away. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Igor Grinberg grinb...@compulab.co.il Tested-by: Nikita Kiryanov nik...@compulab.co.il Acked-by: Nikita Kiryanov nik...@compulab.co.il Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/9] arm: Add warnings about using gdata
On Tue, Dec 23, 2014 at 12:04:51PM -0700, Simon Glass wrote: We need to get rid of this SPL-specific setting of the global_data pointer. It is already set up in start.S immediately before board_init_f() is called, and there may be information there that is needed (e.g. pre-reloc malloc info). Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/9] sunxi: Move SPL s_init() code to board_init_f()
On Tue, Dec 23, 2014 at 12:04:52PM -0700, Simon Glass wrote: The current sunxi implementation uses gdata, which is going away. It also sets up DRAM before board_init_f() in SPL. There is really no reason to do much in s_init() since board_init_f() is called immediately afterwards. The only change is that we need our own implementation of board_init_f() which sets up DRAM before the BSS (which is in DRAM) is cleared. The s_init() code runs once for SPL and again for U-Boot proper. We shouldn't need to init the clock/timer/gpio/i2c init twice, so just have it in SPL. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address
Hello Kevin, These are the changes that would be necessary in uboot mainline for SPL: arch/arm/cpu/armv7/exynos/Kconfig - select OF_CONTROL + select SUPPORT_SPL + select OF_CONTROL if !SPL_BUILD configs/odroid-xu3_defconfig +CONFIG_SPL=y include/configs/odroid_xu3.h #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x02027000 #undef CONFIG_SEC_FW_SIZE #define CONFIG_SEC_FW_SIZE (15 10) /* 15 KB */ FWICT, mainline uboot does not have code to handle secure firmware. For instance when secure firmware is present the address to poke a jump address for the CPU is different (nsram +1c etc). This stems from lowlevel_init.S being moved over to the NS area. This is also missing in uboot mainline or so I think. I hope this helps you out. The ddr init functions seem to be not correct for the 5422 (or so I think). I do not have access to any of the Samsung docs, hence, one solution was to copy over HKs ddr init function, and then the mainline SPL runs. Regards - Suriyan On Tue, Jan 20, 2015 at 1:30 PM, Kevin Hilman khil...@kernel.org wrote: Hello Suriyan, Suriyan Ramasami suriya...@gmail.com writes: Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows: BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625. I'm currently running mainline u-boot, and hoping to test the series that powers down secondary cores on the odroid-xu3. That series applies and builds with mainline u-boot (v2015.01-rc3), but for it to work correctly, IIUC, I'll also need to build an SPL from mainline. Can you share your changes to mainline u-boot that enable the building of SPL? I'd like to try that using your BL2 that will load an unsigned BL2. Thanks, Kevin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] usb: update 'sysmap.h'
Add the required definitions for the USB OTG interface. Signed-off-by: Steve Rae s...@broadcom.com --- arch/arm/include/asm/arch-bcm281xx/sysmap.h | 141 1 file changed, 141 insertions(+) diff --git a/arch/arm/include/asm/arch-bcm281xx/sysmap.h b/arch/arm/include/asm/arch-bcm281xx/sysmap.h index 93ebf34..69f0fb9 100644 --- a/arch/arm/include/asm/arch-bcm281xx/sysmap.h +++ b/arch/arm/include/asm/arch-bcm281xx/sysmap.h @@ -27,4 +27,145 @@ #define SECWD2_BASE_ADDR 0x35002f40 #define TIMER_BASE_ADDR0x3e00d000 +#define HSOTG_OTGCTL_OFFSET0x +#defineHSOTG_OTGCTL_SESREQ_MASK0x0002 +#define HSOTG_OTGINT_OFFSET0x0004 +#defineHSOTG_OTGINT_DBNCEDONE_MASK 0x0008 +#defineHSOTG_OTGINT_ADEVTOUTCHG_MASK 0x0004 +#defineHSOTG_OTGINT_SESREQSUCSTSCHNG_MASK 0x0100 +#defineHSOTG_OTGINT_SESENDDET_MASK 0x0004 +#define HSOTG_AHBCFG_OFFSET0x0008 +#defineHSOTG_AHBCFG_NPTXFEMPLVL_MASK 0x0080 +#defineHSOTG_AHBCFG_DMAEN_MASK 0x0020 +#defineHSOTG_AHBCFG_GLBLINTRMSK_MASK 0x0001 +#define HSOTG_CFG_OFFSET 0x000C +#defineHSOTG_CFG_USBTRDTIM_SHIFT 10 +#defineHSOTG_CFG_HNPCAP_MASK 0x0200 +#defineHSOTG_CFG_SRPCAP_MASK 0x0100 +#defineHSOTG_CFG_ULPI_UTMI_SEL_MASK 0x0010 +#define HSOTG_RSTCTL_OFFSET0x0010 +#defineHSOTG_RSTCTL_AHBIDLE_MASK 0x8000 +#defineHSOTG_RSTCTL_CSFTRST_MASK 0x0001 +#define HSOTG_INTSTS_OFFSET0x0014 +#defineHSOTG_INTSTS_WKUPINT_MASK 0x8000 +#defineHSOTG_INTSTS_OEPINT_MASK0x0008 +#defineHSOTG_INTSTS_IEPINT_MASK0x0004 +#defineHSOTG_INTSTS_ENUMDONE_MASK 0x2000 +#defineHSOTG_INTSTS_USBSUSP_MASK 0x0800 +#defineHSOTG_INTSTS_ERLYSUSP_MASK 0x0400 +#defineHSOTG_INTSTS_OTGINT_MASK0x0004 +#defineHSOTG_INTSTS_CURMOD_MASK0x0001 +#define HSOTG_INTMSK_OFFSET0x0018 +#defineHSOTG_INTMSK_WKUPINTMSK_MASK 0x8000 +#defineHSOTG_INTMSK_DISCONNINTMSK_MASK 0x2000 +#defineHSOTG_INTMSK_OEPINTMSK_MASK 0x0008 +#defineHSOTG_INTMSK_INEPINTMSK_MASK 0x0004 +#defineHSOTG_INTMSK_ENUMDONEMSK_MASK 0x2000 +#defineHSOTG_INTMSK_USBRSTMSK_MASK 0x1000 +#defineHSOTG_INTMSK_USBSUSPMSK_MASK 0x0800 +#defineHSOTG_INTMSK_ERLYSUSPMSK_MASK 0x0400 +#defineHSOTG_INTMSK_OTGINTMSK_MASK 0x0004 +#define HSOTG_RXFSIZ_OFFSET0x0024 +#defineHSOTG_RXFSIZ_RXFDEP_SHIFT 0 +#define HSOTG_NPTXFSIZ_OFFSET 0x0028 +#defineHSOTG_NPTXFSIZ_NPTXFDEP_SHIFT 16 +#defineHSOTG_NPTXFSIZ_NPTXFSTADDR_SHIFT0 +#define HSOTG_DIEPTXF1_OFFSET 0x0104 +#defineHSOTG_DIEPTXF1_INEPNTXFDEP_SHIFT16 +#defineHSOTG_DIEPTXF1_INEPNTXFSTADDR_SHIFT 0 +#define HSOTG_DCFG_OFFSET 0x0800 +#defineHSOTG_DCFG_EPMISCNT_SHIFT 18 +#defineHSOTG_DCFG_PERFRINT_SHIFT 11 +#defineHSOTG_DCFG_DEVADDR_SHIFT4 +#define HSOTG_DCTL_OFFSET 0x0804 +#defineHSOTG_DCTL_TSTCTL_MASK 0x0070 +#defineHSOTG_DCTL_SFTDISCON_MASK 0x0002 +#define HSOTG_DSTS_OFFSET 0x0808 +#defineHSOTG_DSTS_ENUMSPD_SHIFT1 +#defineHSOTG_DSTS_ENUMSPD_MASK 0x0006 +#define HSOTG_DIEPMSK_OFFSET 0x0810 +#defineHSOTG_DIEPMSK_TIMEOUTMSK_MASK 0x0008 +#defineHSOTG_DIEPMSK_AHBERRMSK_MASK 0x0004 +#defineHSOTG_DIEPMSK_EPDISBLDMSK_MASK
[U-Boot] [PATCH 2/4] usb: add 'bcm_udc_otg' support
Implement the UDC support for the USB OTG interface.
Signed-off-by: Steve Rae s...@broadcom.com
---
This commit is not checkpatch clean - however, there seems to be
no way to remove this warning:
warning: drivers/usb/gadget/bcm_udc_otg.c,97:
Adding new packed members is to be done with care
drivers/usb/gadget/bcm_udc_otg.c | 1193 ++
drivers/usb/gadget/bcm_udc_otg.h | 19 +
2 files changed, 1212 insertions(+)
create mode 100644 drivers/usb/gadget/bcm_udc_otg.c
create mode 100644 drivers/usb/gadget/bcm_udc_otg.h
diff --git a/drivers/usb/gadget/bcm_udc_otg.c b/drivers/usb/gadget/bcm_udc_otg.c
new file mode 100644
index 000..706e003
--- /dev/null
+++ b/drivers/usb/gadget/bcm_udc_otg.c
@@ -0,0 +1,1193 @@
+/*
+ * Copyright 2015 Broadcom Corporation.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include config.h
+#include asm/io.h
+#include asm/arch/sysmap.h
+#include asm/kona-common/clk.h
+#include bcm_udc_otg.h
+
+#ifdef CONFIG_CMD_SERIALNO
+#include serial_no.h
+#endif
+
+#include usbdevice.h
+
+#define DEVICE_STRING_LANGUAGE_ID_INDEX0
+#define DEVICE_STRING_PRODUCT_INDEX1
+#define DEVICE_STRING_SERIAL_NUMBER_INDEX 2
+#define DEVICE_STRING_CONFIG_INDEX 3
+#define DEVICE_STRING_INTERFACE_INDEX 4
+#define DEVICE_STRING_MANUFACTURER_INDEX 5
+#define DEVICE_STRING_MAX_INDEXDEVICE_STRING_MANUFACTURER_INDEX
+
+#define FASTBOOT_INTERFACE_CLASS 0xff
+#define FASTBOOT_INTERFACE_SUB_CLASS 0x42
+#define FASTBOOT_INTERFACE_PROTOCOL0x03
+
+#define wfld_set(addr, fld_val, fld_mask) \
+ (writel(((readl(addr) ~(fld_mask)) | (fld_val)), (addr)))
+#define wfld_clear(addr, fld_mask) \
+ (writel((readl(addr) ~(fld_mask)), (addr)))
+
+#define DEVICE_STRING_LANGUAGE_ID 0x0409 /* English (United States) */
+
+/*
+ * In high speed mode rx packets are 512
+ * In full speed mode rx packets are 64
+ */
+#define RX_ENDPOINT_MAXIMUM_PACKET_SIZE(0x0200)
+#define TX_ENDPOINT_MAXIMUM_PACKET_SIZE(0x0040)
+
+#ifndef CONFIG_USB_BOARDNAME
+#define CONFIG_USB_BOARDNAME Board
+#endif
+
+#ifndef CONFIG_USB_CONFIGURATION
+#define CONFIG_USB_CONFIGURATION Fastboot
+#endif
+
+#ifndef CONFIG_USB_INTERFACE
+#define CONFIG_USB_INTERFACE Fastboot
+#endif
+
+#ifndef CONFIG_USB_SERIALNO
+#define CONFIG_USB_SERIALNO 1234567890
+#endif
+
+#ifndef CONFIG_USBID_ADDR
+#error CONFIG_USBID_ADDR must be defined!
+#endif
+
+static char *usb_device_strings[DEVICE_STRING_MANUFACTURER_INDEX + 1] = {
+ /* Language = */ ,
+ /* Product =*/ CONFIG_USB_BOARDNAME,
+ /* Serial = */ CONFIG_USB_SERIALNO,
+ /* Config = */ CONFIG_USB_CONFIGURATION,
+ /* Interface = */ CONFIG_USB_INTERFACE,
+ /* Manufacturer = */ CONFIG_G_DNL_MANUFACTURER,
+};
+
+static struct usb_device_descriptor dfu_dev_descriptor
+ __aligned(4) = {
+ .bLength= 0x12,
+ .bDescriptorType= USB_DT_DEVICE,
+ .bcdUSB = 0x100,
+ .bDeviceClass = 0xff,
+ .bDeviceSubClass= 0xff,
+ .bDeviceProtocol= 0xff,
+ .bMaxPacketSize0= 64, /* depends on enum speed */
+ .idVendor = CONFIG_G_DNL_VENDOR_NUM,
+ .idProduct = CONFIG_G_DNL_PRODUCT_NUM,
+ .bcdDevice = 0x0001,
+ .iManufacturer = DEVICE_STRING_MANUFACTURER_INDEX,
+ .iProduct = DEVICE_STRING_PRODUCT_INDEX,
+ .iSerialNumber = DEVICE_STRING_SERIAL_NUMBER_INDEX,
+ .bNumConfigurations = 0x1,
+};
+
+struct full_configuration_descriptor {
+ struct usb_configuration_descriptor c;
+ struct usb_interface_descriptor i;
+ struct usb_endpoint_descriptor e1;
+ struct usb_endpoint_descriptor e2;
+} __packed;
+
+static struct full_configuration_descriptor full_desc
+ __aligned(4) = {
+.c = {
+ .bLength= 0x9,
+ .bDescriptorType= USB_DT_CONFIG,
+ .wTotalLength = sizeof(struct usb_configuration_descriptor) +
+ sizeof(struct usb_interface_descriptor) +
+ sizeof(struct usb_endpoint_descriptor) +
+ sizeof(struct usb_endpoint_descriptor),
+ .bNumInterfaces = 1,
+ .bConfigurationValue= 1,
+ .iConfiguration = DEVICE_STRING_CONFIG_INDEX,
+ .bmAttributes = BMATTRIBUTE_RESERVED |
+ BMATTRIBUTE_SELF_POWERED,
+ .bMaxPower = 0,
+},
+.i = {
+ .bLength= 0x9,
+
[U-Boot] [PATCH 1/4] usb: gadget: fastboot: add CONFIG_FASTBOOT_NO_GADGET support
Implement fastboot_func_init() which provides a minimalistic setup
of the USB endpoints and requests required by the fastboot gadget.
Signed-off-by: Steve Rae s...@broadcom.com
---
drivers/usb/gadget/f_fastboot.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 6d3f05b..455f768 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -47,15 +47,18 @@ struct f_fastboot {
struct usb_request *in_req, *out_req;
};
+#ifndef CONFIG_FASTBOOT_NO_GADGET
static inline struct f_fastboot *func_to_fastboot(struct usb_function *f)
{
return container_of(f, struct f_fastboot, usb_function);
}
+#endif
static struct f_fastboot *fastboot_func;
static unsigned int download_size;
static unsigned int download_bytes;
+#ifndef CONFIG_FASTBOOT_NO_GADGET
static struct usb_endpoint_descriptor fs_ep_in = {
.bLength= USB_DT_ENDPOINT_SIZE,
.bDescriptorType= USB_DT_ENDPOINT,
@@ -120,6 +123,7 @@ static struct usb_gadget_strings *fastboot_strings[] = {
stringtab_fastboot,
NULL,
};
+#endif
static void rx_handler_command(struct usb_ep *ep, struct usb_request *req);
@@ -131,6 +135,7 @@ static void fastboot_complete(struct usb_ep *ep, struct
usb_request *req)
printf(status: %d ep '%s' trans: %d\n, status, ep-name, req-actual);
}
+#ifndef CONFIG_FASTBOOT_NO_GADGET
static int fastboot_bind(struct usb_configuration *c, struct usb_function *f)
{
int id;
@@ -293,6 +298,7 @@ static int fastboot_add(struct usb_configuration *c)
return status;
}
DECLARE_GADGET_BIND_CALLBACK(usb_dnl_fastboot, fastboot_add);
+#endif
static int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
{
@@ -576,3 +582,36 @@ static void rx_handler_command(struct usb_ep *ep, struct
usb_request *req)
usb_ep_queue(ep, req, 0);
}
}
+
+#ifdef CONFIG_FASTBOOT_NO_GADGET
+void fastboot_func_init(struct usb_ep *in_ep, struct usb_ep *out_ep,
+ struct usb_request *in_req, struct usb_request *out_req)
+{
+ struct f_fastboot *f_fb = fastboot_func;
+
+ /* see above: fastboot_add() */
+ if (!f_fb) {
+ f_fb = memalign(CONFIG_SYS_CACHELINE_SIZE, sizeof(*f_fb));
+ if (!f_fb) {
+ printf(%s: fatal!\n, __func__);
+ return;
+ }
+
+ fastboot_func = f_fb;
+ memset(f_fb, 0, sizeof(*f_fb));
+ }
+
+ /* initialize IN/OUT EP's and corresponding requests */
+ f_fb-in_ep = in_ep;
+ f_fb-out_ep = out_ep;
+ f_fb-in_req = in_req;
+ f_fb-out_req = out_req;
+
+ /* initialize 'complete' handlers */
+ f_fb-in_req-complete = fastboot_complete;
+ f_fb-out_req-complete = rx_handler_command;
+
+ /* initialize data */
+ f_fb-out_req-length = EP_BUFFER_SIZE;
+}
+#endif
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] dm: i2c: Rename driver model I2C functions to permit compatibility
On 12 January 2015 at 18:02, Simon Glass s...@chromium.org wrote: Add a dm_ prefix to driver model I2C functions so that we can keep the old ones around. This is a little unfortunate, but on reflection it is too difficult to change the API. We can undo this rename when most boards and drivers are converted to use driver model for I2C. Signed-off-by: Simon Glass s...@chromium.org --- board/avionic-design/common/tamonten-ng.c | 2 +- board/nvidia/cardhu/cardhu.c | 8 ++--- board/nvidia/dalmore/dalmore.c| 6 ++-- board/nvidia/whistler/whistler.c | 10 +++--- board/toradex/apalis_t30/apalis_t30.c | 6 ++-- common/cmd_i2c.c | 28 --- common/exports.c | 3 +- drivers/i2c/i2c-uclass.c | 9 ++--- drivers/power/as3722.c| 4 +-- drivers/power/tps6586x.c | 4 +-- include/i2c.h | 19 +- test/dm/i2c.c | 60 +++ 12 files changed, 82 insertions(+), 77 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] dm: i2c: Add a compatbility layer
On 12 January 2015 at 18:02, Simon Glass s...@chromium.org wrote: For boards which use multiple I2C devices, or for SOCs which support multiple boards, we might want to convert these to driver model at different times. At present this is difficult because we need to either use CONFIG_DM_I2C for a board or not. Add a compatibility layer which implements the old API, thus allowing a board to move to driver model for I2C without requiring that everything it uses is moved in the same commit. Signed-off-by: Simon Glass s...@chromium.org --- Makefile| 7 +++ drivers/i2c/Makefile| 1 + drivers/i2c/i2c-uclass-compat.c | 98 + include/i2c.h | 59 + 4 files changed, 165 insertions(+) create mode 100644 drivers/i2c/i2c-uclass-compat.c Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: Drop gpio.h header from fdtdec.c
On 15 January 2015 at 09:19, Simon Glass s...@chromium.org wrote: Since GPIO support has now moved to the driver model uclass, we can drop this include. Signed-off-by: Simon Glass s...@chromium.org --- lib/fdtdec.c | 2 -- 1 file changed, 2 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: tegra: Fix port information parsing
Hi,
On Wed, Jan 21, 2015 at 3:05 AM, Simon Glass s...@chromium.org wrote:
Hi Sjoerd,
On 20 January 2015 at 10:06, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
commit a62e84d7b1824a202dd incorrectly changed the tegra pci code to the
new fdtdec pci helpers. To get the device index of the root port, the
reg property should be parsed from the dtb (as was previously the
case).
With this patch i can successfully network boot my jetson tk1
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/pci/pci_tegra.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Can you also please take a look at this patch?
http://patchwork.ozlabs.org/patch/430815/
It tries to support both options.
Although I still don't see how the Tegra's dts is written, I feel this
patch is doing correctly.
diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
index f9e05ad..67b5fdf 100644
--- a/drivers/pci/pci_tegra.c
+++ b/drivers/pci/pci_tegra.c
@@ -459,7 +459,6 @@ static int tegra_pcie_parse_port_info(const void *fdt,
int node,
unsigned int *lanes)
{
struct fdt_pci_addr addr;
- pci_dev_t bdf;
int err;
err = fdtdec_get_int(fdt, node, nvidia,num-lanes, 0);
@@ -470,13 +469,13 @@ static int tegra_pcie_parse_port_info(const void *fdt,
int node,
*lanes = err;
- err = fdtdec_get_pci_bdf(fdt, node, addr, bdf);
+ err = fdtdec_get_pci_addr(fdt, node, 0, reg, addr);
I suggest replace 0 to FDT_PCI_SPACE_CONFIG.
if (err 0) {
error(failed to parse \reg\ property);
return err;
}
- *index = PCI_DEV(bdf) - 1;
+ *index = PCI_DEV(addr.phys_hi) - 1;
return 0;
}
Based on this patch, I think Tegra's dts just uses reg to encode the
device number into fdt_pci_addr.phys_hi. The bus number and function
number are not there.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] EXYNOS5: Add function to enable exynos5420 usbdev phy ctrl
Exynos5420 has different registers with other exynos5 SoCs to control
usb device phy, so need separated function to enable exynos5420 usb
device phy.
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
I used usbdev instead of usbdrd on function name because registers
name prefix is usbdev_.
arch/arm/cpu/armv7/exynos/power.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index 1520d64..1b12051 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -102,10 +102,34 @@ static void exynos5_set_usbdrd_phy_ctrl(unsigned int
enable)
}
}
+static void exynos5420_set_usbdev_phy_ctrl(unsigned int enable)
+{
+ struct exynos5420_power *power =
+ (struct exynos5420_power *)samsung_get_base_power();
+
+ if (enable) {
+ /* Enabling USBDEV_PHY */
+ setbits_le32(power-usbdev_phy_control,
+ POWER_USB_DRD_PHY_CTRL_EN);
+ setbits_le32(power-usbdev1_phy_control,
+ POWER_USB_DRD_PHY_CTRL_EN);
+ } else {
+ /* Disabling USBDEV_PHY */
+ clrbits_le32(power-usbdev_phy_control,
+ POWER_USB_DRD_PHY_CTRL_EN);
+ clrbits_le32(power-usbdev1_phy_control,
+ POWER_USB_DRD_PHY_CTRL_EN);
+ }
+}
+
void set_usbdrd_phy_ctrl(unsigned int enable)
{
- if (cpu_is_exynos5())
- exynos5_set_usbdrd_phy_ctrl(enable);
+ if (cpu_is_exynos5()) {
+ if (proid_is_exynos5420() || proid_is_exynos5800())
+ exynos5420_set_usbdev_phy_ctrl(enable);
+ else
+ exynos5_set_usbdrd_phy_ctrl(enable);
+ }
}
static void exynos5_dp_phy_control(unsigned int enable)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dm:gpio:mxc add DT support
Hi, Igor
On 1/20/2015 10:39 PM, Igor Grinberg wrote:
On 01/20/15 09:15, Peng Fan wrote:
This patch add DT support for mxc gpio driver.
Include a bank_index entry in platdata. This can avoid using
`plat - mxc_plat` to calculate bank number. Also this can simplify code.
Although, I don't insist, but I would recommend to split the patch into 2:
the bank_index rework and the DT support addition.
Ok. I can split this in v3 patch.
There are two places still using CONFIG_OF_CONTROL macro, just to
shrink code size if only support DM but not support DT.
1. The U_BOOT_DEVICES and mxc_plat array are complied out. To DT,
platdata is alloced using calloc, so there is no need to use mxc_plat.
2. add a function mxc_get_gpio_addr to get reg property if DT support.
If no DT, this function just returns NULL.
I have some comments on this one, please see below...
Reply below.
The following situations are tested:
1. with DM, without DT
2. with DM and DT
3. without DM
Since device tree has not been upstreamed, if want to test this patch.
The followings need to be done.
+ pieces of code does not gpio_request when using gpio_direction_xxx and
etc, need to request gpio.
+ move the gpio settings from board_early_init_f to board_init
+ define CONFIG_DM ,CONFIG_DM_GPIO and CONFIG_OF_CONTROL
+ Add device tree file and do related configuration in
`make ARCH=arm menuconfig`
These will be done in future patches by step.
Signed-off-by: Peng Fan peng@freescale.com
---
Changes v2:
1. remove uneccessary #ifdef
2. add more stuff in commit log
3. include a new function mxc_get_gpio_addr to get register base.
This function is different for DT and not DT, by `#ifdef`.
If using one implementation for DT and not DT, final image will be big.
4. include a new entry in platdata, named bank_index. it can simplify DT
support. To no DT, bank_index is static initilized; to DT, bank_index
is get from device's req_seq.
drivers/gpio/mxc_gpio.c | 89 +++--
1 file changed, 71 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
index 8bb9e39..5826620 100644
--- a/drivers/gpio/mxc_gpio.c
+++ b/drivers/gpio/mxc_gpio.c
@@ -23,6 +23,7 @@ enum mxc_gpio_direction {
#define GPIO_PER_BANK 32
struct mxc_gpio_plat {
+ int bank_index;
struct gpio_regs *regs;
};
@@ -150,6 +151,9 @@ int gpio_direction_output(unsigned gpio, int value)
#endif
#ifdef CONFIG_DM_GPIO
+#include fdtdec.h
+DECLARE_GLOBAL_DATA_PTR;
+
static int mxc_gpio_is_output(struct gpio_regs *regs, int offset)
{
u32 val;
@@ -258,23 +262,6 @@ static const struct dm_gpio_ops gpio_mxc_ops = {
.get_function = mxc_gpio_get_function,
};
-static const struct mxc_gpio_plat mxc_plat[] = {
- { (struct gpio_regs *)GPIO1_BASE_ADDR },
- { (struct gpio_regs *)GPIO2_BASE_ADDR },
- { (struct gpio_regs *)GPIO3_BASE_ADDR },
-#if defined(CONFIG_MX25) || defined(CONFIG_MX27) || defined(CONFIG_MX51) || \
- defined(CONFIG_MX53) || defined(CONFIG_MX6)
- { (struct gpio_regs *)GPIO4_BASE_ADDR },
-#endif
-#if defined(CONFIG_MX27) || defined(CONFIG_MX53) || defined(CONFIG_MX6)
- { (struct gpio_regs *)GPIO5_BASE_ADDR },
- { (struct gpio_regs *)GPIO6_BASE_ADDR },
-#endif
-#if defined(CONFIG_MX53) || defined(CONFIG_MX6)
- { (struct gpio_regs *)GPIO7_BASE_ADDR },
-#endif
-};
-
static int mxc_gpio_probe(struct udevice *dev)
{
struct mxc_bank_info *bank = dev_get_priv(dev);
@@ -283,7 +270,7 @@ static int mxc_gpio_probe(struct udevice *dev)
int banknum;
char name[18], *str;
- banknum = plat - mxc_plat;
+ banknum = plat-bank_index;
sprintf(name, GPIO%d_, banknum + 1);
str = strdup(name);
if (!str)
@@ -295,12 +282,77 @@ static int mxc_gpio_probe(struct udevice *dev)
return 0;
}
+#ifdef CONFIG_OF_CONTROL
+static struct gpio_regs *mxc_get_gpio_addr(struct udevice *device)
+{
+ fdt_addr_t addr;
+ addr = fdtdec_get_addr(gd-fdt_blob, device-of_offset, reg);
+ if (addr == FDT_ADDR_T_NONE)
+ return NULL;
+ else
+ return (struct gpio_regs *)addr;
+}
+#else
+static struct gpio_regs *mxc_get_gpio_addr(struct udevice *device)
+{
+ return NULL;
+}
+#endif
In general, I'm fine with this concept, but I believe we should implement
a stub for fdtdec_get_addr() function in the fdtdec.h (say just returning
FDT_ADDR_T_NONE), as otherwise we might end up with multiple drivers
implementing the same noop callback just to work around a poor fdtdec_*()
interface.
I tried to implement a stub function in fdtdec.h like this:
__weak fdt_addr_t fdtdec_get_addr_wrap()
{
return FDT_ADDR_T_NONE;
}
And in driver code, implement non weak version as following:
#ifdef CONFIG_OF_CONTROL
fdt_addr_t fdtdec_get_addr_wrap()
{
[U-Boot] [PATCH] mpc837xerdb: fix Calling __hwconfig without a buffer warning
Signed-off-by: Sinan Akman si...@writeme.com
---
board/freescale/mpc837xerdb/mpc837xerdb.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mpc837xerdb/mpc837xerdb.c
b/board/freescale/mpc837xerdb/mpc837xerdb.c
index e0a1031..565f815 100644
--- a/board/freescale/mpc837xerdb/mpc837xerdb.c
+++ b/board/freescale/mpc837xerdb/mpc837xerdb.c
@@ -166,8 +166,13 @@ int board_early_init_f(void)
int board_mmc_init(bd_t *bd)
{
struct immap __iomem *im = (struct immap __iomem *)CONFIG_SYS_IMMR;
+ char buffer[HWCONFIG_BUFFER_SIZE] = {0};
+ int esdhc_hwconfig_enabled = 0;
- if (!hwconfig(esdhc))
+ if (getenv_f(hwconfig, buffer, sizeof(buffer)) 0)
+ esdhc_hwconfig_enabled = hwconfig_f(esdhc, buffer);
+
+ if (esdhc_hwconfig_enabled == 0)
return 0;
clrsetbits_be32(im-sysconf.sicrl, SICRL_USB_B, SICRL_USB_B_SD);
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: pci: Permit use of reg property for setting device address
Hi Simon,
On Tue, Jan 20, 2015 at 10:31 PM, Simon Glass s...@chromium.org wrote:
+Thierry
Hi Bin,
On 20 January 2015 at 05:59, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Tue, Jan 20, 2015 at 11:19 AM, Simon Glass s...@chromium.org wrote:
In commit a62e84d the old functionality of obtaining a PCI address from the
'reg' property was lost. Add it back, so we can support both a compatible
string list and a 'reg' property.
This patch fixes PCIe ethernet on Tegra boards.
Signed-off-by: Simon Glass s...@chromium.org
---
lib/fdtdec.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 89dac4c..0488607 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -219,8 +219,14 @@ int fdtdec_get_pci_bdf(const void *blob, int node,
/* get vendor id device id from the compatible string */
ret = fdtdec_get_pci_vendev(blob, node, dt_vendor, dt_device);
- if (ret)
- return ret;
+ if (ret) {
+ /* Fall back to using the 'reg' property */
+ ret = fdtdec_get_int(blob, node, reg, -1);
+ if (ret == -1)
+ return -ENOENT;
+ *bdf = ret 0xff;
+ return 0;
+ }
/* extract the bdf from fdt_pci_addr */
*bdf = addr-phys_hi 0x00;
--
How is 'reg' encodeded in Tegra's dts? I feel we should start using
standard bindings instead of custom one.
This is as per the 'Numerical Representation' of the Physical Address
Formats (in pci supplement v2.1). It seems just as valid as the
textual ones.
I still don't get it. The 'Numerical Representation' of the Physical
Address Formats (in pci supplement v2.1) is already supported in
commit a62e84d. That's why I want to see how the Tegra's dts is
written and how commit a62e84d could not handle that case.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] lcd: fix console address is not initialized
This commit 904672e (lcd: refactor lcd console stuff into its
own file), which cause lcd console address is not initialized.
This patch split lcd console address initialize and lcd logo
display into two functions.
Signed-off-by: Bo Shen voice.s...@atmel.com
---
common/lcd.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index cc34b8a..f435e2a 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -82,7 +82,8 @@ DECLARE_GLOBAL_DATA_PTR;
static int lcd_init(void *lcdbase);
-static void *lcd_logo(void);
+static void lcd_logo(void);
+static void *lcd_console_address(void);
static void lcd_setfgcolor(int color);
static void lcd_setbgcolor(int color);
@@ -268,7 +269,8 @@ void lcd_clear(void)
console_rows = panel_info.vl_row / VIDEO_FONT_HEIGHT;
#endif
console_cols = panel_info.vl_col / VIDEO_FONT_WIDTH;
- lcd_init_console(lcd_logo(), console_rows, console_cols);
+ lcd_init_console(lcd_console_address(), console_rows, console_cols);
+ lcd_logo();
lcd_sync();
}
@@ -849,7 +851,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
}
#endif
-static void *lcd_logo(void)
+static void lcd_logo(void)
{
#ifdef CONFIG_SPLASH_SCREEN
char *s;
@@ -879,7 +881,10 @@ static void *lcd_logo(void)
lcd_set_row(LCD_INFO_Y / VIDEO_FONT_HEIGHT);
lcd_show_board_info();
#endif /* CONFIG_LCD_INFO */
+}
+static void *lcd_console_address(void)
+{
#if defined(CONFIG_LCD_LOGO) !defined(CONFIG_LCD_INFO_BELOW_LOGO)
return (void *)((ulong)lcd_base + BMP_LOGO_HEIGHT * lcd_line_length);
#else
--
2.3.0.rc0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] exynos: usb: make dwc3_set_mode to static
The dwc3_set_mode function is used only in
drivers/usb/host/xhci-exynos5.c so make it to static.
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
drivers/usb/host/xhci-exynos5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-exynos5.c b/drivers/usb/host/xhci-exynos5.c
index a77c8bc..3f86fdc 100644
--- a/drivers/usb/host/xhci-exynos5.c
+++ b/drivers/usb/host/xhci-exynos5.c
@@ -182,7 +182,7 @@ static void exynos5_usb3_phy_exit(struct exynos_usb3_phy
*phy)
set_usbdrd_phy_ctrl(POWER_USB_DRD_PHY_CTRL_DISABLE);
}
-void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode)
+static void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode)
{
clrsetbits_le32(dwc3_reg-g_ctl,
DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG),
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] ARM: UniPhier: add static to local functions
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v2:
- Fix umc_init.c too
arch/arm/cpu/armv7/uniphier/ph1-ld4/pll_init.c | 6 +++---
arch/arm/cpu/armv7/uniphier/ph1-ld4/umc_init.c | 4 ++--
arch/arm/cpu/armv7/uniphier/ph1-pro4/pll_init.c | 6 +++---
arch/arm/cpu/armv7/uniphier/ph1-pro4/umc_init.c | 4 ++--
arch/arm/cpu/armv7/uniphier/ph1-sld8/pll_init.c | 6 +++---
arch/arm/cpu/armv7/uniphier/ph1-sld8/umc_init.c | 4 ++--
6 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-ld4/pll_init.c
b/arch/arm/cpu/armv7/uniphier/ph1-ld4/pll_init.c
index 68b9d5f..b83582f 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-ld4/pll_init.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-ld4/pll_init.c
@@ -11,7 +11,7 @@
#undef DPLL_SSC_RATE_1PER
-void dpll_init(void)
+static void dpll_init(void)
{
u32 tmp;
@@ -42,7 +42,7 @@ void dpll_init(void)
writel(tmp, SC_DPLLCTRL2);
}
-void upll_init(void)
+static void upll_init(void)
{
u32 tmp, clk_mode_upll, clk_mode_axosel;
@@ -82,7 +82,7 @@ void upll_init(void)
writel(tmp, SC_UPLLCTRL);
}
-void vpll_init(void)
+static void vpll_init(void)
{
u32 tmp, clk_mode_axosel;
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-ld4/umc_init.c
b/arch/arm/cpu/armv7/uniphier/ph1-ld4/umc_init.c
index 8788916..6387352 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-ld4/umc_init.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-ld4/umc_init.c
@@ -43,8 +43,8 @@ static inline void umc_start_ssif(void __iomem *ssif_base)
writel(0x0001, ssif_base + UMC_DMDRST);
}
-void umc_dramcont_init(void __iomem *dramcont, void __iomem *ca_base,
- int size, int freq)
+static void umc_dramcont_init(void __iomem *dramcont, void __iomem *ca_base,
+ int size, int freq)
{
if (freq == 1333) {
writel(0x45990b11, dramcont + UMC_CMDCTLA);
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-pro4/pll_init.c
b/arch/arm/cpu/armv7/uniphier/ph1-pro4/pll_init.c
index 2dcc089..1db90f8 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-pro4/pll_init.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-pro4/pll_init.c
@@ -11,7 +11,7 @@
#undef DPLL_SSC_RATE_1PER
-void dpll_init(void)
+static void dpll_init(void)
{
u32 tmp;
@@ -46,7 +46,7 @@ void dpll_init(void)
writel(tmp, SC_DPLLCTRL2);
}
-void stop_mpll(void)
+static void stop_mpll(void)
{
u32 tmp;
@@ -62,7 +62,7 @@ void stop_mpll(void)
;
}
-void vpll_init(void)
+static void vpll_init(void)
{
u32 tmp, clk_mode_axosel;
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-pro4/umc_init.c
b/arch/arm/cpu/armv7/uniphier/ph1-pro4/umc_init.c
index 1973ab0..6b9aa74 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-pro4/umc_init.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-pro4/umc_init.c
@@ -52,8 +52,8 @@ static inline void umc_start_ssif(void __iomem *ssif_base)
writel(0x0001, ssif_base + UMC_DMDRST);
}
-void umc_dramcont_init(void __iomem *dramcont, void __iomem *ca_base,
- int size, int freq)
+static void umc_dramcont_init(void __iomem *dramcont, void __iomem *ca_base,
+ int size, int freq)
{
writel(0x66bb0f17, dramcont + UMC_CMDCTLA);
writel(0x18c6aa44, dramcont + UMC_CMDCTLB);
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-sld8/pll_init.c
b/arch/arm/cpu/armv7/uniphier/ph1-sld8/pll_init.c
index 4d87053..4b82700 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-sld8/pll_init.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-sld8/pll_init.c
@@ -9,7 +9,7 @@
#include asm/arch/sc-regs.h
#include asm/arch/sg-regs.h
-void dpll_init(void)
+static void dpll_init(void)
{
u32 tmp;
/*
@@ -54,7 +54,7 @@ void dpll_init(void)
writel(tmp, SC_DPLLCTRL2);
}
-void upll_init(void)
+static void upll_init(void)
{
u32 tmp, clk_mode_upll, clk_mode_axosel;
@@ -94,7 +94,7 @@ void upll_init(void)
writel(tmp, SC_UPLLCTRL);
}
-void vpll_init(void)
+static void vpll_init(void)
{
u32 tmp, clk_mode_axosel;
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-sld8/umc_init.c
b/arch/arm/cpu/armv7/uniphier/ph1-sld8/umc_init.c
index 2e0f9ae..d8285d0 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-sld8/umc_init.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-sld8/umc_init.c
@@ -43,8 +43,8 @@ static inline void umc_start_ssif(void __iomem *ssif_base)
writel(0x0001, ssif_base + UMC_DMDRST);
}
-void umc_dramcont_init(void __iomem *dramcont, void __iomem *ca_base,
- int size, int freq)
+static void umc_dramcont_init(void __iomem *dramcont, void __iomem *ca_base,
+ int size, int freq)
{
#ifdef CONFIG_DDR_STANDARD
writel(0x55990b11, dramcont + UMC_CMDCTLA);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: UniPhier: remove non-sense inline directives
The inlining is done by GCC when needed, there is no need to do it
explicitly. Furthermore, the inline keyword does not force-inline
the code, but is only a hint for the compiler.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/cpu/armv7/uniphier/ph1-ld4/umc_init.c | 4 ++--
arch/arm/cpu/armv7/uniphier/ph1-pro4/umc_init.c | 4 ++--
arch/arm/cpu/armv7/uniphier/ph1-sld8/umc_init.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-ld4/umc_init.c
b/arch/arm/cpu/armv7/uniphier/ph1-ld4/umc_init.c
index 6387352..bbc3dcb 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-ld4/umc_init.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-ld4/umc_init.c
@@ -9,7 +9,7 @@
#include asm/arch/umc-regs.h
#include asm/arch/ddrphy-regs.h
-static inline void umc_start_ssif(void __iomem *ssif_base)
+static void umc_start_ssif(void __iomem *ssif_base)
{
writel(0x, ssif_base + 0xb004);
writel(0x, ssif_base + 0xc004);
@@ -119,7 +119,7 @@ static void umc_dramcont_init(void __iomem *dramcont, void
__iomem *ca_base,
writel(0x0520, dramcont + UMC_DFICUPDCTLA);
}
-static inline int umc_init_sub(int freq, int size_ch0, int size_ch1)
+static int umc_init_sub(int freq, int size_ch0, int size_ch1)
{
void __iomem *ssif_base = (void __iomem *)UMC_SSIF_BASE;
void __iomem *ca_base0 = (void __iomem *)UMC_CA_BASE(0);
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-pro4/umc_init.c
b/arch/arm/cpu/armv7/uniphier/ph1-pro4/umc_init.c
index 6b9aa74..2d1bde6 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-pro4/umc_init.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-pro4/umc_init.c
@@ -9,7 +9,7 @@
#include asm/arch/umc-regs.h
#include asm/arch/ddrphy-regs.h
-static inline void umc_start_ssif(void __iomem *ssif_base)
+static void umc_start_ssif(void __iomem *ssif_base)
{
writel(0x0001, ssif_base + 0xb004);
writel(0x, ssif_base + 0xc004);
@@ -88,7 +88,7 @@ static void umc_dramcont_init(void __iomem *dramcont, void
__iomem *ca_base,
writel(0x8020, dramcont + UMC_DFICUPDCTLA);
}
-static inline int umc_init_sub(int freq, int size_ch0, int size_ch1)
+static int umc_init_sub(int freq, int size_ch0, int size_ch1)
{
void __iomem *ssif_base = (void __iomem *)UMC_SSIF_BASE;
void __iomem *ca_base0 = (void __iomem *)UMC_CA_BASE(0);
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-sld8/umc_init.c
b/arch/arm/cpu/armv7/uniphier/ph1-sld8/umc_init.c
index d8285d0..2fbc73a 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-sld8/umc_init.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-sld8/umc_init.c
@@ -9,7 +9,7 @@
#include asm/arch/umc-regs.h
#include asm/arch/ddrphy-regs.h
-static inline void umc_start_ssif(void __iomem *ssif_base)
+static void umc_start_ssif(void __iomem *ssif_base)
{
writel(0x, ssif_base + 0xb004);
writel(0x, ssif_base + 0xc004);
@@ -99,7 +99,7 @@ static void umc_dramcont_init(void __iomem *dramcont, void
__iomem *ca_base,
writel(0x0520, dramcont + UMC_DFICUPDCTLA);
}
-static inline int umc_init_sub(int freq, int size_ch0, int size_ch1)
+static int umc_init_sub(int freq, int size_ch0, int size_ch1)
{
void __iomem *ssif_base = (void __iomem *)UMC_SSIF_BASE;
void __iomem *ca_base0 = (void __iomem *)UMC_CA_BASE(0);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address
Hello Kevin, On Tue, Jan 20, 2015 at 2:43 PM, Kevin Hilman khil...@kernel.org wrote: Suriyan Ramasami suriya...@gmail.com writes: Hello Kevin, These are the changes that would be necessary in uboot mainline for SPL: arch/arm/cpu/armv7/exynos/Kconfig - select OF_CONTROL + select SUPPORT_SPL + select OF_CONTROL if !SPL_BUILD configs/odroid-xu3_defconfig +CONFIG_SPL=y include/configs/odroid_xu3.h #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x02027000 #undef CONFIG_SEC_FW_SIZE #define CONFIG_SEC_FW_SIZE (15 10) /* 15 KB */ Thanks. With those changes, a build gives me: ./include/common.h:355:73: fatal error: asm/u-boot-sandbox.h: No such file or directory Sorry for the dumb questions, but I'm not very familiar with u-boot. I'm more comofortable in the kernel. The above used to work (a month ago). I shall check with current mainline uboot and report back. FWICT, mainline uboot does not have code to handle secure firmware. For instance when secure firmware is present the address to poke a jump address for the CPU is different (nsram +1c etc). This stems from lowlevel_init.S being moved over to the NS area. This is also missing in uboot mainline or so I think. Hmm, it seems the XU3 has secure firmware so I guess this wont' be useful for me yet? It should be relevant to you, as mainline uboot does not overlay the NS area with a bootstrap code from lowlevel_init.S. At least I have seen mainline linux src code using this address for waking up the CPUs (so does XEN). Curious what platforms you're testing this on? And are any of them using secure firmware? I am currently working only on the XU3 (I thought there was no interest, so I let it slide). I probably should say that the Exynos secure firmware support needs to be tweaked in U-Boot. Maybe other SoCs are supported? I am not sure. Also, I'm still a bit unsure where the switch from secure to NS world happens. Is that in BL1? or somewhere in BL2? If it's in BL2, have you tried switching secure mode off? I know for sure that the signed BL2 does switch from Hyp to NS. This BL2 that I am referring to is HK's nomenclature, which translates to BL1 (SPL) in UBoot lingo. Hence, this adds some confusion in the discussions! The blobs are as follows: (possibly listed in the HK web pages) BL0 (signed encrypted blob from Samsung). This loads HK's signed BL2 (this is U-Boot SPL) This loads U-Boot (U-Boot BL2) and the Trustzone Also, no matter what mode the odroid xu3 is in, the linux kernel from what I can tell depending on the secure-firmware dts entry (which is present) will use the NS + 1c area when powering on the CPU. Hence, its mandatory to have code there. I hope this helps you out. Well, it's certainly a step in the right direction, but not sure yet if I can use it on the odroid-xu3 as I'm still trying to understand the boot sequence. Kevin The ddr init functions seem to be not correct for the 5422 (or so I think). I do not have access to any of the Samsung docs, hence, one solution was to copy over HKs ddr init function, and then the mainline SPL runs. Regards - Suriyan On Tue, Jan 20, 2015 at 1:30 PM, Kevin Hilman khil...@kernel.org wrote: Hello Suriyan, Suriyan Ramasami suriya...@gmail.com writes: Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows: BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625. I'm currently running mainline u-boot, and hoping to test the series that powers down secondary cores on the odroid-xu3. That series applies and builds with mainline u-boot (v2015.01-rc3), but for it to work correctly, IIUC, I'll also need to build an SPL from mainline. Can you share your changes to mainline u-boot that enable the building of SPL? I'd like to try that using your BL2 that will load an unsigned BL2. Thanks, Kevin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/11] Add support for booting multiple cores
Hi Kevin, Akshay Saraswat aksha...@samsung.com writes: This patch series introduces changes for booting secondary CPUs on Exynos5420 and Exynos5800. Thanks for this series. I think this should help get the odroid-xu3 behave better with the mainline linux kernel (assuming I can get it working with mainline u-boot/SPL.) Are you testing this on mainline u-boot? Yes, this series is based on mainline u-boot-samsung git. Can you describe what platforms you've tested this on and whether or not those platforms are using secure firmware? I have tested these patches on Chromebook-2 11 and 13 inch having Exynos 5420 and Exynos 5800 respectively. Not sure of how Odroid-xu3 will behave with this set because I don't have that platform and never tested it. Kevin Regards, Akshay Saraswat ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board_f: save malloc_base from zeroing in case of CONFIG_SYS_MALLOC_F_LEN
Hello Alexey, On Tue, 20 Jan 2015 13:06:57 +, Alexey Brodkin alexey.brod...@synopsys.com wrote: Hi Albert, On Tue, 2015-01-20 at 08:07 +0100, Albert ARIBAUD wrote: Hello Alexey, On Mon, 19 Jan 2015 20:55:03 +0300, Alexey Brodkin alexey.brod...@synopsys.com wrote: In case of CONFIG_SYS_MALLOC_F_LEN malloc_base is used for early start-up code and is set very early, typically in start.S or crt1.S. There is no crt1.S in U-Boot. Did you mean crt0.S? Indeed I meant crt0.S In current implementation in case of CONFIG_SYS_GENERIC_GLOBAL_DATA all global data gets zeroed on board_init_f entry. But by that time malloc_base could have been set already, which means it will be zeroed and subsequent C-code will be executed improperly (if executed at all - if there's no memory mapped to 0 or it is read-only then on some arches there will be an exception and others will quetly die). To work-around described situation we just need to make sure malloc_base is saved prior zeroing global data and recovered afterwards. Keeping data from being zeroed etc is usually done through GD. Could malloc_base be placed there instead of creating a specific exemption for it? Unfortunately I didn't understand your suggestion here. malloc_base is already in global data structure. My bad; as you had not mentioned GD (or I'd missed it), I thought you were referring to a standalone variable. I should have grepped, which I have done now. But the point is global data structure also requires zeroing sometime on early start-up. This is required to make sure we don't have any garbage in GD (for example left-overs from lower-level bootloader or previously executed kernel etc). So other option is to zero GD earlier in start-up code. This is essentially doable but it will be done on per-architecture or even per-CPU basis in their start.S - which means we'll have duplication of the same functionality and maintenance will be difficult then. Right now, yes, we'd have to duplicate this a bit, but we can minimize that by doing the GD init in a single routine called from each start.S; this would only add one bl line per start.S (and hopefully, it can be added the same way in each start.S and we can still eventually merge these start.S files together). Probably I just didn't get you point so then could you please clarify what did you mean. No, I just hadn't completely done my homework. -Alexey Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/4] arm, at91, wdt: do not disable WDT in SPL
if CONFIG_AT91SAM9_WATCHDOG is set, do not disable WDT in
SPL
Signed-off-by: Heiko Schocher h...@denx.de
---
arch/arm/cpu/at91-common/spl.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/cpu/at91-common/spl.c b/arch/arm/cpu/at91-common/spl.c
index 6473320..aaa5eec 100644
--- a/arch/arm/cpu/at91-common/spl.c
+++ b/arch/arm/cpu/at91-common/spl.c
@@ -12,12 +12,16 @@
#include asm/arch/clk.h
#include spl.h
+#if defined(CONFIG_AT91SAM9_WATCHDOG)
+void at91_disable_wdt(void) { }
+#else
void at91_disable_wdt(void)
{
struct at91_wdt *wdt = (struct at91_wdt *)ATMEL_BASE_WDT;
writel(AT91_WDT_MR_WDDIS, wdt-mr);
}
+#endif
u32 spl_boot_device(void)
{
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 2/4] common/board_f: add at91 wdt
call hw_watchdog_init() also if CONFIG_AT91SAM9_WATCHDOG
is used.
Signed-off-by: Heiko Schocher h...@denx.de
---
common/board_f.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index 3a4b32c..693a75c 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -111,7 +111,7 @@ static int init_func_watchdog_init(void)
{
# if defined(CONFIG_HW_WATCHDOG) (defined(CONFIG_BLACKFIN) || \
defined(CONFIG_M68K) || defined(CONFIG_MICROBLAZE) || \
- defined(CONFIG_SH))
+ defined(CONFIG_SH) || defined(CONFIG_AT91SAM9_WATCHDOG))
hw_watchdog_init();
# endif
puts( Watchdog enabled\n);
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 4/4] arm, at91, taurus: enable WDT
enable WDT for the taurus board. Signed-off-by: Heiko Schocher h...@denx.de --- include/configs/taurus.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/taurus.h b/include/configs/taurus.h index 65468ad..b61dc2d 100644 --- a/include/configs/taurus.h +++ b/include/configs/taurus.h @@ -121,6 +121,12 @@ #define CONFIG_RMII #define CONFIG_AT91_WANTS_COMMON_PHY +#define CONFIG_AT91SAM9_WATCHDOG +#if !defined(CONFIG_SPL_BUILD) +/* Enable the watchdog */ +#define CONFIG_HW_WATCHDOG +#endif + /* USB */ #if defined(CONFIG_BOARD_TAURUS) #define CONFIG_USB_ATMEL -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 3/4] arm, at91, wdt: make timeout configurable
make the HW WDT timeout configurable through the define CONFIG_AT91_HW_WDT_TIMEOUT. Signed-off-by: Heiko Schocher h...@denx.de --- README | 3 +++ drivers/watchdog/at91sam9_wdt.c | 4 2 files changed, 7 insertions(+) diff --git a/README b/README index fefa71c..5cce4c2 100644 --- a/README +++ b/README @@ -1257,6 +1257,9 @@ The following options need to be configured: SoC, then define this variable and provide board specific code for the hw_watchdog_reset function. + CONFIG_AT91_HW_WDT_TIMEOUT + specify the timeout in seconds. default 2 seconds. + - U-Boot Version: CONFIG_VERSION_VARIABLE If this variable is defined, an environment variable diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c index ffd49a2..03c786c 100644 --- a/drivers/watchdog/at91sam9_wdt.c +++ b/drivers/watchdog/at91sam9_wdt.c @@ -30,7 +30,11 @@ #define ticks_to_ms(t) (((t + 1) * 1000) 8) /* Hardware timeout in seconds */ +#if !defined(CONFIG_AT91_HW_WDT_TIMEOUT) #define WDT_HW_TIMEOUT 2 +#else +#define WDT_HW_TIMEOUT CONFIG_AT91_HW_WDT_TIMEOUT +#endif /* * Set the watchdog time interval in 1/256Hz (write-once) -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] ARM: UniPhier: fix SocGlue header
Masahiro Yamada (3): ARM: UniPhier: use linux/sizes.h for readability ARM: UniPhier: rename SG_MEMCONF_* macros for readability ARM: UniPhier: add SG_MEMCONF macros for DDR channel 2 arch/arm/include/asm/arch-uniphier/sg-regs.h | 109 +++ 1 file changed, 77 insertions(+), 32 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] ARM: UniPhier: add SG_MEMCONF macros for DDR channel 2
PH1-sLD3, PH1-LD6b have DDR channel 2.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v2: None
arch/arm/include/asm/arch-uniphier/sg-regs.h | 44
1 file changed, 44 insertions(+)
diff --git a/arch/arm/include/asm/arch-uniphier/sg-regs.h
b/arch/arm/include/asm/arch-uniphier/sg-regs.h
index 9b468d4..4ae67c8 100644
--- a/arch/arm/include/asm/arch-uniphier/sg-regs.h
+++ b/arch/arm/include/asm/arch-uniphier/sg-regs.h
@@ -41,6 +41,13 @@
#define SG_MEMCONF_CH1_NUM_1 (0x1 9)
#define SG_MEMCONF_CH1_NUM_2 (0x0 9)
+#define SG_MEMCONF_CH2_SZ_64M ((0x0 26) | (0x01 16))
+#define SG_MEMCONF_CH2_SZ_128M ((0x0 26) | (0x02 16))
+#define SG_MEMCONF_CH2_SZ_256M ((0x0 26) | (0x03 16))
+#define SG_MEMCONF_CH2_SZ_512M ((0x1 26) | (0x00 16))
+#define SG_MEMCONF_CH2_NUM_1 (0x1 24)
+#define SG_MEMCONF_CH2_NUM_2 (0x0 24)
+
#define SG_MEMCONF_SPARSEMEM (0x1 4)
/* Pin Control */
@@ -189,6 +196,43 @@ static inline u32 sg_memconf_val_ch1(unsigned long size,
int num)
}
return ret;
}
+
+static inline u32 sg_memconf_val_ch2(unsigned long size, int num)
+{
+ int size_mb = size / num;
+ u32 ret;
+
+ switch (size_mb) {
+ case SZ_64M:
+ ret = SG_MEMCONF_CH2_SZ_64M;
+ break;
+ case SZ_128M:
+ ret = SG_MEMCONF_CH2_SZ_128M;
+ break;
+ case SZ_256M:
+ ret = SG_MEMCONF_CH2_SZ_256M;
+ break;
+ case SZ_512M:
+ ret = SG_MEMCONF_CH2_SZ_512M;
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ switch (num) {
+ case 1:
+ ret |= SG_MEMCONF_CH2_NUM_1;
+ break;
+ case 2:
+ ret |= SG_MEMCONF_CH2_NUM_2;
+ break;
+ default:
+ BUG();
+ break;
+ }
+ return ret;
+}
#endif /* __ASSEMBLY__ */
#endif /* ARCH_SG_REGS_H */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm, at91: add reset controller status register
add reset controller status register Signed-off-by: Heiko Schocher h...@denx.de --- arch/arm/include/asm/arch-at91/at91_rstc.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-at91/at91_rstc.h b/arch/arm/include/asm/arch-at91/at91_rstc.h index a942342..e4eb3da 100644 --- a/arch/arm/include/asm/arch-at91/at91_rstc.h +++ b/arch/arm/include/asm/arch-at91/at91_rstc.h @@ -13,6 +13,8 @@ #ifndef AT91_RSTC_H #define AT91_RSTC_H +/* Reset Controller Status Register */ +#define AT91_ASM_RSTC_SR (ATMEL_BASE_RSTC + 0x04) #define AT91_ASM_RSTC_MR (ATMEL_BASE_RSTC + 0x08) #ifndef __ASSEMBLY__ -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12] sunxi: Move setting of CPU system control register SMP bit to save_boot_params
Hello Hans,
On Tue, 20 Jan 2015 15:32:34 +0100, Hans de Goede hdego...@redhat.com
wrote:
Hi,
On 20-01-15 11:22, Albert ARIBAUD wrote:
Hello Hans,
I'm leaning toward grouping all CP15 inits (including cache(s)
and TLB disabling and maybe VBAR setting) in a single CP15 call to
a single soc_init_cp15 function.
Now, SoCs with the same CPU will have a common CP15 init part, and
that part could go into a cpu_init_cp15 function which soc_init_cp15
would call. Of course, since we're doing this way before we have any
stack, we will have to handle nested calls by saving and restoring LR
in intermediate function contexts.
Note that solving this still leaves the A80 magic sram controller poke
which
also needs to happen really really early or otherwise the entire SoC just
resets as if the watchdog has triggered, I'm fine with using
save_boot_params
for that, it is not its intended purpose, but it works fine for it, so
I see no reason to complicate things with yet another callback.
Maybe we could turn soc_init_cp15 into a more general soc_init function
which would do whatever is needed, on cp15 or otherwise.
(I see there is one soc_init defined, for spear600, but it is actually
empty and could/should be removed. Patch anyone?)
Hmm, so if I'm reading the above correctly, then I think you want to do
the following:
1) Rename cpu_init_cp15 to cpu_init_cp15_common
2) Add a new soc_init function, with a weak default which just calls
cpu_init_cp15_common
3) Add a a7_init_cp15 which sets the smp bit
4) Have Cortex A7 SoCs override soc_init with one which first calls
a7_init_cp15 and then calls cpu_init_cp15_common
5) And on SoC's which need to do something special before or after
cp15 init, they can do so by overriding soc_init and do what
ever they need to do there before *or* after calling
cpu_init_cp15_common
Have I got that right ?
Almost entirely. My only comments are on 1) :
- cpu_init_cp15_common does not need the common suffix IMO; actually,
it might be more general than just touching cp15, so we could just
call it cpu_init (1).
- if two CPUs need different versions, then we will want to make
cpu_init a weak function, with a default based on the 'common
denominator'.
(1) Note that there is already a cpu_init() function in U-Boot, used by
SH and AVR32; if we want 'cpu_init' to be consistent across architectures,
we might have to change {soc,cpu}_init to somehting else (for instance
{soc,cpu}_setup or {soc,cpu}_boot_init) but I don't like that much, or
investigate what the existing cpu_init() does and see if /that/ could be
renamed or merged into a common mechanism (I doubt that the second is
practically feasible).
If so I can try to write a patch-set for this, my arm asm is a bit
weak, but I should be able to cobble this together using existing code
as an example.
Thanks!
Regards,
Hans
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Disable tftp and access
Hello Jakub, On Tue, 20 Jan 2015 20:09:21 +0100, Jakub Jančo kub...@gmail.com wrote: Hello, I want to disable uboot tftp on my device and if uboot allow some login/access(eg. by console) then disable it too. My aim is to lock uboot except booting image(OS), I want manage it only from OS(changing env variables only from OS) I want to ask what env variables I should change to disable tftp functions and access? Basically, you should look into the bootdelay and stdin variables. Thanks, Kubco Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem Mounting/Unmounting several UBI volumes in u-boot.
Hello Konstantyn,
Am 20.01.2015 17:09, schrieb Konstantyn Prokopenko:
Hello,
I'm using the latest u-boot on our custom board. The u-boot is located on the
NAND flash in the first 4MB partition. I break 256MB NAND into 4 MTD
partitions: u-boot(4MB), kernel(4MB), rootfs(100MB), safefs(40MB), varfs(108MB).
We are using Freescale iMX6 processor (nitrogen6x BSP in u-boot). I've modified
board support code to include our pad configurations and additional hardware.
Also I added misc driver for our system initialization. The driver would mount
rootfs UBI fs on rootfs MTD partition and validate system. If failed, it would
unmounts it and mount UBI fs on safefs MTD partition and load it.
The problem was with unmounting rootfs and initializing safefs partition. Here
is the relevant portion of my initialization script:
echo Loading just in case, default kernel from installation
partition...; \
nand read 1080 40 40; \
echo Configuring NAND flash for MTD...; \
mtdparts default; mtdparts; \
echo Mounting Root filesystem; \
ubi part rootfs; \
ubifsmount ubi0:rootfs; \
echo Verifying if filesystem and kernel is OK...; \
parallax validate 1 kernel; \
if test ${parallax_result} = 0; then \
echo Reading kernel file from rootfs; \
else \
echo ROOTFS or Rootfs Kernel appears to be BAD. Trying
SAFEFS...; \
ubifsumount; \
ubi part safefs; \
ubifsmount ubi0:safefs; \
parallax validate 2 kernel; \
if test ${parallax_result} = 0; then \
echo Reading kernel file from safefs; \
else \
echo All FILESYSTEMS are bad, booting from MTD1 kernel
partition; \
nand read 1080 40 40; bootm 1080; \
fi; \
fi; \
ubifsload 1080 kernel; \
ubifsumount; \
bootm 1080;\0 \
The parallax module is our own driver which is relevant to our system
operations. It tests for validity currently mounted partition. Nothing fancy,
just a bunch of MD5 checks.
OK, I've digged into the MTD/UBI code and found the problem. When mounting the
first partition, no matter which one, the mtd_dev_param[] array is populated
with the MTD device parameters entry (the first mounted partition). The
ubi_init() finds it first and successfully attaches it.
When unmounting this partition, the mtd_dev_param[] array still includes the
same entry and when attempting to mount the second partition, the array
includes two mtd_dev_param enties: The first one for already unmounted MTD
partition and the second for the next candidate.
The ubi_init start accessing this array from ID0 and after trying to attach
entry 0 errors out ignoring the second entry.
I've added a temporary hack to avoid this problem. Because UBIFS can mount only
a signgle partition at a time, I've introduced a global parameter:
Char *device_to_attach[] which is populated when ubi_mtd_param_parse() is
called.
Now, in ubi_init() I check if the current entry to the mtd_dev_array matches
the device to attach. Also I added check for NULL if we are out of devices.
...
/* Attach MTD devices */
for (i = 0; i mtd_devs; i++) {
struct mtd_dev_param *p = mtd_dev_param[i];
struct mtd_info *mtd;
if(p == NULL) {
printk(KERN_INFO UBI_INIT: Could not find device: %s\n,
device_to_attach);
err = -ENODEV;
goto out_slab;
}
if(strcmp(p-name, device_to_attach) != 0)
continue;
This is a temp hack, just to make it work for our needs. Please advice if there
are better ways or maybe we can just clean the mtd_dev_param array after
unmounts being called.
Can you try this patch?
http://patchwork.ozlabs.org/patch/430909/
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] ARM: UniPhier: use linux/sizes.h for readability
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v2:
- Split into two patches
arch/arm/include/asm/arch-uniphier/sg-regs.h | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/arch-uniphier/sg-regs.h
b/arch/arm/include/asm/arch-uniphier/sg-regs.h
index fa5e6ae..7bf45c5 100644
--- a/arch/arm/include/asm/arch-uniphier/sg-regs.h
+++ b/arch/arm/include/asm/arch-uniphier/sg-regs.h
@@ -101,6 +101,7 @@
#else
#include linux/types.h
+#include linux/sizes.h
#include asm/io.h
static inline void sg_set_pinsel(int n, int value)
@@ -111,23 +112,23 @@ static inline void sg_set_pinsel(int n, int value)
static inline u32 sg_memconf_val_ch0(unsigned long size, int num)
{
- int size_mb = (size 20) / num;
+ int size_mb = size / num;
u32 ret;
switch (size_mb) {
- case 64:
+ case SZ_64M:
ret = SG_MEMCONF_CH0_SIZE_64MB;
break;
- case 128:
+ case SZ_128M:
ret = SG_MEMCONF_CH0_SIZE_128MB;
break;
- case 256:
+ case SZ_256M:
ret = SG_MEMCONF_CH0_SIZE_256MB;
break;
- case 512:
+ case SZ_512M:
ret = SG_MEMCONF_CH0_SIZE_512MB;
break;
- case 1024:
+ case SZ_1G:
ret = SG_MEMCONF_CH0_SIZE_1024MB;
break;
default:
@@ -151,23 +152,23 @@ static inline u32 sg_memconf_val_ch0(unsigned long size,
int num)
static inline u32 sg_memconf_val_ch1(unsigned long size, int num)
{
- int size_mb = (size 20) / num;
+ int size_mb = size / num;
u32 ret;
switch (size_mb) {
- case 64:
+ case SZ_64M:
ret = SG_MEMCONF_CH1_SIZE_64MB;
break;
- case 128:
+ case SZ_128M:
ret = SG_MEMCONF_CH1_SIZE_128MB;
break;
- case 256:
+ case SZ_256M:
ret = SG_MEMCONF_CH1_SIZE_256MB;
break;
- case 512:
+ case SZ_512M:
ret = SG_MEMCONF_CH1_SIZE_512MB;
break;
- case 1024:
+ case SZ_1G:
ret = SG_MEMCONF_CH1_SIZE_1024MB;
break;
default:
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] ARM: UniPhier: rename SG_MEMCONF_* macros for readability
Match the suffixes of SG_MEMCONF_* macros with SZ_* macros defined
by linux/sizes.h for readability.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v2:
- Split into two patches
arch/arm/include/asm/arch-uniphier/sg-regs.h | 40 ++--
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/include/asm/arch-uniphier/sg-regs.h
b/arch/arm/include/asm/arch-uniphier/sg-regs.h
index 7bf45c5..9b468d4 100644
--- a/arch/arm/include/asm/arch-uniphier/sg-regs.h
+++ b/arch/arm/include/asm/arch-uniphier/sg-regs.h
@@ -25,19 +25,19 @@
/* Memory Configuration */
#define SG_MEMCONF (SG_CTRL_BASE | 0x0400)
-#define SG_MEMCONF_CH0_SIZE_64MB ((0x0 10) | (0x01 0))
-#define SG_MEMCONF_CH0_SIZE_128MB ((0x0 10) | (0x02 0))
-#define SG_MEMCONF_CH0_SIZE_256MB ((0x0 10) | (0x03 0))
-#define SG_MEMCONF_CH0_SIZE_512MB ((0x1 10) | (0x00 0))
-#define SG_MEMCONF_CH0_SIZE_1024MB ((0x1 10) | (0x01 0))
+#define SG_MEMCONF_CH0_SZ_64M ((0x0 10) | (0x01 0))
+#define SG_MEMCONF_CH0_SZ_128M ((0x0 10) | (0x02 0))
+#define SG_MEMCONF_CH0_SZ_256M ((0x0 10) | (0x03 0))
+#define SG_MEMCONF_CH0_SZ_512M ((0x1 10) | (0x00 0))
+#define SG_MEMCONF_CH0_SZ_1G ((0x1 10) | (0x01 0))
#define SG_MEMCONF_CH0_NUM_1 (0x1 8)
#define SG_MEMCONF_CH0_NUM_2 (0x0 8)
-#define SG_MEMCONF_CH1_SIZE_64MB ((0x0 11) | (0x01 2))
-#define SG_MEMCONF_CH1_SIZE_128MB ((0x0 11) | (0x02 2))
-#define SG_MEMCONF_CH1_SIZE_256MB ((0x0 11) | (0x03 2))
-#define SG_MEMCONF_CH1_SIZE_512MB ((0x1 11) | (0x00 2))
-#define SG_MEMCONF_CH1_SIZE_1024MB ((0x1 11) | (0x01 2))
+#define SG_MEMCONF_CH1_SZ_64M ((0x0 11) | (0x01 2))
+#define SG_MEMCONF_CH1_SZ_128M ((0x0 11) | (0x02 2))
+#define SG_MEMCONF_CH1_SZ_256M ((0x0 11) | (0x03 2))
+#define SG_MEMCONF_CH1_SZ_512M ((0x1 11) | (0x00 2))
+#define SG_MEMCONF_CH1_SZ_1G ((0x1 11) | (0x01 2))
#define SG_MEMCONF_CH1_NUM_1 (0x1 9)
#define SG_MEMCONF_CH1_NUM_2 (0x0 9)
@@ -117,19 +117,19 @@ static inline u32 sg_memconf_val_ch0(unsigned long size,
int num)
switch (size_mb) {
case SZ_64M:
- ret = SG_MEMCONF_CH0_SIZE_64MB;
+ ret = SG_MEMCONF_CH0_SZ_64M;
break;
case SZ_128M:
- ret = SG_MEMCONF_CH0_SIZE_128MB;
+ ret = SG_MEMCONF_CH0_SZ_128M;
break;
case SZ_256M:
- ret = SG_MEMCONF_CH0_SIZE_256MB;
+ ret = SG_MEMCONF_CH0_SZ_256M;
break;
case SZ_512M:
- ret = SG_MEMCONF_CH0_SIZE_512MB;
+ ret = SG_MEMCONF_CH0_SZ_512M;
break;
case SZ_1G:
- ret = SG_MEMCONF_CH0_SIZE_1024MB;
+ ret = SG_MEMCONF_CH0_SZ_1G;
break;
default:
BUG();
@@ -157,19 +157,19 @@ static inline u32 sg_memconf_val_ch1(unsigned long size,
int num)
switch (size_mb) {
case SZ_64M:
- ret = SG_MEMCONF_CH1_SIZE_64MB;
+ ret = SG_MEMCONF_CH1_SZ_64M;
break;
case SZ_128M:
- ret = SG_MEMCONF_CH1_SIZE_128MB;
+ ret = SG_MEMCONF_CH1_SZ_128M;
break;
case SZ_256M:
- ret = SG_MEMCONF_CH1_SIZE_256MB;
+ ret = SG_MEMCONF_CH1_SZ_256M;
break;
case SZ_512M:
- ret = SG_MEMCONF_CH1_SIZE_512MB;
+ ret = SG_MEMCONF_CH1_SZ_512M;
break;
case SZ_1G:
- ret = SG_MEMCONF_CH1_SIZE_1024MB;
+ ret = SG_MEMCONF_CH1_SZ_1G;
break;
default:
BUG();
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Enable journal replay for UBIFS
Hello Anton, Am 20.01.2015 15:22, schrieb Anton Habegger: Hello Heiko Thank you fro the review. I added atomic_long_read in ubifs.h as for other atomic operations. Hmm.. I see, there are other missing atomic defines for UBI also ... Ok, I tend to accept your patch, but the correct way would be to import include/asm-generic/atomic-long.h from linux and drop this definitions in ubifs.h ... Could you prepare such a second patch? I hope (but I can't garantee) by this time the mail is well formed. If not please tell me again. It looks good now! During mount_ubifs the ubifs_replay_journal was disabled. This patch enables it again and fix some unrecoverable UBIFS volumes. nitpick ... Sorry, this is not a valid commit message ... please look at http://www.denx.de/wiki/view/U-Boot/Patches how to write a commit message. Please add comments to your patch under a --- line, and provide a patch history ... add also a hint from which linux version you picked up the new file fs/ubifs/gc.c Current version of the other MTD/UBI/UBIFS files is 1860e379875df: Linux 3.15 Could you use this as base for your patch? Thanks! Signed-off-by: Anton Habegger anton.habeg...@delta-es.com --- fs/ubifs/Makefile | 2 +- fs/ubifs/gc.c | 987 ++ fs/ubifs/replay.c | 4 - fs/ubifs/super.c | 8 +- fs/ubifs/tnc.c| 2 - fs/ubifs/ubifs.h | 1 + 6 files changed, 990 insertions(+), 14 deletions(-) create mode 100644 fs/ubifs/gc.c Compiling current mainline with your patch drops the follwoing warning: CC fs/ubifs/tnc.o fs/ubifs/tnc.c: In function 'ubifs_tnc_close': fs/ubifs/tnc.c:2861:8: warning: variable 'n' set but not used [-Wunused-but-set-variable] Could you please fix this too? Thanks! Beside of this nitpicks, your patch looks good. bye, Heiko diff --git a/fs/ubifs/Makefile b/fs/ubifs/Makefile index 8c8c6ac..5efb349 100644 --- a/fs/ubifs/Makefile +++ b/fs/ubifs/Makefile @@ -12,4 +12,4 @@ obj-y := ubifs.o io.o super.o sb.o master.o lpt.o obj-y += lpt_commit.o scan.o lprops.o obj-y += tnc.o tnc_misc.o debug.o crc16.o budget.o -obj-y += log.o orphan.o recovery.o replay.o +obj-y += log.o orphan.o recovery.o replay.o gc.o diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c new file mode 100644 index 000..159ee67 --- /dev/null +++ b/fs/ubifs/gc.c @@ -0,0 +1,987 @@ +/* + * This file is part of UBIFS. + * + * Copyright (C) 2006-2008 Nokia Corporation. + * + * 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. + * + * 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., 51 + * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * + * Authors: Adrian Hunter + * Artem Bityutskiy (Битюцкий Артём) + */ + +/* + * This file implements garbage collection. The procedure for garbage collection + * is different depending on whether a LEB as an index LEB (contains index + * nodes) or not. For non-index LEBs, garbage collection finds a LEB which + * contains a lot of dirty space (obsolete nodes), and copies the non-obsolete + * nodes to the journal, at which point the garbage-collected LEB is free to be + * reused. For index LEBs, garbage collection marks the non-obsolete index nodes + * dirty in the TNC, and after the next commit, the garbage-collected LEB is + * to be reused. Garbage collection will cause the number of dirty index nodes + * to grow, however sufficient space is reserved for the index to ensure the + * commit will never run out of space. + * + * Notes about dead watermark. At current UBIFS implementation we assume that + * LEBs which have less than @c-dead_wm bytes of free + dirty space are full + * and not worth garbage-collecting. The dead watermark is one min. I/O unit + * size, or min. UBIFS node size, depending on what is greater. Indeed, UBIFS + * Garbage Collector has to synchronize the GC head's write buffer before + * returning, so this is about wasting one min. I/O unit. However, UBIFS GC can + * actually reclaim even very small pieces of dirty space by garbage collecting + * enough dirty LEBs, but we do not bother doing this at this implementation. + * + * Notes about dark watermark. The results of GC work depends on how big are + * the UBIFS nodes GC deals with. Large nodes make GC waste more space. Indeed, + * if GC move data from LEB A to LEB B and nodes in LEB A are large, GC would + * have to waste large pieces of free space at the end of LEB B, because nodes + * from LEB A would not fit. And the worst situation is when all
