Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Ulf Samuelsson]

The goal of this branch is to update the AT91 support.

1) Fix AT91bootstrap, which is currently non-functional
2) Update to the latest u-boot (2009.08-rc2)
3) Update the kernel (2.6.30.2)
   with many AT91 patches not yet in mainstream kernel.
   MCI patches still lacking...

I have so far managed to build everything and load
on an AT91SAM9263EK which has a dataflash
containing at91bootstrap, u-boot and linux.

0x0     at91bootstrap
0x8400  u-boot
0x84000 linux

The NAND flash is programmed with a root file system

0x400000 JFFS2 root file system.

AT91BOOTSTRAP
v2.10 was completely wrong due to bad linkaddr.
v2.12 and v2.13 boots properly from dataflash.

Supported boards:
afeb9260
cap9adk
cap9stk
sam9g10ek
sam9g20ek
sam9g45ekes
sam9rlek
sam9xeek
sam9260ek
sam9261ek
sam9263ek


df	dataflash
dfc	dataflashcard
nf	nandflash
f	parallel flash

No support for SD-Card boot yet

All boards compile, but only the SAM9263EK has been tested on H/W.
Only dataflashcard boot that is...
Boot from NAND flash not tested.

The updated at91bootstrap changes the recipe
so that the normal way to configure is to do

oe_runmake <board>_defconfig

instead of copying a defconfig file to the toplevel .config

Since AT91bootstrap-2.12 supports KConfig, it is easy to
create your own board support by entering the builddirectory
and run make menuconfig.

Copy the resulting .config to one of the board directories
and create a patch which will generate this file.
This way, supported boards will not need a defconfig file
in the recipies/at91bootstrap directory.

The at91bootstrap-2.13-rc1 will attempt to init the bus-matrix of
the sam9263, which is neccessary for large screens,
but I have no large screen to test on.
If the CONFIG_PSRAM is enabled (which it is), then
LCD access to the 32 bit bus has low priority which
can cause problems.

The priority is also set so that the MACB has
high priority to the 80 kB SRAM and the OHCI
has high priority to the 16 kB SRAM.

The LCD and 2DACC has high priority to the EBI1.

2.13-rc1 also adds support for the AFEB9260.
(Compiled, but not tested on a board)

U-BOOT
Updated to 2009.08-rc2 with patches.
I use the same patches as in Buildroot
so some are not 100% applicable.

Supported at91 boards in the atmel directory:
cap9adk
rm9200dk
rm9200ek
sam9g45ekes
sam9m10g45ek
sam9rlek
sam9260ek	used for 	sam9xeek	sam9g20ek
sam9261ek	used for	sam9g10ek
sam9263ek


Some patches:
Disables -msoftfloat
Adds some downloads tools for minicom (sx-at91/sx-raw)
Some extra commands to set up a scripts which
will make it easier for newbies.
"factory" command will generate the default environment
even if a newbie has overwritten the environment.
"ethinit" will init the ethernet mac
Support for commands handling the LEDs.
Update of configs
gcc-4.4 does not like the combination of weak and inline
Increase the area for u-boot to both sector 1 and 2.
A dataflash is divided mostly into sectors of 256 pages (1056 bytes)
but the first 256 pages are divided into an 8 page parameter area
and a 248 page sector for other things.
The patch adds another 256 page sector.
When compiling with late gcc compilers, which uses
their own libgcc, div0 calls "raise" which is
not part of libgcc, but rather part of glibc.
The patch adds a raise in libarm/board.c which
calls the "hang" routine.
Use -mabi=aapcs-linux instead of -mabi=apcs-gnu

In the tested configuration, U-BOOT 2009.08-rc2
is loaded by at91bootstrap and can tftp
down a kernel which is programmed to dataflash.
The kernel boots.

The last time I bitbaked this, U-Boot did not build
for some reason.
When I bitbaked u-boot directly, it built.
Will rebuild again and see if problem repeats.

LINUX
A kernel is generated, with the defconfig taken
from Marcin's 2.6.30, slightly updated.

