Bug#441933: sometimes calculations are really off

I don't use that utility anymore. I don't even remember if this was happening often or not. You can close the issue, if you like. lun., 28 feb. 2022, 01:52 Paul Wise a scris: > On Wed, 12 Sep 2007 02:14:22 +0300 Eddy Petrișor wrote: > > > When copying a 700MB file from an USB

Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

package grub-efi-amd64 found 984760 2.02+dfsg1-20+deb10u4 thanks Hello, I also had this issue when upgrading from stretch to buster. For me the BIOS allowed be to select the EFI image to boot, so I was able to boot into the system that way, then the fix was to: 1) run again update-grub2 and 2)

Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

package grub-efi-amd64 found 984760 2.02+dfsg1-20+deb10u4 thanks Hello, I also had this issue when upgrading from stretch to buster. For me the BIOS allowed be to select the EFI image to boot, so I was able to boot into the system that way, then the fix was to: 1) run again update-grub2 and 2)

Re: Rust now available on 14 Debian architectures

În vin., 2 nov. 2018, 18:49 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de a scris: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi! > > This week we managed to bootstrap the Rust compiler for four more Debian > architectures [1]. This means, that the Rust compiler is now

Re: Compacting link-rules

Will do. Eddy vin., 19 oct. 2018, 16:52 Paul Smith a scris: > On Fri, 2018-10-19 at 09:26 +0300, Eddy Petrișor wrote: > > I have a similar issue, but in my case I used explicit pattern rules, > > vpath and added compiler generated .d files to make sure the object > >

Re: Compacting link-rules

joi, 18 oct. 2018, 18:56 Paul Smith a scris: > On Thu, 2018-10-18 at 17:40 +0200, Gisle Vanem wrote: > >bin/%.exe: $($(@F)_OBJ) $(LIBS) > >$(call link_EXE, $@, $^) > > This cannot work because automatic variables like $@, etc. are only > valid _inside a recipe_. They are not set

Re: use of math.h / libmath discouraged?

joi, 26 iul. 2018, 19:42 Brian Vandenberg a scris: > Wouldn't profiling information help? >> See details and link to code with 3.81 that does this at: >> > > Yes, it would. I was unaware of that issue. > > It looks as though that feature never made it in [unfortunately]. If it > were added,

Re: use of math.h / libmath discouraged?

Eddy mie., 25 iul. 2018, 23:26 Brian Vandenberg a scris: > However, I'm not sure that this function is sufficiently generic to be >> > added as a built-in function. Can you provide use-cases for it? >> > > I suppose that depends on the definition of "sufficiently generic". The > two

Re: [RFC PATCH v3 2/2] t7406: add test for non-default branch in submodule

2018-04-05 0:41 GMT+03:00 Stefan Beller <sbel...@google.com>: > On Wed, Apr 4, 2018 at 1:37 PM, Eddy Petrișor <eddy.petri...@gmail.com> wrote: > >>> you plan to later submit as one patch including both the change as well as >>> the test. >> >> Ye

Re: [RFC PATCH v4 1/9] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

-9 have the 'fixup' prefix. > I think the end result looks good, but that is best reviewed as one > piece instead of 9 patches. -- Eddy Petrișor

[RFC PATCH v4 6/9] fixup:t7406:don't call init after add, is redundant

From: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- t/t7406-submodule-update.sh | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index c5b412c46..3299

[RFC PATCH v4 4/9] fixup:t7404:use 'git -C' instead of cd .. && git

From: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- t/t7406-submodule-update.sh | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index 7fb370991..974f

[RFC PATCH v4 5/9] fixup:t7406:cleanup chained submodules after test is done

From: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- t/t7406-submodule-update.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index 974f949df..c5b4

[RFC PATCH v4 8/9] fixup:t7406:use super_w instead of the existing super

From: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- t/t7406-submodule-update.sh | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index 18328be7

[RFC PATCH v4 2/9] t7406: add test for non-default branch in submodule

From: Eddy Petrișor <eddy.petri...@gmail.com> If a submodule uses a non-default branch and the branch info is versioned, on submodule update --recursive --init the correct branch should be checked out. Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- t/t7406-submodule-up

[RFC PATCH v4 9/9] fixup:t7406:change branches in submodules after the link is done

From: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- t/t7406-submodule-update.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index f44872143..68c2

[RFC PATCH v4 1/9] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

