Carlos Leyva Guerrero | 19 Nov 11:21 2014
Picon

Mini2440 - new flash chip - barebox update to last version

Dear Juergen and Sasha, 

I'have included you both given that you (Juergen) is the one working with the ptxdist version for the mini2440 and you (Sasha) are currently developing barebox.

Juergen is aware of a problem we have with the new mini2440 boards due to a change of the nand device because EOL of the previous part. Some adjustments need to be done to the nand controller to disallow partial programming because the new chip doesn't support it (and also have worse timings).

In any case, I am trying to solve it but also to update the barebox to its latest version (2014.11.0). I have already ported the env structure to the new format on barebox. When booting from nor (vivi) and then loading barebox on ram, I have no problems (beside the fact that I haven't implemented the new methods for barebox_update and have temporary solved it by including the update scripts from previous versions). However, when I try to load from the NAND nothing happens, no output in the serial port.

I'm trying to setup a arm debugger+opencd setup to see if I can find out what could be happening but for the time being, I don't have yet the required HW.

Surfing through the code in both releases (the one in last git respository for 2440, barebox 2011.05.0 and the last one available on barebox webpage (2014.11.0) I haven't found any major differences (that could cause this behaviour) besides one specific modification in lowlevel.S that replaces TEXT_BASE for TEXT_BASE - SZ_2M in the nand load routine. Do you now the reason for such a change?

Btw, i forgot to mention that I've also added the required modifications for proper management of 'big (>=128Mb) nands' using the patches from previous version as a base.

Can any of you provide some help regarding this issue? Specifically, have been there any attempts to update barebox to its last version for mini2440? Could any of you provide an inner point of view and some possible explanation for the impossibility to boot from nand?

Thanks in advance, 

Best regards, 

Carlos Leyva


-- 


ian c | 17 Nov 11:07 2014
Picon

BSP configuration for automount SD partition during boot-up

Hello Experts,

I have this partition on the SD card.
----
        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192       16383        4096   83  Linux
/dev/mmcblk0p2           16384     3162111     1572864   83  Linux
/dev/mmcblk0p3         3162112     3686399      262144   83  Linux
----

The /dev/mmcblk0p2 partition is the root partition while /dev/mmcblk0p3 is the spare partition.
Currently, I do manual mounting and formatting the spare partition and then added to fstab.

May I know how to configure the BSP so that the spare partition will automatically mount on first and onward
system boot-up?

Best REgards,
Ian

 		 	   		  

Carlos Leyva Guerrero | 11 Nov 12:37 2014
Picon

Problem with new nand flash

Dear Juergen and all, 

I am having problems with a new batch of mini2440 boards I have received from the manufacturer, the chip for NAND in this boards is K9K8G08U0E SCB0. I am able of writing data to the board (i.e. write the bootloader (busybox) and our linux image) but, as soon as i start using the board and filling up the space, more and more problems appear, making the boot time unusable (>10 mins) due to MTD error messages.

Previously, I have been working with boards with chips SAMSUNG 131 K9K8G08UOB PIB0 and K9K8G08OUOD SCB0 with no problem, same image, same bootloader. 

I have been able to locate a note regarding differences in the chips: http://www.phytec.de/fileadmin/user_upload/pictures/Support/LPN-134e_1.pdf

Are you aware of this situation? Have been it solved in latest OSELAS releases? If not, could you please give some guidance in the solution of this issue?

I'm stuck with old kernels because we could say the boards are in "production stage" so no big changes should be performed in order to avoid further problems and because in later kernel versions, as far as I remember, new issues arose as Sound not working.

Please let me know if any one can provide some light.

Best regards, 

Carlos Leyva


-- 


ian c | 10 Nov 15:34 2014
Picon

Upgrading OSELAS python package

Hi All,

The current python in OSELAS is python 2.6.6. I would like to run an application that requires python 2.7.6.
Therefore, I need to upgrade the version. I could not use the version 3.0 since it is unstable for that application.

Could anybody help me on this?

Thank you. 		 	   		  

mind entropy | 7 Nov 18:57 2014
Picon

On SDRAM BK76MAP value.

Hi,

  I am developing a small BSP and I am trying to configure my SDRAM.

  In the barebox configuration of SDRAM the BK76MAP has the value of
001 i.e. 64MB/64MB  (
http://git.pengutronix.de/?p=barebox.git;a=blob;f=arch/arm/boards/friendlyarm-mini2440/config.h;h=347930224e4cee893db77c9142c9550e828748dc;hb=784b352aeeed917f9cf75b3e8fc74aec12a48a01#l117
) see line 117.

   I have a K4S561632N SDRAM (
http://www.samsung.com/global/business/semiconductor/product/consumer-dram/detail?productId=7147&iaId=742).
On the board I see 2 chips. I am assuming these are 2 banks. Should my
BK76MAP be 32MB/32MB? Also how do I get the SCAN parameter (9 bit
columns in the code)?

Thanks,
Gautam.

ian c | 30 Oct 07:46 2014
Picon

memory dump utility in Oselas

Dear Experts,

I developed an application to load multiple input xml files. I used linked list to manage these multiple
files. For some reason there is one xml files that eat large chunk of memories. I plan to dump the memory
allocated this xml file for debugging purposes. I am thinking to use dump command utility but I could not
find in Oselas.BSP menuconfig. Just wondering if the dump command is supported on Oselas.BSP. I would
appreciate if someone can point me where to enable this dump utility in menuconfig.

Best Regards,
Ian 		 	   		  

Dave Festing | 18 Oct 11:21 2014
Picon

unable to locate package ipkg

Upgraded from Ubuntu 10.04LTS to Xubuntu 14.04LTS on both my desktop and
netbook.

I can ptxdist go and ptxdist images on the Desktop but on the netbook,
withptxdist images, I get the following error:

davef <at> davef-AOD255E:~/OSELAS.BSP-Pengutronix-Mini2440-2013.10.0$ ptxdist images
Creating ipkg index
'/home/davef/OSELAS.BSP-Pengutronix-Mini2440-2013.10.0/platform-mini2440
/packages/Packages'...
Traceback (most recent call last):
  File
"/home/davef/OSELAS.BSP-Pengutronix-Mini2440-2013.10.0/platform-mini2440
/sysroot-host/bin/ipkg-make-index",
line 7, in <module>
    import ipkg
ImportError: No module named ipkg
make: ***
[/home/davef/OSELAS.BSP-Pengutronix-Mini2440-2013.10.0/platform-mini2440
/packages/Packages]
Error 1

***********
It doesn't seem to make any difference ticking or unticking ipkg in Disk and
File Utilities.  Before I completely re-install ptxdist is there an easier
fix to this problem?

Thank you,
Dave

G. B. | 13 Oct 03:08 2014
Picon

Stare and compare ... Opus 2


Let's see, Mini6410 and linux-3.14.19.

Thus spoke dmesg:

  ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
  ohci-platform: OHCI generic platform driver
  ohci-s3c2410: OHCI S3C2410 driver
  s3c2410-ohci s3c2410-ohci: OHCI Host Controller
  s3c2410-ohci s3c2410-ohci: new USB bus registered, assigned bus number 1
  s3c2410-ohci s3c2410-ohci: irq 79, io mem 0x74300000
  s3c2410-ohci s3c2410-ohci: init err (00000000 0000)
  s3c2410-ohci s3c2410-ohci: can't start
  s3c2410-ohci s3c2410-ohci: startup error -75
  s3c2410-ohci s3c2410-ohci: USB bus 1 deregistered
  s3c2410-ohci: probe of s3c2410-ohci failed with error -75

Well ... <sigh> ... That's less than optimal.

So, where does this error come from?  Let's see ...

   drivers/usb/host/ohci-hcd.c

contained within:

   static int ohci_run (struct ohci_hcd *ohci)

around line 674:

   /* some OHCI implementations are finicky about how they init.
    * bogus values here mean not even enumeration could work.
    */
   if ((ohci_readl (ohci, &ohci->regs->fminterval) & 0x3fff0000) == 0
           || !ohci_readl (ohci, &ohci->regs->periodicstart)) {
       if (!(ohci->flags & OHCI_QUIRK_INITRESET)) {
           ohci->flags |= OHCI_QUIRK_INITRESET;
           ohci_dbg (ohci, "enabling initreset quirk\n");
           goto retry;
       }
       spin_unlock_irq (&ohci->lock);
       ohci_err (ohci, "init err (%08x %04x)\n",
           ohci_readl (ohci, &ohci->regs->fminterval),
           ohci_readl (ohci, &ohci->regs->periodicstart));
       return -EOVERFLOW;
   }

So, the message:

   s3c2410-ohci s3c2410-ohci: init err (00000000 0000)

indicates both values:

   ohci->regs->fminterval
   ohci->regs->periodicstart

appear to be zero.  Right.

What does that imply?  I don't know.  Having been chasing more than a 
couple CCF related issues, perhaps this is similar?  Perhaps not ...

Checking:

   drivers/usb/host/ohci-s3c2410.c

it appears that it desires these two clocks:

   clk = devm_clk_get(&dev->dev, "usb-host");
...
   usb_clk = devm_clk_get(&dev->dev, "usb-bus-host");

Checking:

   drivers/clk/samsung/clk-s3c64xx.c

corresponding entries are found:

   ALIAS(HCLK_UHOST, "s3c2410-ohci", "usb-host"),
...
   ALIAS(SCLK_UHOST, "s3c2410-ohci", "usb-bus-host"),

Yet, there are also entries for:

   GATE_BUS(HCLK_UHOST, "hclk_uhost", "hclk", HCLK_GATE, 29),
...
   GATE_BUS(HCLK_USB, "hclk_usb", "hclk", HCLK_GATE, 20),
...
   GATE_SCLK(SCLK_UHOST, "sclk_uhost", "dout_uhost", SCLK_GATE, 30),

Hmmm ... I don't think that's it.  Once again, I think I'm going in the 
wrong direction.

Time passes.  Yes.  Wrong direction.  Again.  Several of my experiments 
have ... well, let's just say that it has been interesting.  Clearly, 
I'm missing something.  Does anyone have some relevant insight they are 
willing to share?

G. B. | 10 Oct 18:32 2014
Picon

Stare and compare ...


... a time honoured tradition.  No doubt about that.

Friends, Geeks, Hackers, I come not to bury the kernel, but to praise 
it.  The evil that change does, lives after; the good is oft interred 
with its bones.  So let it be with this change.

Enough foolishness.

Foolishly I was hacking on my Mini6410 and despite many hours of trying 
to get the FA '1wire' display to function as a touchscreen; sadly I have 
failed.  Hence, I hit upon the bright (dim?) idea of moving the 6410BSP 
forward to using linux-3.14.19.  Brilliant!  You say?  Hah!  No fool 
like an old fool.  So they say.  Whoever 'they' are.  Get off my lawn! 
Bah!  <grumble>

In the beginning, progress was good, and I was feeling pretty darn 
arrogant about it.  Hah!  Such a fool!

Then this happened:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:926 __clk_enable+0x28/0x98()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.19-ptx-master #21
[<c00134c8>] (unwind_backtrace) from [<c0011084>] (show_stack+0x10/0x14)
[<c0011084>] (show_stack) from [<c001c37c>]
(warn_slowpath_common+0x60/0x80) [<c001c37c>] (warn_slowpath_common) from
[<c001c3b4>]
(warn_slowpath_null+0x18/0
x1c)
[<c001c3b4>] (warn_slowpath_null) from [<c02a2be8>]
(__clk_enable+0x28/0x98) [<c02a2be8>] (__clk_enable) from [<c02a3084>]
(clk_enable+0x18/0x2c) [<c02a3084>] (clk_enable) from [<c0018a28>]
(s3c_adc_probe+0x12c/0x1a4) [<c0018a28>] (s3c_adc_probe) from [<c020f9ac>]
(platform_drv_probe+0x1c/0x4c)
[<c020f9ac>] (platform_drv_probe) from [<c020e410>]
(really_probe+0xa4/0x1e4)
[<c020e410>] (really_probe) from [<c020e694>] (__driver_attach+0x60/0x84)
[<c020e694>] (__driver_attach) from [<c020cf64>]
(bus_for_each_dev+0x50/0x84)
[<c020cf64>] (bus_for_each_dev) from [<c020dd04>]
(bus_add_driver+0xa8/0x1bc)
[<c020dd04>] (bus_add_driver) from [<c020ed10>] (driver_register+0x9c/0xe0)
[<c020ed10>] (driver_register) from [<c046b000>] (adc_init+0x10/0x38)
[<c046b000>] (adc_init) from [<c00086d4>] (do_one_initcall+0x9c/0x140)
[<c00086d4>] (do_one_initcall) from [<c0466ab0>]
(kernel_init_freeable+0xe4/0x1a
c)
[<c0466ab0>] (kernel_init_freeable) from [<c033a4bc>]
(kernel_init+0x8/0xe4) [<c033a4bc>] (kernel_init) from [<c000dc98>]
(ret_from_fork+0x14/0x3c) ---[ end trace 82208269eb5301d8 ]---

Hence, it would seem that the problem begins elsewhere, but manifests
here:

   arch/arm/plat-samsung/adc.c

within:

   static int s3c_adc_probe(struct platform_device *pdev)

near this slice of code:

   adc->clk = devm_clk_get(dev, "adc");
   if (IS_ERR(adc->clk)) {
     dev_err(dev, "failed to get adc clock\n");
     return PTR_ERR(adc->clk);
   }

...

   clk_enable(adc->clk);

The error comes from the call to clk_enable(); yet, it begins earlier in
the call to devm_clk_get().

I chased many squirrels, and went down several 'rabbit holes'; only to 
be rewarded with several moments of intersection.  Intersecting my skull 
with the brick wall of 'way wrong answer'!

Then, either through epiphany, or more likely a concussion; I found a 
cleverly subtle but illuminating reference buried within this 'new 
fangled' 'internet-thingy' ... 'Common Clock Framework' (CCF for those 
already 'in the know').

Within this little gem of intrigue contained therein a header file:

/**
  * devm_clk_get - lookup and obtain a managed reference to a clock 
producer.
  *  <at> dev: device for clock "consumer"
  *  <at> id: clock consumer ID
  *
  * Returns a struct clk corresponding to the clock producer, or
  * valid IS_ERR() condition containing errno.  The implementation
  * uses  <at> dev and  <at> id to determine the clock consumer, and thereby
  * the clock producer.  (IOW,  <at> id may be identical strings, but
  * clk_get may return different clock producers depending on  <at> dev.)
  *
  * Drivers must assume that the clock source is not enabled.
  *
  * devm_clk_get should not be called from within interrupt context.
  *
  * The clock will automatically be freed when the device is unbound
  * from the bus.
  */

NB: "...but clk_get may return different clock producers depending on
       <at> dev ..."

(Register shock and moral outrage!)

A glimmer of hope, to be certain.

Culling through drivers/clk/samsung yielded this tidbit of information.

clk-s3c64xx.c does get compiled.  It also contains a handy-dandy structure:

   static struct samsung_clock_alias s3c64xx_clock_aliases[]

which just so happens to contain:

   ALIAS(PCLK_TSADC, "s3c64xx-adc", "adc"),

which just so happens to contain the very text token "adc" which the call:

   adc->clk = devm_clk_get(dev, "adc");

yearns to discover.

Here, my compatriots, is where this morality tale has lead.

Oh the wickedness of hacking has lead me to this dark place!  Yea verily 
I beckon one of the wise sages.  A priest of the kernel to step forth 
and bestow upon this 'Junior Apprentice Kernel Hacker In Training' a 
snippet of wisdom.  Shine your countenance upon my darkened (and 
possibly concussed) brain, so that I may become more wise.  I fear that 
I have lost my way (and probably a few 'geek' points as well).  Grant me 
the sacrament of a clue for my transgression.  (Although, an answer to 
this vexing problem would be welcome as a gentle summer breeze)

Bow.

Scrape.

Say, does anyone have a bottle of ... Bah! ... never mind, I'll find my 
own <durn> bottle.

Grumble.

Cantankerously,
GB

G. B. | 4 Oct 00:15 2014
Picon

mini2440 FA 1-wire support (with patches)


Credit where credit is due:

Thank you, very much, to Tomasz Figa for his work on FriendlyARM '1-wire'.

Thank you to Juergen Borleis for his work supporting the Mini 2440.

With a measure of certainty, I'm reasonably confident that I've done 
something incorrectly.  Hence, it would be nice if someone could test 
these patches.

Theory:

It seems (from reading the mailing list) that others would like to have 
this FriendlyARM 1-wire support for both the Mini 2440 and Mini 6410.

Hopefully, it doesn't offend any one that I renamed T. Figa's files 
(which were applied to the 6410 project).  It seemed like they would be 
useful to both the 2440 and 6410 (and probably other) boards; hence, I 
created these patches to be (hopefully) useful to both.

Practice:

I added the following:

   # FA 1-wire Support
   fa_1wire_fa_1wire.diff
   fa_1wire_fa_1wire_ts.diff
   fa_1wire_mach-mini2440.c.diff

to:

   configs/platform-friendlyarm-mini2440/patches/linux-3.14/series

near the bottom of the file, and (of course) updated:

   set-marker.diff

accordingly, and added the patch files to the same directory as 
'series'.  I've used the patches on 3.14.16 and 3.14.19.  I am planning 
to revert the kernel changes and test them on 3.14.2 over the weekend. 
Thus far, the patches apply cleanly.  Next step:

   ./p clean kernel
   ./p go

Just wanted to be certain that the kernel unpack and rebuild works and 
there is nothing bad happens during patching.

Moving forward.

Add the following:

   SUBSYSTEMS=="input", KERNEL=="event[0-9]*", KERNELS=="input[0-9]*",
     ATTRS{name}=="S3C24XX TouchScreen", SYMLINK+="input/touchscreen"

   SUBSYSTEMS=="input", KERNEL=="event[0-9]*", KERNELS=="input[0-9]*",
     ATTRS{name}=="FA Touchscreen", SYMLINK+="input/fa_1wire"

to:

   /lib/udev/rules.d/10-mini2440.rules

on the target.

Also on the target, in:

   /etc/profile.environment

change:

   MINI2440_TOUCHEVENT=/dev/input/touchscreen

to:

   MINI2440_TOUCHEVENT=/dev/input/touchscreen
   MINI2440_1WIRE=/dev/input/fa_1wire

and change:

   # Qt relevant settings
   export QWS_MOUSE_PROTO=Tslib:${MINI2440_TOUCHEVENT}

to:

   # Qt relevant settings
   export QWS_MOUSE_PROTO="Tslib:${MINI2440_TOUCHEVENT}
     Tslib:${MINI2440_1WIRE}"

nb: the quotes and the space are important (you know what to do)

Oh, yes, I also modified the bootargs variable from:

   bootargs=console=ttySAC0,115200 mini2440=1tb

to:

   bootargs=console=ttySAC0,115200 mini2440=1tbo

With this configuration, I was able to use an A70 (7") display in the 
'analog' and 'digital' modes:

   *) analog R6, R7, R8, R9 installed; R11, R20, R21, R22 removed
   *) 1-wire R11, R20, R21, R22 installed; R6, R7, R8, R9 removed

It was a nice test; however, on a 'production' unit 't' and 'o' should, 
most likely, be mutually exclusive.  Although it didn't seem to hurt to 
have both drivers.

I have to say; in an electrically noisy environment, the 1-wire display 
appeared to be more 'stable'; meaning the mouse pointer appeared less 
'jittery' as compared to the analog touchscreen driver.  It would be 
interesting to see if anyone else makes such an observation.

Let's see ... what else did I do? .... probably something foolish, and 
I'm certain someone will point it out ... no doubt about that.

Oh yes, I've tested this, of course, with a mini2440, and the following 
displays:

   /* mini2440 + 7" TFT + touchscreen (Innolux AT070TN83: N43/LCD70) */
   /* LCD-W35i 3.5" display (Sharp LQ035Q1DG06: W35i )*/

I have an H43 (currently installed on a Mini6410) which I'll be able to
test next week.

At this point it seems customary to request a review, and test victims.
Please test the patches if you are able to do so.

GB
Attachment (fa_1wire_fa_1wire_ts.diff): text/x-patch, 7655 bytes
Juergen Borleis | 1 Oct 09:01 2014
Picon

Re: u-boot_hd.config

Hi Ian,

please keep the mailing list at least on CC. Thanks.

On Wednesday 01 October 2014 07:19:08 ian c wrote:
> thanks for the detailed description. However, I still have question,
> though.
>
> >> partition spare {
> >> size = 256M
> >> partition-type = 0x83
> >> }
> >> size=1024M
> >> }
>
> What is mean for size=1024M? If I add partition (e.g. I name its partition
> duplicate), should I reduce that size value?

If you take a closer look, the "size=1024M" is inside the "image" block. So it 
defines the size of the whole image file to be created.

Regards,
Juergen

--

-- 
Pengutronix e.K.                              | Juergen Borleis             |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |


Gmane