Added a lot of patches from the ARM mailing list,
but the MCI is missing.
Hope to get that later.

linux boots and you can communicate with the console,
but gpe is not started properly.

I introduced the possibility to build linux using
make <board>_defconfig, instead of using a
defconfig in a board directory under linux.
LINUX26_DEFCONFIG needs to be defined.


BOARD SUPPORT
Since there are plenty of AT91 chips with more coming,
I decided to make two include files.
conf/machine/include/AT91.inc
conf/machine/include/AT91-LCD.inc

An AT91 board can include one of the two
files simplifying the maintenance.

The latter includes the former, and adds
some extra support for screens.

Since the sam9rl does not have an usbhost,
each board will have to supply this in the board support file.
Typically each file is now reduced to:

include conf/machine/include/AT91-LCD.inc
LINUX26_CONFIG = "at91sam9263ek_defconfig"
UBOOT_MACHINE = "at91sam9263ek_config"
AT91BOOTSTRAP_BOARD = "at91sam9263ek"
MACHINE_FEATURES += "usbhost"

There are board configs for:
cap9adk
cap9stk
sam9g10ek
sam9g20ek
sam9g45ekes
sam9m10ek
sam9rlek
sam9xeek
sam9260ek
sam9261ek
sam9263ek
at572d940hf (diopsis ARM9 + 1 Gflops Floating Point DSP)

Again, only the sam926e3k has been tested.

Checksums are updated of course.

I will spend some time testing this, but
I hope I will get some help from interested parties.

-- 
Best Regards
Ulf Samuelsson

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Marcin Juszkiewicz]

Dnia wtorek, 11 sierpnia 2009 o 20:55:00 Ulf Samuelsson napisał(a):
> The goal of this branch is to update the AT91 support.
>
> 1) Fix AT91bootstrap, which is currently non-functional
> 2) Update to the latest u-boot (2009.08-rc2)
> 3) Update the kernel (2.6.30.2)
>    with many AT91 patches not yet in mainstream kernel.
>    MCI patches still lacking...

Cool! I will check your changes and then rebase and merge them into .dev 
tree. I am also planning to push it later to stable/2009 branch.

> I have so far managed to build everything and load
> on an AT91SAM9263EK which has a dataflash
> containing at91bootstrap, u-boot and linux.
>
> 0x0     at91bootstrap
> 0x8400  u-boot
> 0x84000 linux
>
> The NAND flash is programmed with a root file system
>
> 0x400000 JFFS2 root file system.

Similar setup is used on at91sam9263-ek here so I will test your branch.

> AT91BOOTSTRAP
> v2.10 was completely wrong due to bad linkaddr.
> v2.12 and v2.13 boots properly from dataflash.

Can we just drop all older versions?

I had to add patch to 2.12 to get rid of -fno-dwarf2-cfi-asm parametr 
passed to GCC. Did not tested with 2.13-rc1 as at91.com is not 
reachable.

> All boards compile, but only the SAM9263EK has been tested on H/W.
> Only dataflashcard boot that is...
> Boot from NAND flash not tested.

Thats what I will not test either - my board has Rev A cpu so only dfc 
booting possible.

> The updated at91bootstrap changes the recipe
> so that the normal way to configure is to do
>
> oe_runmake <board>_defconfig
>
> instead of copying a defconfig file to the toplevel .config

Thats good - especially as at91bootstrap configs in OE are basically the 
same which are in sources.

> U-BOOT
> Updated to 2009.08-rc2 with patches.

[..]

> The last time I bitbaked this, U-Boot did not build
> for some reason.
> When I bitbaked u-boot directly, it built.
> Will rebuild again and see if problem repeats.

Will check it.

> LINUX
> A kernel is generated, with the defconfig taken
> from Marcin's 2.6.30, slightly updated.
>
> Added a lot of patches from the ARM mailing list,
> but the MCI is missing.
> Hope to get that later.

I will merge it with linux_2.6.30.bb recipe. Will add also latest 
2.6.30.x patch to this.

