Re: Bug#703209: linux: Please Add multiplatform flavour to armhf
Hi,
On Wed, Mar 20, 2013 at 12:17 AM, Paul Wise wrote:
> On Tue, 2013-03-19 at 15:05 +, Ian Campbell wrote:
>
>> I think the question here is what the `uname -r` bit should be.
>> Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR.
>
> Woops, I missed that uname -r includes the flavour bit.
>
>> I think there is an argument for making the multiplatform case be the
>> default "no-flavour flavour" i.e. $FLAVOUR is armhf/arm64 etc. Or
>> maybe that's what you are suggesting having not realised that `uname
>> -r` currently includes the -$FLAVOUR suffix. Hrm, I think we may
>> actually be talking about the same thing ;-)
>
> Right, my suggestion is just to use the architecture for the flavour, as
> is done on the other architectures.
>
Thank you for your comment.
In ARM ((but may be used on other architectures as well) ) all architectures,
flavor with the name of the CPU do is that it is multiplatform?
For example, armv7 flavor is multiplatform support in armhf.
I think this is a very simple rule.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CABMQnVL=uen73eqdld9ts2_5ef5n_6cks2ngmsbfoedptwk...@mail.gmail.com
Re: Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, Mar 19, 2013 at 5:34 PM, Ian Campbell wrote:
> On Tue, 2013-03-19 at 08:44 +0100, Arnaud Patard wrote:
>> I already commented some days ago on debian-arm that currently
>> multiplatform support must wait. It is useless as usb support is
>> _broken_ on multiplatform. Hopefully, Linaro devs seem back to work
>> and looks like we may have a patch merged soon. Until then, doing more
>> is near to a waste of time.
>
> I don't think making a start on a MP flavour is a waste of time at all.
>
> We are talking about packages in trunk (currently == experimental)
> rather than Sid/Wheezy. There's no possibility of us releasing anything
> with 3.8 but in the meantime adding the multiplatform flavour allows us
> to start laying the packaging ground work, finding bugs in the MP stuff
> and generally kicking the tyres etc. It's also an obvious step in the
> right direction. As you say the known issues, like the USB think, will
> be fixed upstream sooner rather than later.
>
> Since we are currently not yet talking about removing existing flavours
> I'm not sure there are any downsides to just doing it.
>
>> And about the patch in this bug, it fails to be really
>> multiplatform. During my tests on 3.8, I could already enable platforms
>> like MVEBU, HIGHBANK, BCM, MXC and you can enable OMAP too with 2-3
>> backports. Once done, it needs to be tested on real platforms as it
>> would probably allow to detect some more bugs. 3.9 may be better.
>
> This patch is a start though and doesn't preclude adding those other
> platforms either straight away or when 3.9 comes around as we like.
> Having the flavour would also enable testing on real platforms so that
> isn't a reason to wait IMHO.
Thank you for following this up.
I want to explain to me what you wrote.
>
>> On the long term, we'll have also to consider if we should keep
>> omap/mx5/vexpress or not. If we remove them, we should make sure that
>> the transition will work nicely.
>
> Ack.
me too.
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CABMQnV+aUqJd5esxD9Tc95k86nd_Udnjn+=odogkcykbl_g...@mail.gmail.com
RE: Can't get a Linux 3.6-rc zImage smaller than 2MB
Sure. Yes, zImage now has 4K. This is how it was laid out originally. #Power up, ^C +No network interfaces found EM-438/EM-7220 ver.AG0 2006-05-23 == Executing boot script in 1.000 seconds - enter ^C to abort ^C RedBoot> ^C RedBoot> fis list Name FLASH addr Mem addrLength Entry point RedBoot 0xF000 0xF000 0x0004 0x zImage0xF004 0x01008000 0x0020 0x01008000 ramdisk.gz0xF024 0x0180 0x0040 0x0180 *wmdata0xF064 0xF064 0x000C 0x01008000 *rammode 0xF070 0x0020 0x0004 0x0020 *naskey0xF074 0xF074 0x0002 0x01008000 *log 0xF076 0xF076 0x0004 0x01008000 *vendor0xF07A 0xF07A 0x0002 0x01008000 RedBoot config0xF07C 0xF07C 0x1000 0x FIS directory 0xF07E 0xF07E 0x0002 0x The ones with a * aren’t needed. Rammode is for loading via tftp but I never had much success with that so I used minicom serial/ymodem. Bit slow but works. #Setup flash. Empties flash completely and loads up Redboot, Redboot config and FIS directory to default locations. RedBoot> fis init –f #load your images zImage=vmlinuz-x, ramdisk.gz=initrd.img-x using serial/ymodem RedBoot> load -r -v -b 0x01008000 -m ymodem zImage RedBoot> fis create -b 0x01008000 -f 0xf004 -r 0x01008000 -l 0x0040 zImage RedBoot> load -v -r -b 0x0180 -m ymodem ramdisk.gz RedBoot> fis create -b 0x0180 -f 0xf044 -r 0x0180 -l 0x0034 ramdisk.gz RedBoot> fis list Name FLASH addr Mem addrLength Entry point RedBoot 0xF000 0xF000 0x0004 0x RedBoot config0xF07C 0xF07C 0x1000 0x FIS directory 0xF07E 0xF07E 0x0002 0x zImage0xF004 0x01008000 0x0040 0x01008000 ramdisk.gz0xF044 0x0180 0x0034 0x0180 #Setup boot script #once only needed RedBoot> fconfig (-l to list) Run script at boot: true Enter script, terminate with empty line >> fis load ramdisk.gz >> fis load zImage >> exec -c "console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa000" -r 0x0180 >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 192.168.1.1 Local IP address: 192.168.1.155 Local IP address mask: 255.255.255.0 Default server IP address: 192.168.1.98 Console baud rate: 115200 DNS server IP address: 192.168.1.1 GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y #Reboot Redboot> reset From: Maciej Soltysiak [mailto:mac...@soltysiak.com] Sent: Wednesday, March 20, 2013 4:34 PM To: Chris Wilkinson Cc: Arnaud Patard; Luke Kenneth Casson Leighton; debian-arm@lists.debian.org Subject: Re: Can't get a Linux 3.6-rc zImage smaller than 2MB On Wed, Mar 20, 2013 at 3:42 PM, Chris Wilkinson wrote: Excellent, This worked for me. File sizes are: Initrd.img/ramdisk.gz – 2425607 Vmlinuz/zImage – 1524976 Great! Glad to have helped! Which fit nicely in the flash. I redid the flash layout to get rid of some of the not needed sections and make more useable space. Can you share more detail on how you changed the flash layout? EM-438/EM-7220 ver.AG0 2006-05-23 == Executing boot script in 1.000 seconds - enter ^C to abort ^C RedBoot> ^C RedBoot> fis list Name FLASH addr Mem addrLength Entry point RedBoot 0xF000 0xF000 0x0004 0x RedBoot config0xF07C 0xF07C 0x1000 0x FIS directory 0xF07E 0xF07E 0x0002 0x zImage0xF004 0x01008000 0x0040 0x01008000 ramdisk.gz0xF044 0x0180 0x0034 0x0180 Do I read correctly you made 4MB available for zImage? That would be enough to hold larger kernels anyway! Chris Maciej -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/01ce25b0$c92d8b00$5b88a100$@net
adventures with my imx53 quickstart board
Recently my imx53 quickstart board (r model) dissapeared off my network. The board usually runs debian wheezy from a hard drive but it also has a freescale supplied copy of ubuntu lucid (with a freescale kernel) on a micro SD card which I occasionally boot to use as a recovery system. Since I'd forgotten the root password for the debian system (I ususually use ssh with key based auth) I booted into the ubuntu system to perform a password reset. While in this system I also discovered networking was working. After resetting the root password I booted back into the debian system and established that the network device claimed to be up but no packets got through and I periodically got the error message "[ 77.211021] FEC ENET: rcv is not +last" (time obviously varied) on the console. I tried updating the kernel to the latest version from wheezy but that didn't change anything. So I then tried the kernel from experimental which wouldn't boot at all. So I restored the old debian wheezy kernel I started with (I had a conviniant backup of the uImage and uInitrd for it that I made before I started messing arround), networking remained broken. I then discovered that the reported link speed in both the debian and ubuntu systems was only 10mbps (should be 100). At this point I decided to power cycle the network switch (a cheap unmanaged switch with no recognisable brand) and ubuntu reconnected at 100mbps. I then rebooted into debian and networking worked again. I then re-upgraded to the lasted wheezy kernel, networking continued to work. So now onto the conclusions from this adventure 1: with the debian wheezy kernel network operation at 10mbps seems to be broken. 2: the debian experimental kernel doesn't want to boot at all 3: cheap network switches work fine most of the time but can do really strange shit from time to time. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514a2031.2060...@p10link.net
Re: Can't get a Linux 3.6-rc zImage smaller than 2MB
On Wed, Mar 20, 2013 at 3:42 PM, Chris Wilkinson wrote: > Excellent, This worked for me. > > ** ** > > File sizes are: > > Initrd.img/ramdisk.gz – 2425607 > > Vmlinuz/zImage – 1524976 > Great! Glad to have helped! Which fit nicely in the flash. I redid the flash layout to get rid of some > of the not needed sections and make more useable space. > Can you share more detail on how you changed the flash layout? > EM-438/EM-7220 ver.AG0 2006-05-23 > > > == Executing boot script in 1.000 seconds - enter ^C to > abort > > ^C > > > RedBoot> > ^C > > > RedBoot> fis > list > > > Name FLASH addr Mem addrLength Entry > point > > RedBoot 0xF000 0xF000 0x0004 0x > > RedBoot config0xF07C 0xF07C 0x1000 0x > > FIS directory 0xF07E 0xF07E 0x0002 0x > > zImage0xF004 0x01008000 0x0040 0x01008000 > > ramdisk.gz0xF044 0x0180 0x0034 0x0180 > Do I read correctly you made 4MB available for zImage? That would be enough to hold larger kernels anyway! Chris > Maciej
RE: Can't get a Linux 3.6-rc zImage smaller than 2MB
Excellent, This worked for me. File sizes are: Initrd.img/ramdisk.gz – 2425607 Vmlinuz/zImage – 1524976 Which fit nicely in the flash. I redid the flash layout to get rid of some of the not needed sections and make more useable space. EM-438/EM-7220 ver.AG0 2006-05-23 == Executing boot script in 1.000 seconds - enter ^C to abort ^C RedBoot> ^C RedBoot> fis list Name FLASH addr Mem addrLength Entry point RedBoot 0xF000 0xF000 0x0004 0x RedBoot config0xF07C 0xF07C 0x1000 0x FIS directory 0xF07E 0xF07E 0x0002 0x zImage0xF004 0x01008000 0x0040 0x01008000 ramdisk.gz0xF044 0x0180 0x0034 0x0180 Chris From: Maciej Soltysiak [mailto:mac...@soltysiak.com] Sent: Monday, March 18, 2013 4:25 PM To: Arnaud Patard; Luke Kenneth Casson Leighton Cc: Chris Wilkinson; debian-arm@lists.debian.org Subject: Re: Can't get a Linux 3.6-rc zImage smaller than 2MB On Mon, Mar 18, 2013 at 6:10 PM, Arnaud Patard wrote: "Chris Wilkinson" writes: > Is it necessary to flash-kernel? Once /boot on HD is populated with > the new kernel, doesn’t it finally boot from that and it doesn’t matter what > version is flashed? redboot is configured to read the kernel from the flash, so yes, you need flash-kernel. I've not tested to load a kernel from disk so I've no idea if you can configure and use redboot to do it (but it's unlikely). I was wondering if it would be possible to use a different portion of the flash memory for the kernel. I mean that redboot MTD has like 7 regions. Anyway, as some people requested, I wanted to share what worked for me, so I redid the same thing but with 3.8.3. Here are the steps: https://soltysiak.com/compiling-linux-kernel-for-ss4000-e-aka-lanner-em-7210-running-debian/ Best regards, Maciej
