Re: [U-Boot] [PATCH v3 1/5] arm bootm: Allow to pass board specified atags
On Sunday 14 October 2012 02:18:02 Marek Vasut wrote: > Dear Pali Rohár, > > > On Sunday 14 October 2012 01:43:25 Marek Vasut wrote: > > > Dear Pali Rohár, > > > > > > ... missing commit message ... > > > > Is not subject enought? > > Sorry, but no. > Commit message: With this patch is possible to pass board specified atags. Board can implement function setup_board_tags which could append or change atags before booting kernel. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Add power bus message definitions in twl4030.h
Dear Pali Rohár, > On Sunday 14 October 2012 02:16:10 Marek Vasut wrote: > > Dear Pali Rohár, > > > > > On Sunday 14 October 2012 01:46:30 you wrote: > > > > Dear Pali Rohár, > > > > > > > > > * Code copied from linux kernel 3.0.0 from file > > > > > include/linux/i2c/twl.h > > > > > > > > Missing commit ... see > > > > http://www.denx.de/wiki/U-Boot/Patches#Attributing_Code_Cop > > > > yrig hts_Sign > > > > > > "... provide terse but precise information which exact > > > version or even commit ID was used ..." > > > > > > I copied code from 3.0.0 tarball, so I do not know commit ID. > > > But 3.0.0 is exact version. > > > > Look here: > > > > http://git.kernel.org/?p=linux/kernel/git/marex/linux-2.6.git;a > > =summary > > Ok, last commit before 3.0.0 release was > 6523b148b44be38d89c2ee9865d34da30d9f5f1c Please put it into the commit message. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/5] arm bootm: Do not append zero ATAG_MEM
Dear Pali Rohár,
> On Sunday 14 October 2012 02:27:05 Marek Vasut wrote:
> > Dear Pali Rohár,
> >
> > > On Sunday 14 October 2012 02:17:01 Marek Vasut wrote:
> > > > Dear Pali Rohár,
> > > >
> > > > > On Sunday 14 October 2012 01:45:06 Marek Vasut wrote:
> > > > > > > for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> > > > > > >
> > > > > > > + if (bd->bi_dram[i].size == 0)
> > > > > > > + continue;
> > > > > >
> > > > > > This doesn't look right at all, your board is
> > > > > > misconfigured
> > > > > > if
> > > > > > bd->bi_dram[i] == 0. Did you misconfigure
> > > > > > CONFIG_NR_DRAM_BANKS
> > > > > > ?
> > > > >
> > > > > On some N900 devices there are two banks and on some only
> > > > > one. If there is only one it has size 256 MB and if there
> > > > > are two both has 128 MB. CONFIG_NR_DRAM_BANKS must be
> > > > > specified at compile time, but for N900 I need runtime
> > > > > detection.
> > > >
> > > > How can that be? Are these two banks contiguous?
> > >
> > > Yes.
> >
> > And how does the memory map differ in case of device with one
> > 256MB block then ?
>
> Memory map is same, from 0x8000 to 0x9000.
>
> For two bank devices uboot reports:
> size=0800 start=8000
> size=0800 start=8800
>
> And for one:
> size=1000 start=8000
> size= start=9000
Tom, can this not be handled as a single area? How does the omap memory layout
look?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Add power bus message definitions in twl4030.h
On Sunday 14 October 2012 02:16:10 Marek Vasut wrote: > Dear Pali Rohár, > > > On Sunday 14 October 2012 01:46:30 you wrote: > > > Dear Pali Rohár, > > > > > > > * Code copied from linux kernel 3.0.0 from file > > > > include/linux/i2c/twl.h > > > > > > Missing commit ... see > > > http://www.denx.de/wiki/U-Boot/Patches#Attributing_Code_Cop > > > yrig hts_Sign > > > > "... provide terse but precise information which exact > > version or even commit ID was used ..." > > > > I copied code from 3.0.0 tarball, so I do not know commit ID. > > But 3.0.0 is exact version. > > Look here: > > http://git.kernel.org/?p=linux/kernel/git/marex/linux-2.6.git;a > =summary Ok, last commit before 3.0.0 release was 6523b148b44be38d89c2ee9865d34da30d9f5f1c -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/5] arm bootm: Do not append zero ATAG_MEM
On Sunday 14 October 2012 02:27:05 Marek Vasut wrote:
> Dear Pali Rohár,
>
> > On Sunday 14 October 2012 02:17:01 Marek Vasut wrote:
> > > Dear Pali Rohár,
> > >
> > > > On Sunday 14 October 2012 01:45:06 Marek Vasut wrote:
> > > > > > for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> > > > > >
> > > > > > + if (bd->bi_dram[i].size == 0)
> > > > > > + continue;
> > > > >
> > > > > This doesn't look right at all, your board is
> > > > > misconfigured
> > > > > if
> > > > > bd->bi_dram[i] == 0. Did you misconfigure
> > > > > CONFIG_NR_DRAM_BANKS
> > > > > ?
> > > >
> > > > On some N900 devices there are two banks and on some only
> > > > one. If there is only one it has size 256 MB and if there
> > > > are two both has 128 MB. CONFIG_NR_DRAM_BANKS must be
> > > > specified at compile time, but for N900 I need runtime
> > > > detection.
> > >
> > > How can that be? Are these two banks contiguous?
> >
> > Yes.
>
> And how does the memory map differ in case of device with one
> 256MB block then ?
>
Memory map is same, from 0x8000 to 0x9000.
For two bank devices uboot reports:
size00 start�00
size00 start�00
And for one:
size00 start�00
size 00 start�00
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/5] cfb_console: Add support for some ANSI terminal escape codes
Dear Pali Rohár, > On Sunday 14 October 2012 01:48:20 Marek Vasut wrote: > > Dear Pali Rohár, > > > > > * This patch add support for move cursor, reverse colors and > > > clear console> > > > > > >via ANSI espace codes in cfb_console driver > > > > > > * ANSI escape codes can be enabled/disabled via > > > CONFIG_CFB_CONSOLE_ANSI> > > > > > > Signed-off-by: Pali Rohár > > > --- > > > > Missing v3? > > In "Changes since v2" I wrote what was changed in open interval > between v2 and v3. So it is not missing :-) Please stop inventing new ways of writing changelog and obey: http://www.denx.de/wiki/U-Boot/Patches > > > Changes since v2: > > >- Fixed multiline comments > > > > > > Changes since v1: > > >- Added support ANSI code show/hide cursor > > >- Added info to README > > > > [...] > > > > I'll leave the rest of the patch up to Anatolij, he's The > > Expert. > > > > Best regards, > > Marek Vasut Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/5] arm bootm: Do not append zero ATAG_MEM
Dear Pali Rohár,
> On Sunday 14 October 2012 02:17:01 Marek Vasut wrote:
> > Dear Pali Rohár,
> >
> > > On Sunday 14 October 2012 01:45:06 Marek Vasut wrote:
> > > > > for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> > > > >
> > > > > + if (bd->bi_dram[i].size == 0)
> > > > > + continue;
> > > >
> > > > This doesn't look right at all, your board is misconfigured
> > > > if
> > > > bd->bi_dram[i] == 0. Did you misconfigure
> > > > CONFIG_NR_DRAM_BANKS
> > > > ?
> > >
> > > On some N900 devices there are two banks and on some only
> > > one. If there is only one it has size 256 MB and if there
> > > are two both has 128 MB. CONFIG_NR_DRAM_BANKS must be
> > > specified at compile time, but for N900 I need runtime
> > > detection.
> >
> > How can that be? Are these two banks contiguous?
>
> Yes.
And how does the memory map differ in case of device with one 256MB block then ?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/5] arm bootm: Do not append zero ATAG_MEM
On Sunday 14 October 2012 02:17:01 Marek Vasut wrote:
> Dear Pali Rohár,
>
> > On Sunday 14 October 2012 01:45:06 Marek Vasut wrote:
> > > > for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> > > >
> > > > + if (bd->bi_dram[i].size == 0)
> > > > + continue;
> > >
> > > This doesn't look right at all, your board is misconfigured
> > > if
> > > bd->bi_dram[i] == 0. Did you misconfigure
> > > CONFIG_NR_DRAM_BANKS
> > > ?
> >
> > On some N900 devices there are two banks and on some only
> > one. If there is only one it has size 256 MB and if there
> > are two both has 128 MB. CONFIG_NR_DRAM_BANKS must be
> > specified at compile time, but for N900 I need runtime
> > detection.
>
> How can that be? Are these two banks contiguous?
>
Yes.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/5] cfb_console: Add support for some ANSI terminal escape codes
On Sunday 14 October 2012 01:48:20 Marek Vasut wrote: > Dear Pali Rohár, > > > * This patch add support for move cursor, reverse colors and > > clear console> > >via ANSI espace codes in cfb_console driver > > > > * ANSI escape codes can be enabled/disabled via > > CONFIG_CFB_CONSOLE_ANSI> > > Signed-off-by: Pali Rohár > > --- > > Missing v3? > In "Changes since v2" I wrote what was changed in open interval between v2 and v3. So it is not missing :-) > > Changes since v2: > >- Fixed multiline comments > > > > Changes since v1: > >- Added support ANSI code show/hide cursor > >- Added info to README > > [...] > > I'll leave the rest of the patch up to Anatolij, he's The > Expert. > > Best regards, > Marek Vasut -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/5] arm bootm: Allow to pass board specified atags
Dear Pali Rohár,
> On Sunday 14 October 2012 01:43:25 Marek Vasut wrote:
> > Dear Pali Rohár,
> >
> > ... missing commit message ...
>
> Is not subject enought?
Sorry, but no.
> > > Signed-off-by: Pali Rohár
> > > ---
> > >
> > > arch/arm/include/asm/setup.h |5 +
> > > arch/arm/lib/bootm.c |5 +
> > > 2 files changed, 10 insertions(+)
> >
> > ... missing changelog ...
>
> There is no changelog. This patch is new in v3. I wrote it in
> mail [PATCH v3 0/5].
Good
> > > diff --git a/arch/arm/include/asm/setup.h
> > > b/arch/arm/include/asm/setup.h index 89df4dc..78a7fac 100644
> > > --- a/arch/arm/include/asm/setup.h
> > > +++ b/arch/arm/include/asm/setup.h
> > > @@ -267,3 +267,8 @@ struct meminfo {
> > >
> > > extern struct meminfo meminfo;
> > >
> > > #endif
> > >
> > > +
> > > +/*
> > > + * Board specified tags
> > > + */
> >
> > What's this ?
>
> Function which allow to pass board specified (non standard)
> atags.It is what you suggested:
> http://www.mail-archive.com/u-boot@lists.denx.de/msg82803.html
Oh, there's one more line below. OK.
> > > +void setup_board_tags(struct tag **in_params);
> > > diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> > > index a9070d5..c092bfa 100644
> > > --- a/arch/arm/lib/bootm.c
> > > +++ b/arch/arm/lib/bootm.c
> > > @@ -266,6 +266,10 @@ static int create_fdt(bootm_headers_t
> > > *images)>
> > >
> > > }
> > > #endif
> > >
> > > +void __setup_board_tags(void) {}
> > > +void setup_board_tags(struct tag **in_params)
> > > + __attribute__((weak, alias("__setup_board_tags")));
> >
> > __weak void setup...(...) {} works just fine. Include
> > linux/compiler.h
>
> I did not know about __weak. I will change it.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/5] arm bootm: Do not append zero ATAG_MEM
Dear Pali Rohár,
> On Sunday 14 October 2012 01:45:06 Marek Vasut wrote:
> > > for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> > >
> > > + if (bd->bi_dram[i].size == 0)
> > > + continue;
> >
> > This doesn't look right at all, your board is misconfigured if
> > bd->bi_dram[i] == 0. Did you misconfigure CONFIG_NR_DRAM_BANKS
> > ?
>
> On some N900 devices there are two banks and on some only one. If
> there is only one it has size 256 MB and if there are two both
> has 128 MB. CONFIG_NR_DRAM_BANKS must be specified at compile
> time, but for N900 I need runtime detection.
How can that be? Are these two banks contiguous?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Add power bus message definitions in twl4030.h
Dear Pali Rohár, > On Sunday 14 October 2012 01:46:30 you wrote: > > Dear Pali Rohár, > > > > > * Code copied from linux kernel 3.0.0 from file > > > include/linux/i2c/twl.h > > > > Missing commit ... see > > http://www.denx.de/wiki/U-Boot/Patches#Attributing_Code_Copyrig > > hts_Sign > > "... provide terse but precise information which exact version or > even commit ID was used ..." > > I copied code from 3.0.0 tarball, so I do not know commit ID. But > 3.0.0 is exact version. Look here: http://git.kernel.org/?p=linux/kernel/git/marex/linux-2.6.git;a=summary > > [...] > > > > Missing changelog > > Nothing was changed. It'd be good to state that. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Add power bus message definitions in twl4030.h
On Sunday 14 October 2012 01:46:30 you wrote: > Dear Pali Rohár, > > > * Code copied from linux kernel 3.0.0 from file > > include/linux/i2c/twl.h > Missing commit ... see > http://www.denx.de/wiki/U-Boot/Patches#Attributing_Code_Copyrig > hts_Sign "... provide terse but precise information which exact version or even commit ID was used ..." I copied code from 3.0.0 tarball, so I do not know commit ID. But 3.0.0 is exact version. > [...] > > Missing changelog > Nothing was changed. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/5] arm bootm: Do not append zero ATAG_MEM
On Sunday 14 October 2012 01:45:06 Marek Vasut wrote:
> >
> > for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> >
> > + if (bd->bi_dram[i].size == 0)
> > + continue;
>
> This doesn't look right at all, your board is misconfigured if
> bd->bi_dram[i] == 0. Did you misconfigure CONFIG_NR_DRAM_BANKS
> ?
On some N900 devices there are two banks and on some only one. If
there is only one it has size 256 MB and if there are two both
has 128 MB. CONFIG_NR_DRAM_BANKS must be specified at compile
time, but for N900 I need runtime detection.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] New board support: Nokia RX-51 aka N900
Dear Pali Rohár,
> Based on previous work by: Alistair Buxton
>
> Signed-off-by: Pali Rohár
> Cc: Ивайло Димитров
Can we please stick to ASCII instead of UTF8?
Cc: Ivaylo Dimitrov (if I'm not mistaken)
> ---
> Changes since v2:
>- Added documentation in doc/README.nokia_rx51
>- Updated MAINTAINERS
>- Fixed Fix omap_mmc_init
>- Code for errata 430973 workaround
>- Added board specified atag support
>- Generate omap atag table instead reusing from NOLO
>- Load bootmenu.src always
>- Enabled ext4 support
>- Fixed comments
>- Reserve protected RAM for attached kernel
>- Rewritten assembler code in lowlevel_init.S
>- Reset lp5523 led on init
>
> Changes since v1:
>- Set correct configs for Memory Map
>- Enable passing memory tag to kernel atags
>- Use gpio input command for detecting keyboard slide
>- Restore powerbus state after calling twl4030 regulator code
>- Renamed command noloboot to attachboot
>- Atag address must be always 0x8100, removed code from lowlevel
>- Added usb vendor, product id and product name
>- Enabled command line editing
>- Fixed keymap and cursor keys
>
> Changes since original version:
>- Removed Makefile targets: clean and distclean
>- Rewrited bootcommand and env variables in nokia_rx51.h
>- Removed useless CONFIG defines in nokia_rx51.h
>- Disable L2 cache with CONFIG_SYS_L2CACHE_OFF - fixed battery draining
>- Added onenand support (default disabled due to big u-boot size)
>- Moved inlined asm code to new file lowlevel_init.S
>- Fixed commit message
>
> MAINTAINERS |4 +
> board/nokia/rx51/Makefile| 46 +++
> board/nokia/rx51/lowlevel_init.S | 209
> board/nokia/rx51/rx51.c | 673
> ++ board/nokia/rx51/rx51.h |
> 389 ++
> board/nokia/rx51/tag_omap.h | 311 ++
> boards.cfg |1 +
> doc/README.nokia_rx51| 104 ++
> include/configs/nokia_rx51.h | 452 +
> 9 files changed, 2189 insertions(+)
> create mode 100644 board/nokia/rx51/Makefile
> create mode 100644 board/nokia/rx51/lowlevel_init.S
> create mode 100644 board/nokia/rx51/rx51.c
> create mode 100644 board/nokia/rx51/rx51.h
> create mode 100644 board/nokia/rx51/tag_omap.h
> create mode 100644 doc/README.nokia_rx51
> create mode 100644 include/configs/nokia_rx51.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 971235b..613d8cd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1009,6 +1009,10 @@ Nobuhiro Iwamatsu
>
> armadillo-800evaR8A7740 (RMOBILE SoC)
>
> +Pali Rohár
> +
> + nokia_rx51 ARM ARMV7 (OMAP3xx SoC)
OMAP3xxx or OMAP34xx
> +
> -
>
[..]
> +relocaddr: /* address of this relocaddr section after coping */
> + .word . /* address of section (calculated at compile time) */
> +
> +startaddr: /* address of u-boot after copying */
> + .word CONFIG_SYS_TEXT_BASE
> +
> +kernaddr:/* address of kernel after copying */
> + .word KERNEL_ADDRESS
> +
> +kernsize:/* maximal size of kernel image */
> + .word KERNEL_MAXSIZE
> +
> +kernoffs:/* offset of kernel image in loaded u-boot */
> + .word KERNEL_OFFSET
> +
> +imagesize: /* maximal size of image */
> + .word IMAGE_MAXSIZE
> +
> +ih_magic:/* IH_MAGIC in big endian from include/image.h */
> + .word 0x56190527
> +
> +/*
Try using the new kerneldoc style, the tools are now in.
See eg. here about the annotations:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/144173
Also see:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kernel-
doc-nano-HOWTO.txt
> + * Routine: save_boot_params (called after reset from start.S)
> + * Description: Copy attached kernel to address KERNEL_ADDRESS
> + * Copy u-boot to address CONFIG_SYS_TEXT_BASE
> + * Return to copied u-boot address
> + */
> +
> +.global save_boot_params
> +save_boot_params:
[...]
How much of the assembler crap can be made C?
[...]
> +static char *boot_reason_ptr;
> +static char *hw_build_ptr;
> +static char *nolo_version_ptr;
> +static char *boot_mode_ptr;
> +
> +/*
> + * Routine: init_omap_tags
> + * Description: Initialize pointers to values in tag_omap
> + */
> +static void init_omap_tags(void)
> +{
> + char *component;
> + char *version;
> + int i = 0;
> + while (omap[i].hdr.tag) {
> + switch (omap[i].hdr.tag) {
> + case OMAP_TAG_BOOT_REASON:
> + boot_reason_ptr = omap[i].u.boot_reason.reason_str;
> + break;
> + case OMAP_TAG_VERSION_STR:
> + component = omap[i].u.version.comp
Re: [U-Boot] [PATCH v3 1/5] arm bootm: Allow to pass board specified atags
On Sunday 14 October 2012 01:43:25 Marek Vasut wrote:
> Dear Pali Rohár,
>
> ... missing commit message ...
>
Is not subject enought?
> > Signed-off-by: Pali Rohár
> > ---
> >
> > arch/arm/include/asm/setup.h |5 +
> > arch/arm/lib/bootm.c |5 +
> > 2 files changed, 10 insertions(+)
>
> ... missing changelog ...
>
There is no changelog. This patch is new in v3. I wrote it in
mail [PATCH v3 0/5].
> > diff --git a/arch/arm/include/asm/setup.h
> > b/arch/arm/include/asm/setup.h index 89df4dc..78a7fac 100644
> > --- a/arch/arm/include/asm/setup.h
> > +++ b/arch/arm/include/asm/setup.h
> > @@ -267,3 +267,8 @@ struct meminfo {
> >
> > extern struct meminfo meminfo;
> >
> > #endif
> >
> > +
> > +/*
> > + * Board specified tags
> > + */
>
> What's this ?
>
Function which allow to pass board specified (non standard)
atags. It is what you suggested:
http://www.mail-archive.com/u-boot@lists.denx.de/msg82803.html
> > +void setup_board_tags(struct tag **in_params);
> > diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> > index a9070d5..c092bfa 100644
> > --- a/arch/arm/lib/bootm.c
> > +++ b/arch/arm/lib/bootm.c
> > @@ -266,6 +266,10 @@ static int create_fdt(bootm_headers_t
> > *images)>
> > }
> > #endif
> >
> > +void __setup_board_tags(void) {}
> > +void setup_board_tags(struct tag **in_params)
> > + __attribute__((weak, alias("__setup_board_tags")));
>
> __weak void setup...(...) {} works just fine. Include
> linux/compiler.h
I did not know about __weak. I will change it.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/5] cfb_console: Add support for some ANSI terminal escape codes
Dear Pali Rohár, > * This patch add support for move cursor, reverse colors and clear console >via ANSI espace codes in cfb_console driver > * ANSI escape codes can be enabled/disabled via CONFIG_CFB_CONSOLE_ANSI > > Signed-off-by: Pali Rohár > --- Missing v3? > Changes since v2: >- Fixed multiline comments > > Changes since v1: >- Added support ANSI code show/hide cursor >- Added info to README [...] I'll leave the rest of the patch up to Anatolij, he's The Expert. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Add power bus message definitions in twl4030.h
Dear Pali Rohár, > * Code copied from linux kernel 3.0.0 from file include/linux/i2c/twl.h Missing commit ... see http://www.denx.de/wiki/U-Boot/Patches#Attributing_Code_Copyrights_Sign [...] Missing changelog [...] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/5] arm bootm: Do not append zero ATAG_MEM
Dear Pali Rohár,
> If dram bank size is calculated at runtime, it can be zero on some boards.
> This patch added code which ignore these zero bank size in ATAG_MEM.
>
> Signed-off-by: Pali Rohár
> ---
> arch/arm/lib/bootm.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index c092bfa..925925d 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -132,6 +132,9 @@ static void setup_memory_tags(bd_t *bd)
> int i;
>
> for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> + if (bd->bi_dram[i].size == 0)
> + continue;
This doesn't look right at all, your board is misconfigured if bd->bi_dram[i]
==
0. Did you misconfigure CONFIG_NR_DRAM_BANKS ?
> params->hdr.tag = ATAG_MEM;
> params->hdr.size = tag_size (tag_mem32);
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/5] arm bootm: Allow to pass board specified atags
Dear Pali Rohár,
... missing commit message ...
> Signed-off-by: Pali Rohár
> ---
> arch/arm/include/asm/setup.h |5 +
> arch/arm/lib/bootm.c |5 +
> 2 files changed, 10 insertions(+)
... missing changelog ...
> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
> index 89df4dc..78a7fac 100644
> --- a/arch/arm/include/asm/setup.h
> +++ b/arch/arm/include/asm/setup.h
> @@ -267,3 +267,8 @@ struct meminfo {
> extern struct meminfo meminfo;
>
> #endif
> +
> +/*
> + * Board specified tags
> + */
What's this ?
> +void setup_board_tags(struct tag **in_params);
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index a9070d5..c092bfa 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -266,6 +266,10 @@ static int create_fdt(bootm_headers_t *images)
> }
> #endif
>
> +void __setup_board_tags(void) {}
> +void setup_board_tags(struct tag **in_params)
> + __attribute__((weak, alias("__setup_board_tags")));
__weak void setup...(...) {} works just fine. Include linux/compiler.h
> /* Subcommand: PREP */
> static void boot_prep_linux(bootm_headers_t *images)
> {
> @@ -307,6 +311,7 @@ static void boot_prep_linux(bootm_headers_t *images)
> setup_initrd_tag(gd->bd, images->rd_start,
> images->rd_end);
> #endif
> + setup_board_tags(¶ms);
> setup_end_tag(gd->bd);
> #else /* all tags */
> printf("FDT and ATAGS support not compiled in - hanging\n");
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot git usage model
Dear Tom, In message <5079d95e.4070...@ti.com> you wrote: > > While also IANAL (and I try and stay out of these discussions), paging > around in the kernel log it sure seems like Linus and akpm both add > S-O-B when they git am something in (perhaps why there is git am > --signoff?) but not when it comes via pull request. In other words, > up until the point it goes into intended-to-be-pulled-somehow-someway > git, whomever is presenting the work adds one (or more) to say I (we) > worked on it and yes, applies as well as the person bringing it in (I > touch this and believe it to be). Yes, git am has such an option. But git fetch (or pull) does not. I see no technical difference if someone provides me a patch as such, or in form of a git repository with this patch applied so I can just "git fetch" from it. In both cases the result would be exactly the same: I add the patch to my local repository. But in one case I am supposed to sign it (and tools offer me options to do so), but in the other case I cannot do that, even if I wanted? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "It takes all sorts of in & out-door schooling to get adapted to my kind of fooling" - R. Frost ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot git usage model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/13/12 12:30, Wolfgang Denk wrote: [snip] > Yes, I am aware it is also possible to interpret this as "anybody > in the patch's delivery path" - but even then I cannot derive any > obligation for such a passer-on to add his SoB. While also IANAL (and I try and stay out of these discussions), paging around in the kernel log it sure seems like Linus and akpm both add S-O-B when they git am something in (perhaps why there is git am - --signoff?) but not when it comes via pull request. In other words, up until the point it goes into intended-to-be-pulled-somehow-someway git, whomever is presenting the work adds one (or more) to say I (we) worked on it and yes, applies as well as the person bringing it in (I touch this and believe it to be). - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQedleAAoJENk4IS6UOR1WuDsP/RO40omO2g/1QBUhwr0rddrS KocAiHI4txaRxMKaHEn/cISyXpgHBnSMVen9L9iWOQo8HYVfHuusRM500nEYdsZy BBSgiY0IUSkmINHrztc4WxF6sPadJQcftFeE1Rxi4p5uNNCn/luNyPAK5Hi3N1Kw ZjmayqU8lmcjh3nt1jpzTtzkOuLmx+HwhKo7V5CuPklbvAidt2CsRI7cUHFUgcx2 Gw//6zQPGbW/Z5NcimuyyvwYa5csz2/lZJdyb4tTGgbTHDwrwmKbbRa6EUA4bEIb saUqgff4jCY2/NgYuwc6zvz/aBgD3n165libtBTMBZfq3+RNbxzd4SDmsp1tTy24 0ZP40WAL2+0++mW/QptYJU4v7FcnEXjPVJJnxAcxXu+qZSKoYzVf1B+mel7rd1PB YLLGjxbsH9vN+BWqkjyc+OwhubiLGtdGVq+21JCwR2VZKM311UWXW1MVZ7K3wiyH 5iYhyRPWHUPG9xj4ObVRrOJMtqPqnvc3Qq/u1e/ukzrCvCb2iv1cEVqOJlapCNWU 2wxPCimO9w9zHESBJVPFPqKQCrOAGRta4ouMMx2D1Hti4XYhBxVgB9x/nQ9w+QcS f0OkEu6dZKtHEpLY+tI+DDiJfvxBGXA/xzrEdmRKQ3WoxV/luu3cAga9uo/BhyyM HNAILD2siVXVutUPZZYk =ODaw -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/5] arm bootm: Do not append zero ATAG_MEM
If dram bank size is calculated at runtime, it can be zero on some boards.
This patch added code which ignore these zero bank size in ATAG_MEM.
Signed-off-by: Pali Rohár
---
arch/arm/lib/bootm.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index c092bfa..925925d 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -132,6 +132,9 @@ static void setup_memory_tags(bd_t *bd)
int i;
for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
+ if (bd->bi_dram[i].size == 0)
+ continue;
+
params->hdr.tag = ATAG_MEM;
params->hdr.size = tag_size (tag_mem32);
--
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 V3 2/4] FAT: make use of disk_partition_t.part
Hi On Wednesday 10 October 2012 12:14:00 Stephen Warren wrote: > From: Stephen Warren > > This removes the standalone cur_part_nr variable, opening the way to > replacing fat_register_device() with fat_set_blk_dev(). > > Note that when get_partition_info() fails and we use the entire disk, > the correct partition number is 0 (whole disk) not 1 (first partition), > so that change is also made here. > > An alternative to this (and the previous) patch might be to simply > remove the partition number from the printf(). I don't know how attached > people are to it. > > Signed-off-by: Stephen Warren Just as a heads up, in the DM any difference between a partition and a whole block device (also between different interfaces for disks) is hidden from any user code (code other than the one keeping track of partitions/disks, that only uses such information to determine whether to scan for partitions), you only get some object that can read/write blocks if you ask it nicely, and you have to make do with that (if you need more then you're probably doing something wrong). As a result, there is no notion of partition number, and the string you are patching up here (along with many others, due to unification of disk interfaces) is changed. Best Regards Pavel Herrmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/5] arm bootm: Allow to pass board specified atags
Signed-off-by: Pali Rohár
---
arch/arm/include/asm/setup.h |5 +
arch/arm/lib/bootm.c |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index 89df4dc..78a7fac 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -267,3 +267,8 @@ struct meminfo {
extern struct meminfo meminfo;
#endif
+
+/*
+ * Board specified tags
+ */
+void setup_board_tags(struct tag **in_params);
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index a9070d5..c092bfa 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -266,6 +266,10 @@ static int create_fdt(bootm_headers_t *images)
}
#endif
+void __setup_board_tags(void) {}
+void setup_board_tags(struct tag **in_params)
+ __attribute__((weak, alias("__setup_board_tags")));
+
/* Subcommand: PREP */
static void boot_prep_linux(bootm_headers_t *images)
{
@@ -307,6 +311,7 @@ static void boot_prep_linux(bootm_headers_t *images)
setup_initrd_tag(gd->bd, images->rd_start,
images->rd_end);
#endif
+ setup_board_tags(¶ms);
setup_end_tag(gd->bd);
#else /* all tags */
printf("FDT and ATAGS support not compiled in - hanging\n");
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot git usage model
Dear Scott Wood, In message <1349980244.6903.13@snotra> you wrote: > > > The number of people working on next should be small and manageable. > > More people likely use next than some custodian branches, and those are > supposed to be rebase-free... > > Wouldn't anyone developing code for the next merge window be working on > next, > at least when it's not out of date? Yes. And we do not rebase next lightly nor often (just check this history how often this happened in the past). But we explicitly reserve the right of doing this to make sure we get the needed quality of the code before pulling it into master, which definitely cannot be rebased. So instead of knowingly pulling blatant crap into master we will rather make this exception and rebase next. > IMHO it would be nice for the next branch to open immediately after the > merge window closes, and be kept up to date except during the merge > window. Historically the next branch has opened when someone requests > a pull into it, but how do I make a sane pull request when the next > branch has been untouched since the last release? No. Historically next was opened when -rc1 was released. In theory this would be at the end of the MW, but I always found myself with a large backlog of patches tat were not picked up by any custodian trees but left waiting, and I wanted to have these included in the -rc1, which reasulted in the often week-long delay. Provide more people processing patches, say pushing stuff through the staging repo etc., and we can easily reduce this delay. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Women professionals do tend to over-compensate. -- Dr. Elizabeth Dehaver, "Where No Man Has Gone Before", stardate 1312.9. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/5] cfb_console: Add support for some ANSI terminal escape codes
* This patch add support for move cursor, reverse colors and clear console
via ANSI espace codes in cfb_console driver
* ANSI escape codes can be enabled/disabled via CONFIG_CFB_CONSOLE_ANSI
Signed-off-by: Pali Rohár
---
Changes since v2:
- Fixed multiline comments
Changes since v1:
- Added support ANSI code show/hide cursor
- Added info to README
Changes since original version:
- Fixed commit message
README |3 +
drivers/video/cfb_console.c | 313 +--
2 files changed, 307 insertions(+), 9 deletions(-)
diff --git a/README b/README
index 9804cea..d45a91d 100644
--- a/README
+++ b/README
@@ -655,6 +655,9 @@ The following options need to be configured:
additional board info beside
the logo
+ When CONFIG_CFB_CONSOLE_ANSI is defined, console will have
+ ANSI terminal support. Needed for CONFIG_CMDLINE_EDITING.
+
When CONFIG_CFB_CONSOLE is defined, video console is
default i/o. Serial console can be forced with
environment 'console=serial'.
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 9f7794f..3ed96d3 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -385,6 +385,11 @@ static u32 eorx, fgx, bgx; /* color pats */
static int cfb_do_flush_cache;
+static char ansi_buf[10] = { 0, };
+static int ansi_buf_size;
+static int ansi_colors_need_revert;
+static int ansi_cursor_hidden;
+
static const int video_font_draw_table8[] = {
0x, 0x00ff, 0xff00, 0x,
0x00ff, 0x00ff00ff, 0x0000, 0x00ff,
@@ -612,6 +617,14 @@ static void video_putchar(int xx, int yy, unsigned char c)
video_drawchars(xx, yy + video_logo_height, &c, 1);
}
+static void console_swap_colors(void)
+{
+ eorx = fgx;
+ fgx = bgx;
+ bgx = eorx;
+ eorx = fgx ^ bgx;
+}
+
#if defined(CONFIG_CONSOLE_CURSOR) || defined(CONFIG_VIDEO_SW_CURSOR)
static void video_set_cursor(void)
{
@@ -695,6 +708,21 @@ static void memcpyl(int *d, int *s, int c)
}
#endif
+static void console_clear(void)
+{
+#ifdef VIDEO_HW_RECTFILL
+ video_hw_rectfill(VIDEO_PIXEL_SIZE, /* bytes per pixel */
+ 0,/* dest pos x */
+ video_logo_height,/* dest pos y */
+ VIDEO_VISIBLE_COLS, /* frame width */
+ VIDEO_VISIBLE_ROWS, /* frame height */
+ bgx /* fill color */
+ );
+#else
+ memsetl(CONSOLE_ROW_FIRST, CONSOLE_SIZE, bgx);
+#endif
+}
+
static void console_clear_line(int line, int begin, int end)
{
#ifdef VIDEO_HW_RECTFILL
@@ -768,9 +796,54 @@ static void console_back(void)
}
}
-static void console_newline(void)
+static void console_cursor_fix(void)
+{
+ if (console_row < 0)
+ console_row = 0;
+ if (console_row >= CONSOLE_ROWS)
+ console_row = CONSOLE_ROWS-1;
+ if (console_col < 0)
+ console_col = 0;
+ if (console_col >= CONSOLE_COLS)
+ console_col = CONSOLE_COLS-1;
+}
+
+static void console_cursor_up(int n)
+{
+ console_row -= n;
+ console_cursor_fix();
+}
+
+static void console_cursor_down(int n)
+{
+ console_row += n;
+ console_cursor_fix();
+}
+
+static void console_cursor_left(int n)
+{
+ console_col -= n;
+ console_cursor_fix();
+}
+
+static void console_cursor_right(int n)
+{
+ console_col += n;
+ console_cursor_fix();
+}
+
+static void console_cursor_set_position(int row, int col)
+{
+ if (console_row != -1)
+ console_row = row;
+ if (console_col != -1)
+ console_col = col;
+ console_cursor_fix();
+}
+
+static void console_newline(int n)
{
- console_row++;
+ console_row += n;
console_col = 0;
/* Check if we need to scroll the terminal */
@@ -779,20 +852,28 @@ static void console_newline(void)
console_scrollup();
/* Decrement row number */
- console_row--;
+ console_row = CONSOLE_ROWS-1;
}
}
+static void console_previewsline(int n)
+{
+ /* FIXME: also scroll terminal ? */
+ console_row -= n;
+ console_cursor_fix();
+}
+
static void console_cr(void)
{
console_col = 0;
}
-void video_putc(const char c)
+static void parse_putc(const char c)
{
static int nl = 1;
- CURSOR_OFF;
+ if (!ansi_cursor_hidden)
+ CURSOR_OFF;
switch (c) {
case 13:/* back to first column */
@@ -801,7 +882,7 @@ void video_putc(const char c)
case '\n': /* next line */
if (console_col || (!console_col && nl))
-
[U-Boot] [PATCH v3 3/5] Add power bus message definitions in twl4030.h
* Code copied from linux kernel 3.0.0 from file include/linux/i2c/twl.h Signed-off-by: Pali Rohár --- include/twl4030.h | 98 + 1 file changed, 98 insertions(+) diff --git a/include/twl4030.h b/include/twl4030.h index 9cd32ab..0c17f59 100644 --- a/include/twl4030.h +++ b/include/twl4030.h @@ -151,6 +151,103 @@ #define TWL4030_PM_MASTER_SW_EVENTS_DEVSLP (1 << 1) #define TWL4030_PM_MASTER_SW_EVENTS_DEVOFF (1 << 0) +/* Power bus message definitions */ + +/* The TWL4030/5030 splits its power-management resources (the various + * regulators, clock and reset lines) into 3 processor groups - P1, P2 and + * P3. These groups can then be configured to transition between sleep, wait-on + * and active states by sending messages to the power bus. See Section 5.4.2 + * Power Resources of TWL4030 TRM + */ + +/* Processor groups */ +#define DEV_GRP_NULL 0x0 +#define DEV_GRP_P1 0x1 /* P1: all OMAP devices */ +#define DEV_GRP_P2 0x2 /* P2: all Modem devices */ +#define DEV_GRP_P3 0x4 /* P3: all peripheral devices */ + +/* Resource groups */ +#define RES_GRP_RES0x0 /* Reserved */ +#define RES_GRP_PP 0x1 /* Power providers */ +#define RES_GRP_RC 0x2 /* Reset and control */ +#define RES_GRP_PP_RC 0x3 +#define RES_GRP_PR 0x4 /* Power references */ +#define RES_GRP_PP_PR 0x5 +#define RES_GRP_RC_PR 0x6 +#define RES_GRP_ALL0x7 /* All resource groups */ + +#define RES_TYPE2_R0 0x0 + +#define RES_TYPE_ALL 0x7 + +/* Resource states */ +#define RES_STATE_WRST 0xF +#define RES_STATE_ACTIVE 0xE +#define RES_STATE_SLEEP0x8 +#define RES_STATE_OFF 0x0 + +/* Power resources */ + +/* Power providers */ +#define RES_VAUX1 1 +#define RES_VAUX2 2 +#define RES_VAUX3 3 +#define RES_VAUX4 4 +#define RES_VMMC1 5 +#define RES_VMMC2 6 +#define RES_VPLL1 7 +#define RES_VPLL2 8 +#define RES_VSIM9 +#define RES_VDAC10 +#define RES_VINTANA111 +#define RES_VINTANA212 +#define RES_VINTDIG 13 +#define RES_VIO 14 +#define RES_VDD115 +#define RES_VDD216 +#define RES_VUSB_1V517 +#define RES_VUSB_1V818 +#define RES_VUSB_3V119 +#define RES_VUSBCP 20 +#define RES_REGEN 21 +/* Reset and control */ +#define RES_NRES_PWRON 22 +#define RES_CLKEN 23 +#define RES_SYSEN 24 +#define RES_HFCLKOUT25 +#define RES_32KCLKOUT 26 +#define RES_RESET 27 +/* Power Reference */ +#define RES_Main_Ref28 + +#define TOTAL_RESOURCES28 +/* + * Power Bus Message Format ... these can be sent individually by Linux, + * but are usually part of downloaded scripts that are run when various + * power events are triggered. + * + * Broadcast Message (16 Bits): + *DEV_GRP[15:13] MT[12] RES_GRP[11:9] RES_TYPE2[8:7] RES_TYPE[6:4] + *RES_STATE[3:0] + * + * Singular Message (16 Bits): + *DEV_GRP[15:13] MT[12] RES_ID[11:4] RES_STATE[3:0] + */ + +#define MSG_BROADCAST(devgrp, grp, type, type2, state) \ + ((devgrp) << 13 | 1 << 12 | (grp) << 9 | (type2) << 7 \ + | (type) << 4 | (state)) + +#define MSG_SINGULAR(devgrp, id, state) \ + ((devgrp) << 13 | 0 << 12 | (id) << 4 | (state)) + +#define MSG_BROADCAST_ALL(devgrp, state) \ + ((devgrp) << 5 | (state)) + +#define MSG_BROADCAST_REF MSG_BROADCAST_ALL +#define MSG_BROADCAST_PROV MSG_BROADCAST_ALL +#define MSG_BROADCAST__CLK_RST MSG_BROADCAST_ALL + /* Power Managment Receiver */ #define TWL4030_PM_RECEIVER_SC_CONFIG 0x5B #define TWL4030_PM_RECEIVER_SC_DETECT1 0x5C @@ -311,6 +408,7 @@ #define TWL4030_PM_RECEIVER_VDAC_VSEL_18 0x03 #define TWL4030_PM_RECEIVER_VMMC1_VSEL_30 0x02 #define TWL4030_PM_RECEIVER_VMMC1_VSEL_32 0x03 +#define TWL4030_PM_RECEIVER_VSIM_VSEL_18 0x03 /* Device Selection in PM Receiver Module */ #define TWL4030_PM_RECEIVER_DEV_GRP_P1 0x20 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/5] Nokia RX-51 support
This patch series add support for new board Nokia RX-51 (aka N900). This patch series supersedes version v2. Patch details: Already commited (dropped) patches: cfb_console: Fix function console_back cfb_console: Add function console_clear and console_clear_line cfb_console: Add functions for moving with cursor cfb_console: Ignore bell character Dropped patches: arm: Optionally use existing atags in bootm.c New command clear: Clear the ANSI terminal New config variable CONFIG_PREMONITOR New patches: arm bootm: Allow to pass board specified atags arm bootm: Do not append zero ATAG_MEM Pali Rohár (5): arm bootm: Allow to pass board specified atags arm bootm: Do not append zero ATAG_MEM Add power bus message definitions in twl4030.h cfb_console: Add support for some ANSI terminal escape codes New board support: Nokia RX-51 aka N900 MAINTAINERS |4 + README |3 + arch/arm/include/asm/setup.h |5 + arch/arm/lib/bootm.c |8 + board/nokia/rx51/Makefile| 46 +++ board/nokia/rx51/lowlevel_init.S | 209 board/nokia/rx51/rx51.c | 673 ++ board/nokia/rx51/rx51.h | 389 ++ board/nokia/rx51/tag_omap.h | 311 ++ boards.cfg |1 + doc/README.nokia_rx51| 104 ++ drivers/video/cfb_console.c | 313 +- include/configs/nokia_rx51.h | 452 + include/twl4030.h| 98 ++ 14 files changed, 2607 insertions(+), 9 deletions(-) create mode 100644 board/nokia/rx51/Makefile create mode 100644 board/nokia/rx51/lowlevel_init.S create mode 100644 board/nokia/rx51/rx51.c create mode 100644 board/nokia/rx51/rx51.h create mode 100644 board/nokia/rx51/tag_omap.h create mode 100644 doc/README.nokia_rx51 create mode 100644 include/configs/nokia_rx51.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot git usage model
Dear Albert ARIBAUD, In message <20121011203003.02f27b2d@lilith> you wrote: > > > > The Signed-off-by: tag indicates that the signer was involved in the > > > development of the patch, or that he/she was in the patch's delivery path. > > My bad. I've indeed misread the Linux doc. However, the U-Boot doc is > clearly on the side of "no Signed-off-by from custodians". Why do you think you misread anything? The sentence above explains what the SoB _means_. To me it does not include _any_ information about who should add such a line. _This_ is explained in other parts of the document, i. e. the "you wrote it or otherwise have the right to pass it on as an open-source patch". I have strong reason to believe (by remember, IANAL) that the "or" in this statement is intended to cover the cases where the original author(s) cannot or shal not be disclosed for some reason (for example, because company FOO does not want to disclose who or how many people exactly are working on a specific task, and/or where these are located). In this case it simply means: yes, I guarantee you this can be used without restriction as an open-source patch even though I cannot/will not tell you who actually is/are the author(s). Yes, I am aware it is also possible to interpret this as "anybody in the patch's delivery path" - but even then I cannot derive any obligation for such a passer-on to add his SoB. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you're not part of the solution, then you're part of the precipi- tate. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] fs: add partition switch libary, implement ls and fsload commands
Hi On Wednesday 10 October 2012 18:05:07 Stephen Warren wrote: > ...snip... > Makefile|3 +- > common/Makefile |2 + > common/cmd_fs.c | 86 ++ > fs/Makefile | 47 > fs/fs.c | 216 > +++ include/fs.h| > 49 + > 6 files changed, 402 insertions(+), 1 deletions(-) > create mode 100644 common/cmd_fs.c > create mode 100644 fs/Makefile > create mode 100644 fs/fs.c > create mode 100644 include/fs.h I dont see how this is a "partition switch library", when it doesnt deal with partitions at all. Care to explain? Or maybe call it "filesystem-auto detection" or something? Best Regards Pavel Herrmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot git usage model
Dear Scott Wood, In message <1349979213.6903.11@snotra> you wrote: > > I've been signing off patches I apply to the NAND tree. I recall > stopping at one point in the past because someone complained, and then > starting again -- not sure if someone else complained about doing it > *that* way, or if I just noticed others doing it. > > Looking through the history I see others that seems to be doing the > same (outside ARMland), though I can't say for sure without > investigating whether the patch was "passed on without any changes" in > each instance. It appears there are companies who evaluate their engineers based on the number of statistical data (including SoB lines in public repositories). Sosome cases such doing may be just some form of collecting brownie points... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You don't have to stay up nights to succeed; you have to stay awake days. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot git usage model
Dear Stephen Warren, In message <50770155.20...@wwwdotorg.org> you wrote: > > and in particular, the following parts of that doc is what tells me that > committers should always add S-o-b even if the commit didn't change: > > > Developer's Certificate of Origin 1.1 > > > > By making a contribution to this project, I certify that: > ... > > (c) The contribution was provided directly to me by some other > > person who certified (a), (b) or (c) and I have not modified > > it. No, I think you misinterpret this ;-) This is intended for cases where the original author of the patch shall remain unknown for whatever reasons. Consider some bigger companies doing a lot of their actual development in low-cost countries (say, China). They usually have a ton of developers workignon such stuff, and only one (or very few) people who "interface" ith the community. It is these interface-guys who will add their SoB based on above rule, meaning: yes, I can certify that this is Open Source, and even though the original author shall remain unnamed this can be used freely in this context. I don't see how you derive fromt hat that a custodian applying a patch without modifications should add a SoB? If so, then please explain where the limits are? Aplying from a mailbox file from a mailing list? Or from some archive (say, patchwork)? Or pulling from some repository provided by the original author? Or pulling from a downstream repository in your own project? Spinning this to an end consequently, I think we would have to add a new SoB line to all commits for any git pull we are doing (which caanot be the intention, and which cannot work). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Philosophy is a game with objectives and no rules. Mathematics is a game with rules and no objectives. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot git usage model
Dear Stephen Warren, In message <5076fb24.1080...@wwwdotorg.org> you wrote: > > True, tags can be moved. However, the point wasn't that they're > immutable, but that using them can decouple the pull process from the > commit process. For example, I could: > > git checkout -b foo bar > git am > git am > git am > git tag -s tag1 foo > send pull request > not wait for pull to complete > git am > git am > git am > git tag -s tag2 foo > send pull request What do you need tags here for? The git commit ID's itself will be as good. On contrary - using your proposed style, you sill just pollute the tag namespace with tons of more or less random tags. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Brontosaurus Principle: Organizations can grow faster than their brains can manage them in relation to their environment and to their own physiology: when this occurs, they are an endangered species. - Thomas K. Connellan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot git usage model
Dear Scott Wood, In message <1349974486.6903.5@snotra> you wrote: > > Is this documented anywhere? > > http://www.denx.de/wiki/U-Boot/DevelopmentProcess says, "U-Boot has > adopted the Linux kernel signoff policy". > > Actual behavior is probably inconsistent between custodians. This is documented, see previous discussions. We're referring to linux/Documentation/SubmittingPatches . Unfortunaltely this leaves room to interpretation, and depending on thier own interpretation people behave differently. To me the most interesting part of this document is this section: If you are a subsystem or branch maintainer, sometimes you need to slightly modify patches you receive in order to merge them, because the code is not exactly the same in your tree and the submitters'. If you stick strictly to rule (c), you should ask the submitter to rediff, but this is a totally counter-productive waste of time and energy. Rule (b) allows you to adjust the code, but then it is very impolite to change one submitter's code and make him endorse your bugs. To solve this problem, it is recommended that you add a line between the last Signed-off-by header and yours, indicating the nature of your changes. While there is nothing mandatory about this, it seems like prepending the description with your mail and/or name, all enclosed in square brackets, is noticeable enough to make it obvious that you are responsible for last-minute changes. Example : Signed-off-by: Random J Developer [lu...@maintainer.example.org: struct foo moved from foo.c to foo.h] Signed-off-by: Lucky K Maintainer This practise is particularly helpful if you maintain a stable branch and want at the same time to credit the author, track changes, merge the fix, and protect the submitter from complaints. Note that under no circumstances can you change the author's identity (the From header), as it is the one which appears in the changelog. In my interpretation this means that one should add a SoB line of one creates or modifies a patch. Just applying it from some published and recoded form does not include any such modification, so why should I add my SoB when applying a patch from PW for example? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de How many hardware guys does it take to change a light bulb? "Well the diagnostics say it's fine buddy, so it's a software problem." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot git usage model
Dear Stephen Warren, In message <5076f9bd.5050...@wwwdotorg.org> you wrote: > > However, U-Boot is reported to only use Signed-off to indicate the > original author(s), so I can see how the git committer field isn't Delete the "original" here. Once a patch has been commited to a tree, it cannot be changed in any way (such as additional authors could do). > considered important in U-Boot. I'm not convinced it's a good idea to be > so cavalier about git metadata though; wouldn't it be better to take > simple steps (never rebase any other committer's commits) so that the > metadata is always correct? Sorry, I cannot parse that. I don't see what rebasing has to do with that. We are talking about the public trees which don't get rebased, neverever. As soon as you allow any rewriting of the hsitory, you will lose _all_ protection given by git through the strong cecksumming of all history. If you give this up, then anything can be modified and faked as you like, including code and metadata. > > Why would I need to know that? > > Personally I believe it's a good idea to document the whole commit/merge > process fully. That's for all the same reasons that git contains No, definitely not. You do not want to ever know how many different repositories and branches I am using in my own specific development process. Normally, any patch or pullrequest processed by me wil go through 5...8 different repositories (and some eventually some branches) before it hist mainline. You would hate me if each of the "git fetc" I'mdoing would create a merge commit. And others might do the same. If the commits allow fast-forwarding, then there is zero sense in recording a merge commit. > metadata for author, committer, datestamps, log messages, etc. The whole > point of source control is to document the development process; Yes, but "development" here means actually changing something. As long as I don't change anything and just pass data around unchanged, it is not necessary to recode any intermediate step I may take. > If you have two commits or series that depend on each-other, e.g. series > A introduces a new feature and series B makes use of that new feature, > and those two series must be applied to different downstream trees for > some reason, then the process would be: > > 1) commit series A to downstream branch X > 2) pull downstream branch X into u-boot/next > 3) either re-create downstream branch Y from u-boot/next, or merge > u-boot/next into existing downstream branch Y > 4) commit series B to downstream branch Y What has u-boot/next to do with this? This should be unrelated. If your tree needs A and B, then just do a "git pull A B" in that tree. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ...when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor. - Fred Brooks, Jr. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] File placement in Soc / board dirs and make issues (was: [PATCH V3 17/32] imximage.cfg: run files through C preprocessor)
On Sat, Oct 13, 2012 at 3:11 AM, Albert ARIBAUD wrote: > Hi Tom, > > On Thu, 11 Oct 2012 16:15:02 -0700, Tom Rini wrote: > >> On Fri, Oct 12, 2012 at 12:27:09AM +0200, stefano babic wrote: >> >> [snip] >> > One reason to move into the board directory is that there was a decision >> > to move rules related to only one arch or SOC where they belong to, that >> > is in the corresponding arch/ or board/ directory. >> >> I'll admit that maybe my make-fu is off, but that idea doesn't work, at >> least for SPL. So I'd really like someone to make that work first. > > Tom, can you be more specific than 'it doesn't work'? :) > > Seriously, though, I'm interested in understand what the make issue is > there, because I am indeed a proponent of putting files where they > belong to, so if help is needed there, I would try to. I have had no luck moving things like the 'MLO' rule from spl/Makefile to anywhere else. Same with the 'checkthumb' rule in the top-level Makefile. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2] qi_lb60: add nand spl support
Hi Marek I will look into CPU-specific. come out with new patches. Xiangfu On 10/13/2012 08:50 PM, Marek Vasut wrote: > This is CPU-specific , right? So it should be some kind of CPU-specific > override > in CPU-specific directory, not polute the main Makefile. > > 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 v5 2/2] qi_lb60: add software usbboot support
On 10/13/2012 08:52 PM, Marek Vasut wrote: > Dear xiangfu liu, > >> > Hi Marek >> > >> > On Sat, Oct 13, 2012 at 8:23 PM, Marek Vasut wrote: >>> > > Dear xiangfu liu, >>> > > > > > Hi Marek > > > > > > This file was wrote by Ingenic people. I don't have time to convert > > > it > > > to C(I am not very good in mips assembler). the .S file implement > > > basic USB stack. >>> > > >>> > > We already do have an USB stack. >> > >> > This usbboot.S implement a very base usb-client protocol and it implement a >> > jz4740 hardware feature. > We have that too -- see drivers/usb/gadget/ Hi Marek I will look into this issue later, try to integrate this jz4740 feature with u-boot usb structure. but I am not sure that if I can finish this fast. wait my patches on jz4740 software usb boot. :) > >> > (jz4740 have a hard-code rom inside cpu. that have >> > the same feature, they named it 'boot from usb'). so this usbboot.S is for >> > implement the same feature in a software way. > Won't DFU work then? > I know this DFU. but it will different with the hardware-feature. Thanks again for feedback. Xiangfu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] qi_lb60: add software usbboot support
Dear xiangfu liu, > Hi Marek > > On Sat, Oct 13, 2012 at 8:23 PM, Marek Vasut wrote: > > Dear xiangfu liu, > > > > > Hi Marek > > > > > > This file was wrote by Ingenic people. I don't have time to convert it > > > to C(I am not very good in mips assembler). the .S file implement > > > basic USB stack. > > > > We already do have an USB stack. > > This usbboot.S implement a very base usb-client protocol and it implement a > jz4740 hardware feature. We have that too -- see drivers/usb/gadget/ > (jz4740 have a hard-code rom inside cpu. that have > the same feature, they named it 'boot from usb'). so this usbboot.S is for > implement the same feature in a software way. Won't DFU work then? > and I think this usbboot.S > can move to 'arch/mips/cpu/xburst/spl/jz4740_usbboot.s' in future. and I > don't think > it will impact with other usb code in u-boot. That's even worse, the USB code shall be in drivers/usb/ > > > this C code ( > > > > http://projects.qi-hardware.com/index.php/p/xburst-tools/source/tree/mast > > er > > > > > /xbboot) implement the host app. the host app source code even clear > > > then the original Ingenic document. so feel free to send patch. > > > > Sorry, but it is my duty as a USB custodian to NAK patches which try to > > circumvent the constant effort to keep the code clean. Obviously, > > implementing > > yet another USB stack is violation of this. > > Yes. I understand your duty. and keep a project code clean is not easy. > thanks for > feedback. (I never look into u-boot usb code. don't have much experience on > u-boot > usb structure. :) > > All the best > Xiangfu 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 v5 1/2] qi_lb60: add nand spl support
Dear Xiangfu Liu, > On 10/13/2012 10:59 AM, Marek Vasut wrote: > >> From: Xiangfu > >> > >> > The JZ4740 CPU can load 8KB from two different addresses: > >> >1. the normal area up to 8KB starting from NAND flash address > >> >0x 2. the backup area up to 8KB starting from NAND flash > >> >address 0x2000 > >> > > >> > After create u-boot-spl.bin. it needs those 4 commands create final > >> > image > >> > > >> > for jz4740 cpu. > >> > > >> > dd if=spl/u-boot-spl.bin of=u-boot-nand.bin conv=sync bs=8192 > >> > count=1 dd if=spl/u-boot-spl.bin of=u-boot-nand.bin > >> > conv=sync,notrunc > >> > > >> > oflag=append bs=8192 count=1 tr '\0' '\377' < /dev/zero | dd > >> > of=u-boot-nand.bin conv=sync,notrunc oflag=append bs=16384 count=1 cat > >> > u-boot-nand.bin u-boot.bin > u-boot-nand-final.bin > >> > > >> > > > > > Can you not do this in the linker script? Or implement CPU-specific build > > target that does this? > > Hi Marex > > Thanks for reply, I don't know how to do this in linker script. but I have > plan to send out a patch on Makefile. > > Attachment is the patch. do you think it is ok for upstream? if it's ok. I > will send out this patch in another email. This is CPU-specific , right? So it should be some kind of CPU-specific override in CPU-specific directory, not polute the main Makefile. 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 v5 2/2] qi_lb60: add software usbboot support
Hi Marek On Sat, Oct 13, 2012 at 8:23 PM, Marek Vasut wrote: > Dear xiangfu liu, > > > Hi Marek > > > > This file was wrote by Ingenic people. I don't have time to convert it to > > C(I am not very good in mips assembler). the .S file implement basic USB > > stack. > > We already do have an USB stack. > This usbboot.S implement a very base usb-client protocol and it implement a jz4740 hardware feature. (jz4740 have a hard-code rom inside cpu. that have the same feature, they named it 'boot from usb'). so this usbboot.S is for implement the same feature in a software way. and I think this usbboot.S can move to 'arch/mips/cpu/xburst/spl/jz4740_usbboot.s' in future. and I don't think it will impact with other usb code in u-boot. > > > this C code ( > > > http://projects.qi-hardware.com/index.php/p/xburst-tools/source/tree/master > > /xbboot) implement the host app. the host app source code even clear then > > the original Ingenic document. so feel free to send patch. > > Sorry, but it is my duty as a USB custodian to NAK patches which try to > circumvent the constant effort to keep the code clean. Obviously, > implementing > yet another USB stack is violation of this. > Yes. I understand your duty. and keep a project code clean is not easy. thanks for feedback. (I never look into u-boot usb code. don't have much experience on u-boot usb structure. :) All the best Xiangfu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2] qi_lb60: add nand spl support
On 10/13/2012 10:59 AM, Marek Vasut wrote: >> From: Xiangfu >> > >> > The JZ4740 CPU can load 8KB from two different addresses: >> >1. the normal area up to 8KB starting from NAND flash address 0x >> >2. the backup area up to 8KB starting from NAND flash address 0x2000 >> > >> > After create u-boot-spl.bin. it needs those 4 commands create final image >> > for jz4740 cpu. >> > dd if=spl/u-boot-spl.bin of=u-boot-nand.bin conv=sync bs=8192 count=1 >> > dd if=spl/u-boot-spl.bin of=u-boot-nand.bin conv=sync,notrunc >> > oflag=append bs=8192 count=1 tr '\0' '\377' < /dev/zero | dd >> > of=u-boot-nand.bin conv=sync,notrunc oflag=append bs=16384 count=1 cat >> > u-boot-nand.bin u-boot.bin > u-boot-nand-final.bin >> > > Can you not do this in the linker script? Or implement CPU-specific build > target > that does this? Hi Marex Thanks for reply, I don't know how to do this in linker script. but I have plan to send out a patch on Makefile. Attachment is the patch. do you think it is ok for upstream? if it's ok. I will send out this patch in another email. Xiangfu diff --git a/Makefile b/Makefile index 34d9075..55fc72d 100644 --- a/Makefile +++ b/Makefile @@ -554,8 +554,16 @@ $(obj)u-boot.lds: $(LDSCRIPT) nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend $(MAKE) -C nand_spl/board/$(BOARDDIR) all +ifdef CONFIG_JZ4740 +$(obj)u-boot-nand.bin: $(obj)u-boot.bin $(obj)spl/u-boot-spl.bin + dd if=$(obj)spl/u-boot-spl.bin of=$(obj)spl/u-boot-nand.bin conv=sync bs=8192 count=1 + dd if=$(obj)spl/u-boot-spl.bin of=$(obj)spl/u-boot-nand.bin conv=sync,notrunc oflag=append bs=8192 count=1 + tr '\0' '\377' < /dev/zero | dd of=$(obj)spl/u-boot-nand.bin conv=sync,notrunc oflag=append bs=16384 count=1 + cat $(obj)spl/u-boot-nand.bin $(obj)u-boot.bin > $(obj)u-boot-nand.bin +else $(obj)u-boot-nand.bin: nand_spl $(obj)u-boot.bin cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > $(obj)u-boot-nand.bin +endif $(obj)spl/u-boot-spl.bin: $(SUBDIR_TOOLS) depend $(MAKE) -C spl all ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] qi_lb60: add software usbboot support
Dear xiangfu liu, > Hi Marek > > This file was wrote by Ingenic people. I don't have time to convert it to > C(I am not very good in mips assembler). the .S file implement basic USB > stack. We already do have an USB stack. > this C code ( > http://projects.qi-hardware.com/index.php/p/xburst-tools/source/tree/master > /xbboot) implement the host app. the host app source code even clear then > the original Ingenic document. so feel free to send patch. Sorry, but it is my duty as a USB custodian to NAK patches which try to circumvent the constant effort to keep the code clean. Obviously, implementing yet another USB stack is violation of this. > Xiangfu > > On Sat, Oct 13, 2012 at 11:01 AM, Marek Vasut wrote: > > Dear xian...@openmobilefree.net, > > > > > From: Xiangfu > > > > > > JZ4740 CPU have a internal ROM have such kind of code, that make > > > JZ4740 can boot from USB > > > > > > usbboot.S can downloads user program from the USB port to internal > > > SRAM and branches to the internal SRAM to execute the program > > > > > > Signed-off-by: Xiangfu > > > --- > > > > > > board/qi/qi_lb60/qi_lb60-spl.c | 20 + > > > board/qi/qi_lb60/usbboot.S | 838 > > > > > > 2 files changed, 858 > > > insertions(+) > > > > > > create mode 100644 board/qi/qi_lb60/usbboot.S > > > > [...] > > > > UGH. Simply ... UGH. > > > > Can that assembler blob not be rewritten into C ? > > > > Best regards, > > Marek Vasut 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 v5 2/2] qi_lb60: add software usbboot support
Hi Marek This file was wrote by Ingenic people. I don't have time to convert it to C(I am not very good in mips assembler). the .S file implement basic USB stack. this C code ( http://projects.qi-hardware.com/index.php/p/xburst-tools/source/tree/master/xbboot) implement the host app. the host app source code even clear then the original Ingenic document. so feel free to send patch. Xiangfu On Sat, Oct 13, 2012 at 11:01 AM, Marek Vasut wrote: > Dear xian...@openmobilefree.net, > > > From: Xiangfu > > > > JZ4740 CPU have a internal ROM have such kind of code, that make > > JZ4740 can boot from USB > > > > usbboot.S can downloads user program from the USB port to internal > > SRAM and branches to the internal SRAM to execute the program > > > > Signed-off-by: Xiangfu > > --- > > board/qi/qi_lb60/qi_lb60-spl.c | 20 + > > board/qi/qi_lb60/usbboot.S | 838 > > 2 files changed, 858 > > insertions(+) > > create mode 100644 board/qi/qi_lb60/usbboot.S > > > [...] > > UGH. Simply ... UGH. > > Can that assembler blob not be rewritten into C ? > > 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 v5 09/16] arm: Add control over cachability of memory regions
Hi Simon, No comment on the patch itself except for one general question: On Mon, 8 Oct 2012 14:42:29 -0700, Simon Glass wrote: > Add support for adjusting the cachability of an L1 section by updating > the MMU. The mmu_set_region_dcache() function allows drivers to make > these changes after the MMU is set up. Can you just reformulate this a bit? "L1" is not necessary about cache (there can be for instance TCM, frequently (if not correctly) called L1 RAM where I work, for the obvious reason that they are accessed at the same level/layer as the L1 cache. Also, off, writethrough and copyback are "cache behaviors" in ARM parlance, not "cachability". Therefore I would prefer something like "Add support for adjusting the L1 cache behavior by updating the MMU configuration. The mmu_set_region_dcache_behavior() function allows drivers to make these changes after the MMU is set up." (note the suggestion includes slightly renaming the function) Thanks in advance for considering this suggestion. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-tegra/master and /next have been updated and uploaded to denx.de
Hi Stephen, On Fri, 12 Oct 2012 15:30:42 -0600, Stephen Warren wrote: > On 10/12/2012 03:26 PM, Tom Warren wrote: > > Folks, > > > > u-boot-tegra/next has been updated with new patches from Lucas, Marc, and > > Stephen, rebased against u-boot-arm, and pushed to denx.de. > > u-boot-tegra/next right now is based on u-boot-arm/master, but includes > patches that are both: > > a) Already in u-boot-arm/next (but *not* u-boot-arm/master since master > is for the current release and next is for the next release) > > b) New. > > I think you want to create (rebase) u-boot-tegra/next based on > u-boot-arm/next, and drop the following patches (they would rebase out > anyway if you just rebase onto u-boot-arm/next): > > c699a7b tegra: nand: add board pinmux > c7560dd tegra: clean up board include hell > 1ddfbf3 tegra: add funcmux entry for NAND attached to KBC > 8d49ab8 tegra20: rework UART GPIO handling > 5904a2e tegra20: add clock_set_pllout function > 0e0eb51 tegra20: complete periph_id enum > 7811a6d tegra: enable CONFIG_CMD_PART > 517ef6d Tegra20: Move some include files to arch-tegra for sharing with > Tegra30 > 1367676 Tegra20: Move some code files to common directories for upcoming > Tegra30 patches. > 7d92ef4 tegra: Rename Medcom to Medcom-Wide > c527d55 tegra: Update Avionic Design vendor prefix I've rebased arm/next onto u-boot/next as they are now in sync -- whatever was on my next is now on master or in u-boot/next, with the addition of the lh7a40x removal. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] File placement in Soc / board dirs and make issues (was: [PATCH V3 17/32] imximage.cfg: run files through C preprocessor)
Hi Tom, On Thu, 11 Oct 2012 16:15:02 -0700, Tom Rini wrote: > On Fri, Oct 12, 2012 at 12:27:09AM +0200, stefano babic wrote: > > [snip] > > One reason to move into the board directory is that there was a decision > > to move rules related to only one arch or SOC where they belong to, that > > is in the corresponding arch/ or board/ directory. > > I'll admit that maybe my make-fu is off, but that idea doesn't work, at > least for SPL. So I'd really like someone to make that work first. Tom, can you be more specific than 'it doesn't work'? :) Seriously, though, I'm interested in understand what the make issue is there, because I am indeed a proponent of putting files where they belong to, so if help is needed there, I would try to. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush
Hi Marek,
First, a (long) preamble with some general considerations:
A. This patch does not fix an actual issues; it is a prospective patch,
modifying code which so far has not malfunctioned, or at least has not
been reported to malfunction.
B. My comments on the patch below are based on the general consideration
that the effect of a memory clobber is to contrain the reordering of
statements around the clobbering. For the sake of simplicity -- and
serenity :) -- my comments are also made under the assumption that the
clobber prevents any access (volatile or not, write or read) from
crossing it.
C. Another general comment is that adding clobber to instructions other
than barriers is IMO not a good thing and isb() should be used instead,
for two reasons:
1) it mixes an implicit secondary purpose into a statement written for
another, explicit purpose; this can drown the implicit purpose into
oblivion, when it should actually be emphasized, which is the goal and
effect of isb();
2) it mixes the ends and the means. The end of your patch is to
put instruction barriers between statements so that their relative
order is preserved during optimization; adding "memory" to the clobber
list of an asm instruction that happens to be one of the statements is
a means, but so is isb() with the added benefit that using isb() allows
architectures to use whatever means (memory clobber, specialized
instruction, other) are best for the arch.
D. My comments on the patch below are based on the current source code.
One could argue that this may change if the function becomes inline.
While this is true, I do not consider this right now because 1) the
function is a strong replacement of a weak symbol, which AFAIU is not
compatible with inlining, and 2) this patch is against the current
tree, not a potential future tree. If/when a patch arrives to make the
function inline, we'll consider the implications and how to solve them
*then*.
Ther may be another impact on this function, namely LTO; but --again,
AFAIU -- LTO does not rewrite the inside of functions; it only
optimizes between functions. And again, we'll deal with LTO if/when
patches for LTO get submitted.
... and, there may be future changes not imagined here that will break
things. We'll deal with them then.
On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut wrote:
> Add memory barrier to cache invalidate and flush calls.
>
> Signed-off-by: Marek Vasut
> CC: Albert Aribaud
> Cc: Fabio Estevam
> Cc: Otavio Salvador
> Cc: Stefano Babic
> ---
> arch/arm/cpu/arm926ejs/cache.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c
> index 2740ad7..1c67608 100644
> --- a/arch/arm/cpu/arm926ejs/cache.c
> +++ b/arch/arm/cpu/arm926ejs/cache.c
> @@ -30,7 +30,7 @@
>
> void invalidate_dcache_all(void)
> {
> - asm volatile("mcr p15, 0, %0, c7, c6, 0\n" : : "r"(0));
> + asm volatile("mcr p15, 0, %0, c7, c6, 0\n" : : "r"(0) : "memory");
> }
This one is useless since there are no accesses in the function to be
reordered.
> void flush_dcache_all(void)
> @@ -67,7 +67,8 @@ void invalidate_dcache_range(unsigned long start, unsigned
> long stop)
> return;
>
> while (start < stop) {
> - asm volatile("mcr p15, 0, %0, c7, c6, 1\n" : : "r"(start));
> + asm volatile("mcr p15, 0, %0, c7, c6, 1\n"
> + : : "r"(start) : "memory");
> start += CONFIG_SYS_CACHELINE_SIZE;
> }
> }
This one is useless too, as the only access it could constrain is the
one affecting start, which is also affected by the would-be-clobbered
statement (and the enclosing while's condition, thus already preventing
the compiler from reordering.
> @@ -78,11 +79,12 @@ void flush_dcache_range(unsigned long start, unsigned
> long stop)
> return;
>
> while (start < stop) {
> - asm volatile("mcr p15, 0, %0, c7, c14, 1\n" : : "r"(start));
> + asm volatile("mcr p15, 0, %0, c7, c14, 1\n"
> + : : "r"(start) : "memory");
> start += CONFIG_SYS_CACHELINE_SIZE;
> }
Here again, the only access the clobber could constrain is the one
affecting start, which is also affected by the would-be-clobbered
statement (and the enclosing while's condition, thus already preventing
the compiler from reordering.
> - asm volatile("mcr p15, 0, %0, c7, c10, 4\n" : : "r"(0));
> + asm volatile("mcr p15, 0, %0, c7, c10, 4\n" : : "r"(0) : "memory");
> }
Now this asm statement might potentially move around as it does not have
input or output dependencies that the compiler could possibly use to
assess ordering constraints. I would thus suggest replacing the memory
clobber with an 'isb();' placed on the line before the asm volatile,
for the reasons indicated in part C of my (long) preamble above.
> void flush_cache(unsigned long start, unsigned lo