For future: do not use linux-2.6.30.2.tar.bz2 but linux-2.6.30.bz2 + 
patch-2.6.30.2.bz2 - this will save download time for those who have 
linux-2.6.30.tar.bz2 tarball already.

> linux boots and you can communicate with the console,
> but gpe is not started properly.

Interesting problem, will check but later as now I have other type of 
image as default.

> I introduced the possibility to build linux using
> make <board>_defconfig, instead of using a
> defconfig in a board directory under linux.
> LINUX26_DEFCONFIG needs to be defined.

Interesting, will check. I see a problem anyway because linux_*.bb 
recipes by default use defconfig as part of SRC_URI. But we can use 
empty file to satisfy it.

> BOARD SUPPORT
> Since there are plenty of AT91 chips with more coming,
> I decided to make two include files.
> conf/machine/include/AT91.inc
> conf/machine/include/AT91-LCD.inc

Thanks a lot - I had that in todolist ;)

> I will spend some time testing this, but
> I hope I will get some help from interested parties.

As always you can count on me when it comes to AT91 stuff.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Ulf Samuelsson]

Marcin Juszkiewicz skrev:
> Dnia wtorek, 11 sierpnia 2009 o 20:55:00 Ulf Samuelsson napisał(a):
>> The goal of this branch is to update the AT91 support.
>>
>> 1) Fix AT91bootstrap, which is currently non-functional
>> 2) Update to the latest u-boot (2009.08-rc2)
>> 3) Update the kernel (2.6.30.2)
>>    with many AT91 patches not yet in mainstream kernel.
>>    MCI patches still lacking...
> 
> Cool! I will check your changes and then rebase and merge them into .dev 
> tree. I am also planning to push it later to stable/2009 branch.
> 
>> I have so far managed to build everything and load
>> on an AT91SAM9263EK which has a dataflash
>> containing at91bootstrap, u-boot and linux.
>>
>> 0x0     at91bootstrap
>> 0x8400  u-boot
>> 0x84000 linux
>>
>> The NAND flash is programmed with a root file system
>>
>> 0x400000 JFFS2 root file system.
> 
> Similar setup is used on at91sam9263-ek here so I will test your branch.
> 
>> AT91BOOTSTRAP
>> v2.10 was completely wrong due to bad linkaddr.
>> v2.12 and v2.13 boots properly from dataflash.
> 
> Can we just drop all older versions?

The guys responsible for afeb9260 might want to test.

> 
> I had to add patch to 2.12 to get rid of -fno-dwarf2-cfi-asm parametr 
> passed to GCC. Did not tested with 2.13-rc1 as at91.com is not 
> reachable.

Yes, fixed in 2.13-rc1
Will send you the source file.

> 
>> All boards compile, but only the SAM9263EK has been tested on H/W.
>> Only dataflashcard boot that is...
>> Boot from NAND flash not tested.
> 
> Thats what I will not test either - my board has Rev A cpu so only dfc 
> booting possible.
> 
>> The updated at91bootstrap changes the recipe
>> so that the normal way to configure is to do
>>
>> oe_runmake <board>_defconfig
>>
>> instead of copying a defconfig file to the toplevel .config
> 
> Thats good - especially as at91bootstrap configs in OE are basically the 
> same which are in sources.
> 
>> U-BOOT
>> Updated to 2009.08-rc2 with patches.
> 
> [..]
> 
>> The last time I bitbaked this, U-Boot did not build
>> for some reason.
>> When I bitbaked u-boot directly, it built.
>> Will rebuild again and see if problem repeats.
> 
> Will check it.

Someone found the same problem.

> 
>> LINUX
>> A kernel is generated, with the defconfig taken
>> from Marcin's 2.6.30, slightly updated.
>>
>> Added a lot of patches from the ARM mailing list,
>> but the MCI is missing.
>> Hope to get that later.
> 
> I will merge it with linux_2.6.30.bb recipe. Will add also latest 
> 2.6.30.x patch to this.
> 
> For future: do not use linux-2.6.30.2.tar.bz2 but linux-2.6.30.bz2 + 
> patch-2.6.30.2.bz2 - this will save download time for those who have 
> linux-2.6.30.tar.bz2 tarball already.