From: Eddy Petrișor <eddy.petri...@gmail.com> There are projects such as llvm/clang which use several repositories, and they might be forked for providing support for various features such as adding Redox awareness to the toolchain. This typically means the superproject will use another

[RFC PATCH v4 3/9] fixup:t7406: use test_commit instead of echo/add/commit as suggested by Stefan Beller

From: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- t/t7406-submodule-update.sh | 15 +++ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh ind

[RFC PATCH v4 7/9] fixup:t7406:supr5 commit is done before submodules chaining

From: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- t/t7406-submodule-update.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index 32995e272..1832

Re: [RFC PATCH v3 2/2] t7406: add test for non-default branch in submodule

2018-04-04 21:36 GMT+03:00 Stefan Beller <sbel...@google.com>: > On Tue, Apr 3, 2018 at 3:26 PM, Eddy Petrișor <eddy.petri...@gmail.com> wrote: >> Notes: >> I am aware this test is not probably the best one and maybe I >> should have first one test that doe

Re: [RFC PATCH v3 2/2] t7406: add test for non-default branch in submodule

. Help would be appreciated. 2018-04-04 1:20 GMT+03:00 Eddy Petrișor <eddy.petri...@codeaurora.org>: > From: Eddy Petrișor <eddy.petri...@gmail.com> > > If a submodule uses a non-default branch and the branch info is versioned, on > submodule update --recursive --init t

[RFC PATCH v3 1/2] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

From: Eddy Petrișor <eddy.petri...@gmail.com> There are projects such as llvm/clang which use several repositories, and they might be forked for providing support for various features such as adding Redox awareness to the toolchain. This typically means the superproject will use another

[RFC PATCH v3 2/2] t7406: add test for non-default branch in submodule

From: Eddy Petrișor <eddy.petri...@gmail.com> If a submodule uses a non-default branch and the branch info is versioned, on submodule update --recursive --init the correct branch should be checked out. Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- t/t7406-submodule-up

Re: [RFC PATCH v2] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

(+list) 2018-03-30 1:55 GMT+03:00 <eddy.petri...@gmail.com>: > From: Eddy Petrișor <eddy.petri...@gmail.com> > > There are projects such as llvm/clang which use several repositories, and they > might be forked for providing support for various features such as add

Fwd: [RFC PATCH] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

mar., 27 mar. 2018, 02:07 Stefan Beller <sbel...@google.com> a scris: > > [snipped the cc list as well] > > On Tue, Mar 6, 2018 at 12:06 PM Eddy Petrișor <eddy.petri...@gmail.com> > wrote: > > > Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> > &

Is context/directory sensitive config possible or even a god idea?

ted strategy is used, and rebase is the preferred behaviour for pull, instead of merge) -- Eddy Petrișor

Re: [RFC PATCH] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

2018-03-08 21:29 GMT+02:00 Eddy Petrișor <eddy.petri...@gmail.com>: > 2018-03-06 22:21 GMT+02:00 Jonathan Nieder <jrnie...@gmail.com>: >> >> (cc list snipped) >> Hi, >> >> Eddy Petrișor wrote: >> >> > Cc: [a lot of people] >> >&g

Re: [RFC PATCH] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

2018-03-06 22:21 GMT+02:00 Jonathan Nieder <jrnie...@gmail.com>: > > (cc list snipped) > Hi, > > Eddy Petrișor wrote: > > > Cc: [a lot of people] > > Can you say a little about how this cc list was created? E.g. should > "git send-email" g

Re: [U-Boot] [PATCH V2 2/2] Remove config_distro_defaults.h

Eddy Petrișor Pe 6 feb. 2018 15:49, "Adam Ford" <aford...@gmail.com> a scris: With the contents of config_distro_defaults.h migrated to Kconfig, we can remove this header file completely --- a/include/configs/cm_fx6.h +++ b/include/configs/cm_fx6.h @@ -14,7 +14,7 @@ #inclu

Re: [toolchain] lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'?

Pe 5 nov. 2017 12:57 AM, "Gerald Pfeifer" <ger...@pfeifer.com> a scris: On Sun, 29 Oct 2017, Eddy Petrișor wrote: > Yep --and it is even more complicated: gcc vs. clang are sometimes > different for the target listed. . . > > For example -m32 for amd64 changes t

[tup] Falsehoods programmers believe about build systems: pozorvlak

