Tue Mar 26 08:05:01 EDT 2013
f20 : arm vs PA
Same |Newer |Older |Local | Remote |
Missing |
--
12172 |0 | 570 |1 |
Sorry if this is off-topic, but I have searched in Google and I cannot find an
answer to this issue, or a hint to diagnose it further.
I have compiled a 3.5.6-1 kernel for a MCUZONE (www.mcuzone.com) board with a Fedora 17 armv5tel userspace. This particular board has two physical serial ports,
On 03/26/2013 02:57 PM, Alex Villacís Lasso wrote:
So I am at a loss about why ttyS2 works and ttyS1 does not. As
far as I can tell with strace, both instances receive the username and
the password correctly. What can I do to diagnose this further? Do I
need to modify something else to enable th
El 26/03/13 17:00, Brendan Conoboy escribió:
On 03/26/2013 02:57 PM, Alex Villacís Lasso wrote:
So I am at a loss about why ttyS2 works and ttyS1 does not. As
far as I can tell with strace, both instances receive the username and
the password correctly. What can I do to diagnose this further? D
Through Fedora 18 GA we've had a one-to-one mapping between the SoC and
the kernel rpm. Likewise, we produced a different filesystem image for
each SoC (EG, a highbank image, a panda image, a trimslice image, etc).
Since then the unified kernel in 3.7 and beyond has introduced the
ability to
Hi Brendan,
I may be way of the mark with my suggestions as I am not that familiar
with ARM, but here goes:
On Wed, Mar 27, 2013 at 10:39 AM, Brendan Conoboy wrote:
> The trouble is, there is no unified $ubootAddress available. The pandaboard
> uses 0x80008000, highbank and tegra use 0x800
On 03/26/2013 04:49 PM, Graeme Russ wrote:
4. Relocatable kernel (like x86)
If I understand correctly it already is relocatable. This is simply the
address that uboot is instructed to load the kernel into memory at.
5. Have U-Boot process uImage to adjust for load location (U-Boot
already
Hi Brendan,
On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy wrote:
> On 03/26/2013 04:49 PM, Graeme Russ wrote:
>>
>> 4. Relocatable kernel (like x86)
>
>
> If I understand correctly it already is relocatable. This is simply the
> address that uboot is instructed to load the kernel into memory
On 03/26/2013 05:04 PM, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy wrote:
On 03/26/2013 04:49 PM, Graeme Russ wrote:
4. Relocatable kernel (like x86)
If I understand correctly it already is relocatable. This is simply the
address that uboot is instruc
Hi Brendan,
On Wed, Mar 27, 2013 at 11:20 AM, Brendan Conoboy wrote:
> On 03/26/2013 05:04 PM, Graeme Russ wrote:
>>
>> Hi Brendan,
>>
>> On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy wrote:
>>>
>>> On 03/26/2013 04:49 PM, Graeme Russ wrote:
4. Relocatable kernel (like x86)
>>
On 03/26/2013 05:26 PM, Graeme Russ wrote:
I just realised I got this a bit wrong - mkimage make a U-Boot image
with a header which contains the kernel load address. Not sure what
mkimage does to the Linux kernel binary itself
The kernel binary is left intact. Only a 64 byte header is prefixed
I'm trying to get F18 running on the globalscale mirabox.
It comes preloaded with Debian Squeeze. As a first step I've tried
downloading the generic
rootfs from the
https://fedoraproject.org/wiki/Architectures/ARM/F18/Remixes page; I've
tried both the arm and armhfp versions, and even tried an
Hi Brendan,
On Wed, Mar 27, 2013 at 11:34 AM, Brendan Conoboy wrote:
> On 03/26/2013 05:26 PM, Graeme Russ wrote:
>>
>> I just realised I got this a bit wrong - mkimage make a U-Boot image
>> with a header which contains the kernel load address. Not sure what
>> mkimage does to the Linux kernel b
On 03/26/2013 06:09 PM, Graeme Russ wrote:
I've had a quick glance at the U-Boot source and I think the newer
'FIT' image may be a better path to follow. In common/image.c you will
find fit_image_get_load() and in common/cmd_bootm.c you will find
bootm_start() and bootm_load_os(). Teasing apart t
Hi Brendan,
On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy wrote:
> On 03/26/2013 06:09 PM, Graeme Russ wrote:
>>
>> I've had a quick glance at the U-Boot source and I think the newer
>> 'FIT' image may be a better path to follow. In common/image.c you will
>> find fit_image_get_load() and in
I feel we gain the greatness of unified kernel but we make separate images
that handle the u-boot quirks. We push down the stack so to speak. The only
diff of each image being load addr's.
The exynos5 kernel requires FIT images, so an extra dimension of
complexity. Well, at least for chromebook. A
On Wed, 27 Mar 2013, Graeme Russ wrote:
> Hi Brendan,
>
> On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy wrote:
> > On 03/26/2013 06:09 PM, Graeme Russ wrote:
> >>
> >> I've had a quick glance at the U-Boot source and I think the newer
> >> 'FIT' image may be a better path to follow. In commo
On Tue, 26 Mar 2013, Brendan Conoboy wrote:
> We could create a number of uboot headers. Then after loading the default
> uImage, load a separate uboot header overwriting the first 64 bytes of RAM.
Please don't engage in those senseless games just to work around a
stupid restriction of the uIma
On Wed, 27 Mar 2013, Graeme Russ wrote:
> Hi Brendan,
>
> On Wed, Mar 27, 2013 at 11:20 AM, Brendan Conoboy wrote:
> > On 03/26/2013 05:04 PM, Graeme Russ wrote:
> >>
> >> Hi Brendan,
> >>
> >> On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy wrote:
> >>>
> >>> On 03/26/2013 04:49 PM, Graeme R
Hi Nicolas
On Wed, Mar 27, 2013 at 2:29 PM, Nicolas Pitre wrote:
> On Wed, 27 Mar 2013, Graeme Russ wrote:
>
>> Hi Brendan,
>>
>> On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy wrote:
>> > On 03/26/2013 06:09 PM, Graeme Russ wrote:
>> >>
>> >> I've had a quick glance at the U-Boot source and
On 03/26/2013 08:38 PM, Nicolas Pitre wrote:
If uImage is a problem, just don't use it, period. Problem solved. All
the targets supported by the unified kernel are recent enough to have
bootz support in their U-Boot source. Please use that.
Is bootz supported everywhere we need? I was under
21 matches
Mail list logo