OK.

>> linux boots and you can communicate with the console,
>> but gpe is not started properly.
> 
> Interesting problem, will check but later as now I have other type of 
> image as default.
> 
>> I introduced the possibility to build linux using
>> make <board>_defconfig, instead of using a
>> defconfig in a board directory under linux.
>> LINUX26_DEFCONFIG needs to be defined.
> 
> Interesting, will check. I see a problem anyway because linux_*.bb 
> recipes by default use defconfig as part of SRC_URI. But we can use 
> empty file to satisfy it.

The fix will test if $(LINUX_DEFCONFIG) is defined,
and if so, it will copy $(LINUX_DEFCONFIG)
to defconfig to avoid problems with recipes

Had a bug, but I got it running today.
Will push soon.


> 
>> BOARD SUPPORT
>> Since there are plenty of AT91 chips with more coming,
>> I decided to make two include files.
>> conf/machine/include/AT91.inc
>> conf/machine/include/AT91-LCD.inc
> 
> Thanks a lot - I had that in todolist ;)
> 
>> I will spend some time testing this, but
>> I hope I will get some help from interested parties.
> 
> As always you can count on me when it comes to AT91 stuff.
> 
> Regards, 


-- 
Best Regards
Ulf Samuelsson

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Koen Kooi]

On 12-08-09 14:33, Marcin Juszkiewicz wrote:

>> I introduced the possibility to build linux using
>> make<board>_defconfig, instead of using a
>> defconfig in a board directory under linux.
>> LINUX26_DEFCONFIG needs to be defined.
>
> Interesting, will check. I see a problem anyway because linux_*.bb
> recipes by default use defconfig as part of SRC_URI. But we can use
> empty file to satisfy it.

The defconfig-in-OE bit is there because the in-kernel ones are either

a) broken
b) lacking drivers for nearly everything

I suspect you'll be introducing a huge regression when it comes to 
things like uinput, netfilter, usb drivers, etc.

regards,

Koen

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Phil Blundell]

On Wed, 2009-08-12 at 14:33 +0200, Marcin Juszkiewicz wrote:
> Dnia wtorek, 11 sierpnia 2009 o 20:55:00 Ulf Samuelsson napisał(a):
> > I introduced the possibility to build linux using
> > make <board>_defconfig, instead of using a
> > defconfig in a board directory under linux.
> > LINUX26_DEFCONFIG needs to be defined.
> 
> Interesting, will check. I see a problem anyway because linux_*.bb 
> recipes by default use defconfig as part of SRC_URI. But we can use 
> empty file to satisfy it.

We've tried this kind of thing before on various platforms and it
generally seems to be a losing proposition.  Even if your kernel sources
are targetting just a single MACHINE, the kernel isn't quite modular
enough yet that you can truly have a "one size fits all" configuration
to suit all DISTROs.

Also, if you are relying on the defconfig from upstream, any
configuration change at all requires that you either patch it, or
re-issue the upstream tarball.  Neither of those are as convenient as
just editing the defconfig locally in OE.

So, in general, I think you're probably better off sticking with the
"defconfig in FILESDIR" paradigm.  That's not to say I'm completely
opposed to adding the option to use the one from upstream, but I think
you would need to be a bit careful about where you use it.

p.

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Ulf Samuelsson]