How many of these are applicable to Tup? http://pozorvlak.livejournal.com/174763.html Please take this as constructive criticism. Eddy Petrișor -- -- tup-users mailing list email: tup-users@googlegroups.com unsubscribe: tup-users+unsubscr...@googlegroups.com options: http://groups.google.com

Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'?

2017-10-29 9:51 GMT+02:00 Eddy Petrișor <eddy.petri...@gmail.com>: > Various linux distributions > > patch uname and its -p code (for > example). Even for the same kernel > being in use, giving different > textual results. -m seemed more > stable in my limited test

Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'?

Pe 28 oct. 2017 5:31 PM, "Mark Millard" <mar...@dsl-only.net> a scris: On 2017-Oct-28, at 4:11 AM, Dimitry Andric wrote: > On 27 Oct 2017, at 08:23, Eddy Petrișor wrote: >> >> I am trying to make the FreeBSD code base build from a Linux host and >> foun

Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'?

2017-10-27 11:19 GMT+03:00 Mark Millard <mar...@dsl-only.net>: > On 2017-Oct-26, at 11:23 PM, Eddy Petrișor <eddy.petri...@gmail.com> wrote: > >> I am trying to make the FreeBSD code base build from a Linux host and >> found this bit which defines BUILD_TRIPLE in

lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'?

ENDOR}-${OS_VERSION}${TARGET_ABI} +HOST_CC_DUMPMACHINE!=cc -dumpmachine +BUILD_TRIPLE?=${HOST_CC_DUMPMACHINE} -- Eddy Petrișor ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To uns

Re: Converting make rules into other file formats

Pe 15 oct. 2017 12:57 PM, "SF Markus Elfring" a scris: > Are the chances better to extend the tool “remake” then? … > Probably. Can it be that our software development resources are also too limited for mentioned tasks? I don't know. > My intention was to

Re: Converting make rules into other file formats

ur build and execution framework to be able to easily identify bottlenecks. The dependency graphing feature was also present in the branches I was planning to upstream since it allowed me to check if the dependencies in our build system were incorrect from a logical PoV (started with a sequential

Re: Converting make rules into other file formats

simple formatting of info is too much for make to do. Here is the bug report: https://savannah.gnu.org/bugs/?40639 Eddy Petrișor Pe 14 oct. 2017 10:47 PM, <th...@vmware.com> a scris: > SF Markus Elfring writes: > > > A Makefile is basically a human-readable text file

Re: [tup] tugignore or other means to ignore (intermediate) output files

Pe 23 mai 2017 7:14 PM, "Mike Shal" <mar...@gmail.com> a scris: On Tue, May 23, 2017 at 11:36 AM, Eddy Petrișor <eddy.petri...@gmail.com> wrote: > The problem I had was on such a compiler where the temporary files had > totally random filenames. > > This was a

Re: [tup] tugignore or other means to ignore (intermediate) output files

, a file pattern or a directory. The problem I had was on such a compiler where the temporary files had totally random filenames. This was a no go for me. Are you in a similar situation? May I ask which compiler you target? This would for example allow to ignore .pdb and .cache files generates by V

Re: [tup] Command runs in terminal but not in tup

rc prints an error and tup shows it. I can also get rc to print all of the server's symbols from within tup. I'm not sure what else to try or how to figure out why it won't work. Any ideas? Eddy Petrișor -- -- tup-users mailing list email: tup-users@googlegroups.com unsubscribe: tup-users+

Re: [U-Boot] [PATCH v2 2/2] armv8: s32v234: Introduce basic support for s32v234evb

on't know who to contact, please send me an email on my work email (same as my email in this thread, but @nxp.com) and we can clear up the details without spamming the community. > > Thanks > > > > Mohamed El-Sharkawy Eddy Petrișor > Professor > > Purdue School of En

Re: [U-Boot] [U-Boot, v6, 2/2] armv8: s32v234: Introduce basic support for s32v234evb

Pe 19 iun. 2016 4:09 p.m., "Tom Rini" <tr...@konsulko.com> a scris: > > On Sun, Jun 05, 2016 at 03:43:00AM +0300, Eddy Petrisor wrote: > > > From: Eddy Petrișor <eddy.petri...@gmail.com> > > > > Add initial support for NXP's S32V234 SoC and S32V234E

Re: [U-Boot] [U-Boot, v6, 1/2] serial: Introduce linflex uart support

ed on some NXP automotive SoCs part of the former > > Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> > > Applied to u-boot/master, thanks! Thanks, Tom. Eddy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 0/2] Initial support for s32v234

