Skip to content

Nokia RX-51 support

Marek Vasut u-boot 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest2 of 14 patches 0 repliesNew

2 of 14 patches are in this archive. The cover letter announces 14.

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/14arm, omap3: Define save_boot_params in lowlevel_init.S for SPL only+0 -00 replies
5/14cfb_console: Fix function console_scrollup+0 -06 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [U-Boot] [PATCH 00/14] Nokia RX-51 support
Quoted 65 lines · On Sunday 04 March 2012 21:57:23 Marek Vasut wrote:
Quoted 64 lines

Dear Pali Rohar,

I suggest you to read through this whole mail properly, do not get angry by the first few lines.

Quoted 10 lines

U-Boot on Nokia N900 is broken due to bug in MMC and framebuffer driver. See:
http://lists.denx.de/pipermail/u-boot/2012-January/115778.html
http://lists.denx.de/pipermail/u-boot/2012-March/119330.html

Until now *nobody* responce to the first reported problem (2 months old). I
will not do anything with Nokia N900 U-Boot code until both problem will be
fixed!

Firstly, we are very grateful for properly reported bugs!

Yet you probably misunderstood how whole this free software/open source thing works.

If you found a bug noone else noticed, you are not ever supposed to expect people on the mailing list to fall on their backs, drop everything they are doing and start fixing your problem. This is because they didn't observe any trouble and so this has no priority for them.

And this is especially true for out-of-tree ports. N900 is good example of such category.

Now if you actually report a bug to the mailing list and this bug goes unnoticed for an extended period of time, you're supposed to send subsequent email in order to alarm the people on the mailing list the bug report is still relevant.

In case of U-Boot and Linux kernel, there is a list of maintainers in the MAINTAINERS file in the source tree, you are supposed to put these people in the Cc of such reports, this will greatly improve your chance of getting response and help. In case of U-Boot, there is also a list of custodians

available here:
http://www.denx.de/wiki/U-Boot/Custodians

But considering you are yourself a software engineer, the best approach to the problem you're observing is to actually debug the issue you're seeing and submit a patch for it. Next, fix your patches for N900 and submit them. It'd be a good idea to put a note in the patchset cover message that this depends on your previous fix.

Now, to the problems you're observing:

1) Video; check if you have the following defined in your board config:

#define CONFIG_VIDEO
#define CONFIG_VIDEO_SW_CURSOR
#define CONFIG_CFB_CONSOLE
#define CONFIG_VGA_AS_SINGLE_DEVICE
#define CONFIG_SYS_WHITE_ON_BLACK

I understand that you probably want to second and the last define from the list above, which solves your "invert" problem and swcursor problem.

2) MMC; I believe Tom can comment on this one.

Quoted 9 lines
Quoted 8 lines

On a final note, I believe you should adjust your behaviour towards the mailing list. The U-Boot project, as well as many other FOSS projects, is a collective effort to achieve the best possible result for everyone. But for such model to work, everyone must first give and take only afterwards and never too much.

Best regards
Marek Vasut

Dear Pali Rohar,

Quoted 3 lines

Ok. I already sent mail about problem 1) to video maintainer and also sent bug remainder to this list. Now I sent some more info about that problem, so maybe someone could help me.

Did you try the above solution for the video issues?

Quoted 2 lines

I understand you, but mails without response look like ignored.

That's why you need to prod, prod and prod ... in a sane way ;-)

Quoted 3 lines

Also now
with U-Boot master Nokia port does not working, so it cannot be merged to master. I belive that you do not want/need not working code.

That's true, but you can always fix your issues locally and submit those fixed upstream, followed by your newly working code.

Quoted 4 lines

I'm not angry, but now I'm stucked, because I (and nobody other) was not able to fix problem 1) and problem 1) must be fixed before pushing rx51 patches to master. So I cannot work on rx51 patches...

So why don't YOU fix the problem? Maybe we should try diagnosing it?

I might have some time after NSWI075 on tuesday, ending 19:00, you might want to catch me afterwards and we can look into it for a bit?

Best regards
Marek Vasut