Phil Blundell skrev:
> On Wed, 2009-08-12 at 14:33 +0200, Marcin Juszkiewicz wrote:
>> Dnia wtorek, 11 sierpnia 2009 o 20:55:00 Ulf Samuelsson napisał(a):
>>> I introduced the possibility to build linux using
>>> make <board>_defconfig, instead of using a
>>> defconfig in a board directory under linux.
>>> LINUX26_DEFCONFIG needs to be defined.
>> Interesting, will check. I see a problem anyway because linux_*.bb 
>> recipes by default use defconfig as part of SRC_URI. But we can use 
>> empty file to satisfy it.
> 
> We've tried this kind of thing before on various platforms and it
> generally seems to be a losing proposition.  Even if your kernel sources
> are targetting just a single MACHINE, the kernel isn't quite modular
> enough yet that you can truly have a "one size fits all" configuration
> to suit all DISTROs.
> 
> Also, if you are relying on the defconfig from upstream, any
> configuration change at all requires that you either patch it, or
> re-issue the upstream tarball.  Neither of those are as convenient as
> just editing the defconfig locally in OE.
> 
> So, in general, I think you're probably better off sticking with the
> "defconfig in FILESDIR" paradigm.  That's not to say I'm completely
> opposed to adding the option to use the one from upstream, but I think
> you would need to be a bit careful about where you use it.
> 
> p.

Initially, this is to allow easy test of a new board where a config
exists in the kernel.
When there is a configured/tested board, then there will be a defconfig.
Long term plan would make sure that the board defconfig is optimized for
openembedded.


I really don't like calling the stuff "defconfig" though.
Much rather call it "linux-2.6.30.2-at91sam9263nf.config"
or similar so I can tell what it is all about...

Also, why are we copying defconfig to the toplevel.
Why not copy to arch/<ARCH>/config/<BOARD>_defconfig
do the make <BOARD>_defconfig and then SED the contents?

> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


-- 
Best Regards
Ulf Samuelsson

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Ulf Samuelsson]

Status of build:
I tried building some boards overnight.

sam9263dfc:	x11-gpe-image
	I had
	GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 de_DE.UTF-8"
	from an old local.conf.sample
	This should be
	GLIBC_GENERATE_LOCALES = "en_US.UTF-8 en_GB.UTF-8 de_DE.UTF-8"

sam9261df:
	Same as sam9263dfc

sam9g45ek:	x11-gpe-image
	I enabled power management for the linux kernel.
	This does not work, so I will change the linux config.

sam9260dfc:	console_image
	compiles, but bitbake u-boot is needed to complete the build

sam9g20dfc:	console_image
	compiles, but bitbake u-boot is needed to complete the build


....

> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


-- 
Best Regards
Ulf Samuelsson

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Koen Kooi]

On 13-08-09 00:09, Ulf Samuelsson wrote:
> Phil Blundell skrev:
>> On Wed, 2009-08-12 at 14:33 +0200, Marcin Juszkiewicz wrote:
>>> Dnia wtorek, 11 sierpnia 2009 o 20:55:00 Ulf Samuelsson napisał(a):
>>>> I introduced the possibility to build linux using
>>>> make<board>_defconfig, instead of using a
>>>> defconfig in a board directory under linux.
>>>> LINUX26_DEFCONFIG needs to be defined.
>>> Interesting, will check. I see a problem anyway because linux_*.bb
>>> recipes by default use defconfig as part of SRC_URI. But we can use
>>> empty file to satisfy it.
>>
>> We've tried this kind of thing before on various platforms and it
>> generally seems to be a losing proposition.  Even if your kernel sources
>> are targetting just a single MACHINE, the kernel isn't quite modular
>> enough yet that you can truly have a "one size fits all" configuration
>> to suit all DISTROs.
>>
>> Also, if you are relying on the defconfig from upstream, any
>> configuration change at all requires that you either patch it, or
>> re-issue the upstream tarball.  Neither of those are as convenient as
>> just editing the defconfig locally in OE.
>>
>> So, in general, I think you're probably better off sticking with the
>> "defconfig in FILESDIR" paradigm.  That's not to say I'm completely
>> opposed to adding the option to use the one from upstream, but I think
>> you would need to be a bit careful about where you use it.
>>
>> p.
>
> Initially, this is to allow easy test of a new board where a config
> exists in the kernel.

You're saying that a 'cp /path/to/source/linux/arch/arm/configs/foo 
/OE/org.oe.dev/recipes/linux/linux/foo/defconfig' is too hard?

regards,

Koen

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Status update

[Ulf Samuelsson]

Ulf Samuelsson skrev:


Have managed to build a number of things now using my private branch.

1) opie-image
2) x11-image
3) x11-gpe-image
4) console-image