Pe 5 iun. 2016 3:52 a.m., "Fabio Estevam" <feste...@gmail.com> a scris: > > On Sat, Jun 4, 2016 at 8:59 PM, Eddy Petrișor <eddy.petri...@gmail.com> wrote: > > > The board has been having support in our vendor branch a lot before > > the Freescale - N

[U-Boot] [PATCH v6 2/2] armv8: s32v234: Introduce basic support for s32v234evb

From: Eddy Petrișor <eddy.petri...@gmail.com> Add initial support for NXP's S32V234 SoC and S32V234EVB board. The S32V230 family is designed to support computation-intensive applications for image processing. The S32V234, as part of the S32V230 family, is a high-performance automotive pro

[U-Boot] [PATCH v6 0/2] Initial support for s32v234

Sixth version. It seems I reintroduced the typo ficed in v4 again in v5. I was testing on an unsquashed equivalent branch, so I missed the typo reintroduction. Sorry for this. Eddy Petrișor (1): armv8: s32v234: Introduce basic support for s32v234evb Stoica Cosmin-Stefan (1): serial

[U-Boot] [PATCH v6 1/2] serial: Introduce linflex uart support

tefan.sto...@freescale.com> Original-signed-off-by: Chircu Bogdan <bogdan.chi...@freescale.com> Original-signed-off-by: Depons Eric <eric.dep...@freescale.com> Original-signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.c

Re: [U-Boot] [PATCH v5 0/2] Initial support for s32v234

2016-06-05 1:23 GMT+03:00 Fabio Estevam <feste...@gmail.com>: > On Sat, Jun 4, 2016 at 4:18 PM, Eddy Petrișor <eddy.petri...@nxp.com> wrote: > >> board/freescale/s32v234evb/Kconfig | 23 ++ > > What about placing the files under board/nxp instead? The

[U-Boot] [PATCH v5 0/2] Initial support for s32v234

Fifth version of the s32v234evb initial support. This version adds missing DEBUG_UART_FUNCS statement in linflex driver. Eddy Petrișor (1): armv8: s32v234: Introduce basic support for s32v234evb Stoica Cosmin-Stefan (1): serial: Introduce linflex uart support arch/arm/Kconfig

[U-Boot] [PATCH v5 2/2] armv8: s32v234: Introduce basic support for s32v234evb

From: Eddy Petrișor <eddy.petri...@gmail.com> Add initial support for NXP's S32V234 SoC and S32V234EVB board. The S32V230 family is designed to support computation-intensive applications for image processing. The S32V234, as part of the S32V230 family, is a high-performance automotive pro

[U-Boot] [PATCH v5 1/2] serial: Introduce linflex uart support

tefan.sto...@freescale.com> Original-signed-off-by: Chircu Bogdan <bogdan.chi...@freescale.com> Original-signed-off-by: Depons Eric <eric.dep...@freescale.com> Original-signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.c

[U-Boot] [PATCH v4 0/2] Initial support for s32v234

Changes in v4: Corrected a typo in the linflex driver: _debUG_uart_init -> _debug_uart_init Eddy Petrișor (1): armv8: s32v234: Introduce basic support for s32v234evb Stoica Cosmin-Stefan (1): serial: Introduce linflex uart support arch/arm/Kconfig|

[U-Boot] [PATCH v4 2/2] armv8: s32v234: Introduce basic support for s32v234evb

applications in the area of vision and sensor fusion. Code originally writen by: Original-signed-off-by: Stoica Cosmin-Stefan <cosminstefan.sto...@freescale.com> Original-signed-off-by: Mihaela Martinas <mihaela.marti...@freescale.com> Original-signed-off-by: Eddy Petrișor <eddy.pet

[U-Boot] [PATCH v4 1/2] serial: Introduce linflex uart support

tefan.sto...@freescale.com> Original-signed-off-by: Chircu Bogdan <bogdan.chi...@freescale.com> Original-signed-off-by: Depons Eric <eric.dep...@freescale.com> Original-signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.c

[U-Boot] [PATCH v3 0/2] Initial support for S32V234 - version 3

Hello, Here are the reworked patches (3rd version) for the initial s32v234evb support. Eddy Petrișor (1): armv8: s32v234: Introduce basic support for s32v234evb Stoica Cosmin-Stefan (1): serial: Introduce linflex uart support arch/arm/Kconfig| 5 + arch

[U-Boot] [PATCH v3 1/2] serial: Introduce linflex uart support

tefan.sto...@freescale.com> Original-signed-off-by: Chircu Bogdan <bogdan.chi...@freescale.com> Original-signed-off-by: Depons Eric <eric.dep...@freescale.com> Original-signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.c

[U-Boot] [PATCH v3 2/2] armv8: s32v234: Introduce basic support for s32v234evb

applications in the area of vision and sensor fusion. Code originally writen by: Original-signed-off-by: Stoica Cosmin-Stefan <cosminstefan.sto...@freescale.com> Original-signed-off-by: Mihaela Martinas <mihaela.marti...@freescale.com> Original-signed-off-by: Eddy Petrișor <eddy.pet

Re: [U-Boot] [PATCH v2 1/2] serial: Introduce linflex uart support

Pe 7 mai 2016 5:56 p.m., "Bin Meng" <bmeng...@gmail.com> a scris: > > +Simon > > Hi Eddy, > > On Thu, Apr 28, 2016 at 6:07 AM, Eddy Petrișor <eddy.petri...@nxp.com> wrote: > > From: Stoica Cosmin-Stefan <cosminstefan.sto...@freescale.com>

Re: [U-Boot] [PATCH v2 2/2] armv8: s32v234: Introduce basic support for s32v234evb

Pe 7 mai 2016 7:22 p.m., "Alexander Graf" <ag...@suse.de> a scris: > > > On Apr 28, 2016, at 12:07 AM, Eddy Petrișor <eddy.petri...@nxp.com> wrote: > > > From: Eddy Petrișor <eddy.petri...@gmail.com> > > […] > > > +#define CONFIG_CMD_E

[U-Boot] [PATCH 0/2] Initial support for S32V234 - version 2

Here is the second version of the proposed inital support for S32V234. Please excuse the delay, I was kept busy by some unplanned events. Tom: I did not spllit the MMU definitions into a separate file since they are not used anywhere else yet. Eddy Petrișor (1): armv8: s32v234: Introduce basic

[U-Boot] [PATCH v2 0/2] Initial S32V234 support - version 2 (with notes now)

Here are the reworked patches for initial S32V234 support, including the git notes in both patches. Sorry for the repost. Eddy Petrișor (1): armv8: s32v234: Introduce basic support for s32v234evb Stoica Cosmin-Stefan (1): serial: Introduce linflex uart support arch/arm/Kconfig

[U-Boot] [PATCH v2 2/2] armv8: s32v234: Introduce basic support for s32v234evb

From: Eddy Petrișor <eddy.petri...@gmail.com> Add initial support for NXP's S32V234 SoC and S32V234EVB board. The S32V230 family is designed to support computation-intensive applications for image processing. The S32V234, as part of the S32V230 family, is a high-performance automotive pro

[U-Boot] [PATCH v2 1/2] serial: Introduce linflex uart support

tefan.sto...@freescale.com> Original-signed-off-by: Chircu Bogdan <bogdan.chi...@freescale.com> Original-signed-off-by: Depons Eric <eric.dep...@freescale.com> Original-signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.c

[U-Boot] [PATCH 2/2] armv8: s32v234: Introduce basic support for s32v234evb

From: Eddy Petrișor <eddy.petri...@gmail.com> Add initial support for NXP's S32V234 SoC and S32V234EVB board. The S32V230 family is designed to support computation-intensive applications for image processing. The S32V234, as part of the S32V230 family, is a high-performance automotive pro

[U-Boot] [PATCH 1/2] serial: Introduce linflex uart support

tefan.sto...@freescale.com> Original-signed-off-by: Chircu Bogdan <bogdan.chi...@freescale.com> Original-signed-off-by: Depons Eric <eric.dep...@freescale.com> Original-signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.

Re: [U-Boot] [PATCH 2/2] armv8: s32v234: Introduce basic support for s32v234evb

Pe 19 apr. 2016 6:53 p.m., "Tom Rini" <tr...@konsulko.com> a scris: > > On Sun, Apr 03, 2016 at 03:10:06AM +0300, Eddy Petrișor wrote: > > > Add initial support for NXP's S32V234 SoC and S32V234EVB board. > > > > The S32V230 family is designed to

Re: [U-Boot] [PATCH 1/2] serial: Introduce linflex uart support