dfc = boot from dataflashcard
df = boot from dataflash

Kernel builds for:
at91sam9263dfc
at91sam9261df
at91sam9260dfc
at91sam9g20dfc
at91sam9g45ek (boots from NAND flash)

u-boot and at91bootstrap also builds.

I added some audio stuff to the build,
resulting in a JFFS2 file systems size
for x11-gpe-image of > 60 MB.

This is unfortunate, since the size of the partition, where it is
supposed to fit is 60 MB.

The x11-image and x11-gpe-image was too big,
but opie-image is about 55 MB, so I loaded
this using SAM-BA.

----
I loaded a file system built for the SAM9261df
on a SAM9263EK using the correct kernel and boots.

1) No sound card found. "/dev/dsp"
   Have to look at kernel config.

2) I included mpd in the build, but this seems
   to lack a number of directories which are not installed

   "/var/lib/mpd" does not exist
   "/var/lib/mpd/mpd.log" cannot be opened
   "/media/content" does not exist
   "/var/lib/mpd/playlists" does not exist
   "var/lib/mpd/mpd.db does" not exist

3) Could not set time zone to Berlin, because some package was missing.

4) Using Opie on a VGA screen is not so nice,
   since characters are fuzzy.

5) ODevice() - Found Hardware : ATMEL AT91SAM9263EK
   ODevice() - unknown hardware - using default

   I guess, this could be because I use an AT91SAM9261EK