(- Eric, he left the company a little after he contributed to the linflex driver, so he's email is no longer valid) Pe 4 apr. 2016 6:22 a.m., "Bin Meng" <bmeng...@gmail.com> a scris: > > On Sun, Apr 3, 2016 at 8:10 AM, Eddy Petrișor <eddy.petri...@gmail.com> wrote: &g

[U-Boot] [PATCH 1/2] serial: Introduce linflex uart support

scale.com> Signed-off-by: Chircu Bogdan <bogdan.chi...@freescale.com> Signed-off-by: Depons Eric <eric.dep...@freescale.com> Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- drivers/serial/Makefile | 1 + drivers/ser

Re: [U-Boot] [PATCH] common/memsize.c: fix endless loop when saving

Pe 10 feb. 2016 8:26 a.m., "Hannes Schmelzer" <han...@schmelzer.or.at> a scris: > > On 02/09/2016 06:55 PM, Eddy Petrișor wrote: >> >> 2016-02-09 19:41 GMT+02:00 Eddy Petrișor <eddy.petri...@nxp.com>: >> Hannes, can you confirm that with this patc

Re: [U-Boot] [PATCH] common/memsize.c: fix endless loop when saving

Pe 10 feb. 2016 7:58 p.m., "Hannes Schmelzer" <han...@schmelzer.or.at> a scris: > > > On 2016-02-10 18:30, Eddy Petrișor wrote: >> Taking into account the first version was reverted, would you be willing to test a reworked patch targeting v2016.05, (when I have i

Re: [U-Boot] Regarding revert of "Simplify RAM size detection" patch

Pe 10 feb. 2016 8:40 p.m., "Sam Protsenko" a scris: > > Hi guys, Hi Sam, > I see that "Simplify RAM size detection" patch is reverted now. It was > breaking boot on DRA7XX EVM as well. But I think I found the actual > bug in that patch. This line (from patch): > > -

Re: [U-Boot] [PATCH] Revert "common/memsize.c: Simplify RAM size detection"

2016-02-10 10:20 GMT+02:00 Hans de Goede <hdego...@redhat.com>: > Hi, > > On 10-02-16 07:11, Eddy Petrișor wrote: >> >> Hi Hans, >> >> I sent a fixup patch yesterday (I managed somehow to send an outdated >> patch), > > > Ah I did not notice th

Re: [U-Boot] [PATCHv2] common/memsize.c: Simplify RAM size detection

2016-02-09 12:14 GMT+02:00 Hannes Schmelzer <han...@schmelzer.or.at>: > > On 02.02.2016 21:15, Eddy Petrișor wrote: >> >> The case of memory of size 0 is not that different from a memory of any >> other >> size, so we remove the duplicate code

[U-Boot] [PATCH] common/memsize.c: fix endless loop when saving

When cnt reaches 0, any shift operation will keep cnt=0, so the condition `cnt >= 0` doesn't make sense. To fix this endless loop, we drop the useless condition and simply break the loop when cnt reaches 0. Signed-off-by: Eddy Petrișor <eddy.petri...@nxp.com> --- common/memsize.c |

Re: [U-Boot] [PATCH] Revert "common/memsize.c: Simplify RAM size detection"

Hi Hans, I sent a fixup patch yesterday (I managed somehow to send an outdated patch), did you try the fixup patch? http://lists.denx.de/pipermail/u-boot/2016-February/245080.html Pe 9 feb. 2016 11:38 p.m., "Hans de Goede" a scris: > This commit breaks bootup on sunxi

Re: [U-Boot] [PATCH] common/memsize.c: fix endless loop when saving

2016-02-09 19:41 GMT+02:00 Eddy Petrișor <eddy.petri...@nxp.com>: > When cnt reaches 0, any shift operation will keep cnt=0, so the condition > `cnt >= 0` doesn't make sense. > > To fix this endless loop, we drop the useless condition and simply break the > loop when cnt

Re: [U-Boot] [U-Boot, PATCHv2] common/memsize.c: Simplify RAM size detection

2016-02-08 22:49 GMT+02:00 Tom Rini <tr...@konsulko.com>: > On Tue, Feb 02, 2016 at 10:15:28PM +0200, Eddy Petrișor wrote: > >> The case of memory of size 0 is not that different from a memory of any other >> size, so we remove the duplicate code and treat th

[U-Boot] Fwd: Patman use (was: [PATCHv2] common/memsize.c: Simplify RAM size detection)

(Sorry Albert for the dup, I accidentally sent the reply only to you.) -- Forwarded message -- From: Eddy Petrișor <eddy.petri...@gmail.com> Date: 2016-02-05 9:06 GMT+02:00 Subject: Re: Patman use (was: [U-Boot] [PATCHv2] common/memsize.c: Simplify RAM size detection) To:

[U-Boot] [PATCHv2] common/memsize.c: Simplify RAM size detection

The case of memory of size 0 is not that different from a memory of any other size, so we remove the duplicate code and treat the small differences when it is the case. Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- v2: Removed patman stuff from commit message common/memsize.

Re: [U-Boot] [PATCHv2] common/memsize.c: Simplify RAM size detection

2016-02-03 15:38 GMT+02:00 Albert ARIBAUD <albert.u.b...@aribaud.net>: > Hello Eddy, > > On Tue, 2 Feb 2016 22:15:28 +0200, Eddy Petrișor > <eddy.petri...@gmail.com> wrote: [..] >> v2: Removed patman stuff from commit message > > Sorry for asking, but

[U-Boot] [PATCH] common/memsize.c: Simplify RAM size detection

The case of memory of size 0 is not that different from a memory of any other size, so we remove the duplicate code and treat the small differences when it is the case. Series-to: u-boot Signed-off-by: Eddy Petrișor <eddy.petri...@gmail.com> --- common/memsize.

Re: [Talk-ro] Import toate bancile din Romania ?

Pe 21 apr. 2015 15:41, Anatolie Golovco golovcoanato...@gmail.com a scris: eu folosesc urmatorul workflow: 1. Scoti Romania de pe http://download.geofabrik.de/europe/romania-latest.osm.pbf 2. Filtrezi tagurile care seamana cu ce vrei tu sa importezi, si le scoti in un fisier .osm (folosind

Re: [Talk-ro] Targu Mures

Pe 5 mar. 2015 19:09, Gabriel Sebastian Moise gabrielsebastianmo...@gmail.com a scris: Eddy, nu prea inteleg cam la ce te gandesti ! Eu cred că e destul de clar, OSM e un proiect apolitic, iar discuția trebuie să fie tehnică și vidă de naționalism, fie el maghiar ori român. Cred că e clară

Re: [Talk-ro] Targu Mures

, corecțiile acestor greșeli și acțiunile lui Gergely, adică aproximativ cam ce ai scris mai inainte citatul de mai sus. On 05.03.2015 18:36, Eddy Petrișor wrote: Pe 2 mar. 2015 20:15, Ciprian ARSENIE cipr...@carsenie.ro a scris: Sunt lamurit cu astia din mures unde intri in ceva magazin mai mic de

Re: [Talk-ro] Targu Mures

Pe 2 mar. 2015 20:15, Ciprian ARSENIE cipr...@carsenie.ro a scris: Sunt lamurit cu astia din mures unde intri in ceva magazin mai mic de la coltul strazii si cand ii vorbesti pe romaneste se uita la tine ca broasca la bariera asa ca greseala negreseala Cu ce e asta relevant pentru

Re: [Talk-ro] Talk-ro Digest, Vol 71, Issue 16

Pe 2 mar. 2015 19:29, Gergely Bartha gergely_bar...@yahoo.com a scris: Nu e o porcarie ce au facut Sud Tirolezii. Intr-o regiune multiculturala trebuie sa fie normal afisarea strazilor in mai multe limbi. Este o porcarie ce este acum in Ardeal, lucrul asta bcu romana sa fie singura limba...Cum

Bug#685832: xcfe4-sensors-plugin relies on a setuid hddtemp and recommends to setuid it

: pn xsensors none -- no debconf information -- Eddy Petrișor diff -Nru xfce4-sensors-plugin-1.2.5/debian/changelog xfce4-sensors-plugin-1.2.5/debian/changelog --- xfce4-sensors-plugin-1.2.5/debian/changelog 2013-05-26 14:18:23.0 +0300 +++ xfce4-sensors-plugin-1.2.5/debian/changelog

[Pkg-xfce-devel] Bug#685832: xcfe4-sensors-plugin relies on a setuid hddtemp and recommends to setuid it

: pn xsensors none -- no debconf information -- Eddy Petrișor diff -Nru xfce4-sensors-plugin-1.2.5/debian/changelog xfce4-sensors-plugin-1.2.5/debian/changelog --- xfce4-sensors-plugin-1.2.5/debian/changelog 2013-05-26 14:18:23.0 +0300 +++ xfce4-sensors-plugin-1.2.5/debian/changelog

Re: [Talk-ro] Dorinta import PUG Dragasani

Salut, Am un sigur comentariu legat de limbaj, nu de fond. Aş recomanda să mai introduci câte un vă rog și câte un mulțumesc în mesajele tale și să pui mai devreme avantajele lor. Ar fi păcat să dai de câte un berbec care să zică 'ia uite ce tupeu are și asta, ia mai dă-l în origini că nu-i dau

Re: [Talk-ro] sorein

Pe 15.07.2014 03:29, Serge Wroclawski emac...@gmail.com a scris: Dear Romanian Community, I appologize in advance if this mail sounds strange. I do not speak Romanian and I am using a translation program to translate this email (the original is at the bottom of this mail). After a long

Re: [Talk-ro] Mapping Party OpenStreetMap in Bucuresti - 17-18 mai 2014

Pe 13.05.2014 23:59, Badita Florin baditaflo...@gmail.com a scris: În weekendul 17-18 Mai 2014, în Bucuresti, un grup de oameni entuziaști și pasionați de OpenStreetMap își vor aduce aportul în proiectul global de cartografiere colaborativă, ce a determinat dezvoltarea celei mai dinamice hărți

Bug#459371: Caps lock is compose/control - caps led wrong

2014-04-01 22:26 GMT+03:00 althaser altha...@gmail.com: Hey, this is an old bug. Could you please still reproduce this issue with newer gnome-control-center version like 1:3.4.3.1-2 or 1:3.8.3-4 ? Sorry, I am no longer a GNOME user. cheers, althaser -- Eddy Petrișor

Bug#470900: pulseaudio: switching forth the sink - ok, switch back - hangs client(s)

Pe 04.04.2014 22:42, Felipe Sateler fsate...@debian.org a scris: Hi, Eddy Petrișor wrote: Sjoerd Simons a scris: On Tue, Apr 08, 2008 at 09:32:59AM +0300, Eddy Petri??or wrote: Could it have to do with the fact the remote sink was running etch's pulseaudio while the local

Bug#470900: pulseaudio: switching forth the sink - ok, switch back - hangs client(s)

Pe 04.04.2014 22:42, Felipe Sateler fsate...@debian.org a scris: Hi, Eddy Petrișor wrote: Sjoerd Simons a scris: On Tue, Apr 08, 2008 at 09:32:59AM +0300, Eddy Petri??or wrote: Could it have to do with the fact the remote sink was running etch's pulseaudio while the local

Re: [bug #40639] GNU Make with profiling information

Pe 11.01.2014 20:58, Paul Smith psm...@gnu.org a scris: Sorry, I've been mostly away from my systems recently. On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote: Thanks for clarifying this. Could you please confirm if the general direction of the the is OK in the latest patch I sent

Re: [bug #40639] GNU Make with profiling information

2014/1/12 Paul Smith psm...@gnu.org: On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote: Could you please confirm if the general direction of the the is OK in the latest patch I sent? Conceptually it seems OK. I'm still not jazzed about having any more than one output format, and I'd

Re: [bug #40639] GNU Make with profiling information

code to review). In any case, fixed/floating point seconds since 1970 is the nicest format to process from scripts in my experience. That is what is printed now, where applicable. -- Eddy Petrișor ___ Bug-make mailing list Bug-make@gnu.org https

Re: [bug #40639] GNU Make with profiling information

Paul, I would really appreciate feedback on this. If the problem is the licensing, don't worry about my rights, I will gladly give them to the FSF. Pe 18.12.2013 13:28, Eddy Petrișor eddy.petri...@gmail.com a scris: Pe 15.12.2013 18:07, Paul Smith psm...@gnu.org a scris: On Sun, 2013-12

Re: [bug #40639] GNU Make with profiling information

Pe 15.12.2013 18:07, Paul Smith psm...@gnu.org a scris: On Sun, 2013-12-15 at 13:38 +, Tim Murphy wrote: I suppose I'm skirting around saying that I think gnu make needs an output format in the same way that valgrind has --xml=yes. I'm not an XML fan really - JSON might be an

  1   2   3   4   5   6   7   8   9   10   >