6) Psychedelic colours
   The AT91SAM9263 and earlier devices uses a BGR (Blue-Green-Red)
   orientation, while most S/W expect RGB (Red-Green-Blue).
   This can be fixed by swapping the connection from the chip
   to the display, otherwise, it will require fixing the S/W.

   Don't know if Opie does this, if the right H/W is detected.

   If QT 4.3.x or later is configured with "-depth generic"
   Then you need to export "QWS_DISPLAY=Linuxfb:genericcolors"
   but when I did this, the screen went black :-(

   When I removed this, and restarted,I again got a nice screen
   Pink and Yellow!!!
   Got to find those adapters, I have somewhere...

   The SAM9G45 should not have this problem.



Tried building beagleboard-demo-image failed:
ERROR: Task 4419
(/home/ulf/projects/OE_atmel/openembedded/recipes/gnome/libgnomeprint_2.18.5.bb,
do_compile) failed
Entering directory
`/home/ulf/projects/OE_atmel/boards/build-at91sam9261df/tmp/
work/armv5te-angstrom-linux-gnueabi/libgnomeprint-2.18.5-r0/
libgnomeprint-2.18.5/doc/reference'

Reason:  I/O error : Attempt to load network entity
http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd



-- 
Best Regards
Ulf Samuelsson

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Marcin Juszkiewicz]

Dnia środa, 12 sierpnia 2009 o 15:32:50 Ulf Samuelsson napisał(a):
> > I had to add patch to 2.12 to get rid of -fno-dwarf2-cfi-asm parametr
> > passed to GCC. Did not tested with 2.13-rc1 as at91.com is not
> > reachable.
>
> Yes, fixed in 2.13-rc1
> Will send you the source file.

2.13-rc1 gaves me non-booting board:

RomBOOT                                                                                                                                                             
> *** AT91Bootstrap-2.13-rc1                                                                                                                                        
> AT45DB642D detected                                                                                                                                               
> invalidboot                                                                                                                                                       
> AT45DB642D detected                                                                                                                                               
> invalidboot                                                                                                                                                       
> AT45DB642D detected                                                                                                                                               
> invalidboot                                                                                                                                                       

Any ideas? I have same problem when 2.12 is used. 1.14 works still.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Ulf Samuelsson]

Marcin Juszkiewicz skrev:
> Dnia środa, 12 sierpnia 2009 o 15:32:50 Ulf Samuelsson napisał(a):
>>> I had to add patch to 2.12 to get rid of -fno-dwarf2-cfi-asm parametr
>>> passed to GCC. Did not tested with 2.13-rc1 as at91.com is not
>>> reachable.
>> Yes, fixed in 2.13-rc1
>> Will send you the source file.
> 
> 2.13-rc1 gaves me non-booting board:
> 
> RomBOOT                                                                                                                                                             
>> *** AT91Bootstrap-2.13-rc1                                                                                                                                        
>> AT45DB642D detected                                                                                                                                               
>> invalidboot                                                                                                                                                       
>> AT45DB642D detected                                                                                                                                               
>> invalidboot                                                                                                                                                       
>> AT45DB642D detected                                                                                                                                               
>> invalidboot                                                                                                                                                       
> 
> Any ideas? I have same problem when 2.12 is used. 1.14 works still.
> 
> Regards, 

What is the file name of your at9bootstrap?

Where are you loading your u-boot?

Which board are you building?


I test with "at91sam9263dfc" and it works.
NAND boot does not work, but no time to really investigate,

Busy with SAM9G45.
Want to use dataflash there as well, because SAMBA wants
to erase the complete NAND flash, and SAMBA does not
work on my linux machine, so I want to program using U-Boot.

I have updated to -rc3, and will update to -rc4 today.
Key feature in rc4 is to enable the user reset input.
This means that you do not have to unplug the power to reboot.


-- 
Best Regards
Ulf Samuelsson

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Ulf Samuelsson]

Marcin Juszkiewicz skrev:
> Dnia środa, 12 sierpnia 2009 o 15:32:50 Ulf Samuelsson napisał(a):
>>> I had to add patch to 2.12 to get rid of -fno-dwarf2-cfi-asm parametr
>>> passed to GCC. Did not tested with 2.13-rc1 as at91.com is not
>>> reachable.
>> Yes, fixed in 2.13-rc1
>> Will send you the source file.
> 
> 2.13-rc1 gaves me non-booting board:
> 
> RomBOOT                                                                                                                                                             
>> *** AT91Bootstrap-2.13-rc1                                                                                                                                        
>> AT45DB642D detected                                                                                                                                               
>> invalidboot                                                                                                                                                       
>> AT45DB642D detected                                                                                                                                               
>> invalidboot                                                                                                                                                       
>> AT45DB642D detected                                                                                                                                               
>> invalidboot                                                                                                                                                       
> 
> Any ideas? I have same problem when 2.12 is used. 1.14 works still.
> 
This is the code that will block your progress.
Can you provide the first 8 dwords of the image you ae trying to load?
Maybe you have not initialized all the trap vectors
or you are doing something valid, but unexpected.

Are you loading something else than U-Boot?

As you see, you can disable the check in your configuration file.

#if	defined(CONFIG_APP_CHECK)
/*------------------------------------------------------------------------------*/
/* \fn    df_is_boot_valid							*/
/* \brief Check that the first bytes of the buffer are valid ARM vectors	*/
/*------------------------------------------------------------------------------*/
static unsigned int df_is_boot_valid(unsigned char *buffer)
{
	int i = 3;
 	/* Verify if the 28 first bytes of the sram correspond to ARM vectors
	   The sixth ARM vector contain the size of the code */
    	while(i < 28)
    	{
		if (i != 23)
		{
			if ((buffer[i] != 0xEA) && (buffer[i] != 0xE5) )
				return FAILURE;
		}
		i+=4;
    	}
	return SUCCESS;
}
#endif

> Regards, 

Have now checked the source:

The 2.13 is based on the 1.13 sources.
	
The 1,14 source code is not available on the Atmel.
I will point that out.

	Differences between the 1 series and the 2 series are:
	1) Kconfig - You can do make <board>_config from OpenEmbedded
		If you want to modify something it is much harder
	2) Init of EBI1 of SAM9263
	3) Bus Matrix Initialization
	4) User reset enabled -but it does not work on the G45!
	5) Not depending on a c library.
		Can be compiled with any gcc compiler,
		not just somehing with newlib.
	etc.

	The 1 series is provided by Atmel in Rousset,
	and I have done the 2 series.
	


-- 
Best Regards
Ulf Samuelsson

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Marcin Juszkiewicz]

Dnia sobota, 22 sierpnia 2009 o 19:45:51 Ulf Samuelsson napisał(a):
> Marcin Juszkiewicz skrev:

> > Any ideas? I have same problem when 2.12 is used. 1.14 works still.
>
> This is the code that will block your progress.
> Can you provide the first 8 dwords of the image you ae trying to load?

http://marcin.juszkiewicz.com.pl/download/at91/ contains at91bootstrap files 
which I checked on board. I tried with at91sam9263ek files before and today 
with at91sam9263dfc one.

During week I plan to change at91bootstrap recipe to build all variants for 
board (so for MACHINE=at91sam9263ek it will build at91sam9263ek, 
at91sam9263dfc and at91sam9263nf) as ek/dfc/nf are just variants of one board 
which differ only at at91bootstrap (kernel and userspace is the same). When 
this will work all machine configs other then *ek can be dropped.

> Maybe you have not initialized all the trap vectors
> or you are doing something valid, but unexpected.
>
> Are you loading something else than U-Boot?

U-Boot 2009.08-rc built from your recipe.

> Have now checked the source:
>
> The 2.13 is based on the 1.13 sources.
>
> The 1,14 source code is not available on the Atmel.

ftp://www.linux4sam.org/pub/at91bootstrap/AT91Bootstrap1.14.zip


Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Marcin Juszkiewicz]

Dnia sobota, 22 sierpnia 2009 o 09:41:46 Ulf Samuelsson napisał(a):

> What is the file name of your at9bootstrap?

at91sam9263dfc-dataflashcardboot-2.12-r0.bin
at91sam9263dfc-dataflashcardboot-2.13-rc1-r2.bin
at91sam9263dfc-dataflashcardboot-2.13-rc4-r0.bin
at91sam9263ek-dataflashcardboot-2.13-rc1-r2.bin

> Where are you loading your u-boot?

dataflashcard 0x8400

> Which board are you building?

at91sam9263ek and at91sam9263dfc

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.

[Ulf Samuelsson]

Marcin Juszkiewicz skrev:
> Dnia sobota, 22 sierpnia 2009 o 19:45:51 Ulf Samuelsson napisał(a):
>> Marcin Juszkiewicz skrev:
> 
>>> Any ideas? I have same problem when 2.12 is used. 1.14 works still.
>> This is the code that will block your progress.
>> Can you provide the first 8 dwords of the image you ae trying to load?
> 
> http://marcin.juszkiewicz.com.pl/download/at91/ contains at91bootstrap files 
> which I checked on board. I tried with at91sam9263ek files before and today 
> with at91sam9263dfc one.
> 
> During week I plan to change at91bootstrap recipe to build all variants for 
> board (so for MACHINE=at91sam9263ek it will build at91sam9263ek, 
> at91sam9263dfc and at91sam9263nf) as ek/dfc/nf are just variants of one board 
> which differ only at at91bootstrap (kernel and userspace is the same). When 
> this will work all machine configs other then *ek can be dropped.
> 

OK, you can run the  MAKEALL script to build everything
and pick from the binaries, I guess, it is quick to build.
Maybe MAKEALL should be

U-boot needs to be built differently as well.
You need to be able to save the environment in:

Long term we need environment in:
nandflash
dataflash_cs0
dataflash_cs1
flash
eeprom
SD-card (maybe this can use EEPROM)



>> Maybe you have not initialized all the trap vectors
>> or you are doing something valid, but unexpected.
>>
>> Are you loading something else than U-Boot?
> 
> U-Boot 2009.08-rc built from your recipe.
> 
Funny, I dont see that.

>> Have now checked the source:
>>
>> The 2.13 is based on the 1.13 sources.
>>
>> The 1,14 source code is not available on the Atmel.
> 
> ftp://www.linux4sam.org/pub/at91bootstrap/AT91Bootstrap1.14.zip
I noticed later, and in fact I have those patches already in 1.13-rc#.
Its been a long summer.

> 
> 
> Regards, 


-- 
Best Regards
Ulf Samuelsson