Karsten Merker (2015-02-02):
> On Fri, Jan 02, 2015 at 04:40:38PM +0100, Cyril Brulebois wrote:
> > ISTR having proposed a patch to #700026 / #696418, but that wasn't
> > commented upon.
>
> Hello,
>
> I have tried your patch from
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700026#26,
>
Karsten Merker (2015-03-09):
> On Sun, Mar 08, 2015 at 04:07:35PM +0100, Cyril Brulebois wrote:
> > Ian Campbell (2015-01-07):
> > > On Fri, 2015-01-02 at 16:40 +0100, Cyril Brulebois wrote:
> > > > Karsten Merker (2015-01-02):
> > > > > > (Do your patches end up adding the correct Built-Using o
Ian Campbell (2015-01-07):
> On Fri, 2015-01-02 at 16:40 +0100, Cyril Brulebois wrote:
> > Karsten Merker (2015-01-02):
> > > > (Do your patches end up adding the correct Built-Using on u-boot?)
> > >
> > > No, they don't, but d-i does not do that for similar components
> > > on other platforms
On Wed, 2015-01-07 at 10:41 -0800, Vagrant Cascadian wrote:
> On 2015-01-07, Ian Campbell wrote:
> > And therefore aren't they more usefully built along with
> > that iso? Otherwise how do you know how big to make the partition to
> > contain the iso at d-i build time given the varied sizes of .iso
On 2015-01-05, Cyril Brulebois wrote:
> Karsten Merker (2015-01-02):
>> Ok, I'll change the wording for V4. My intention was to provide a
>> generic README that works regardless of which compression options
>> one chooses in the makefile, so that switching from .gz to .xz
>> would be simple withou
On Fri, 2015-01-02 at 16:40 +0100, Cyril Brulebois wrote:
> Karsten Merker (2015-01-02):
> > > (Do your patches end up adding the correct Built-Using on u-boot?)
> >
> > No, they don't, but d-i does not do that for similar components
> > on other platforms (syslinux/isolinux/grub) as well. Probab
On 2015-01-07, Ian Campbell wrote:
> On Fri, 2015-01-02 at 08:59 -0800, Vagrant Cascadian wrote:
>> On 2015-01-02, Ian Campbell wrote:
>> > On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote:
>> >> On 2014-12-30, Ian Campbell wrote:
> But I still have a question about the hd-media sd-card
On Fri, 2015-01-02 at 22:13 +0100, Karsten Merker wrote:
> On Fri, Jan 02, 2015 at 02:51:18PM +0100, Karsten Merker wrote:
> > On Fri, Jan 02, 2015 at 10:46:37AM +, Ian Campbell wrote:
>
> > > BTW our kernel now supports the /chosen/stdout-path property in fdt and
> > > will automatically put
On Fri, 2015-01-02 at 14:51 +0100, Karsten Merker wrote:
> On Fri, Jan 02, 2015 at 10:46:37AM +, Ian Campbell wrote:
> > On Wed, 2014-12-31 at 01:59 +0100, Karsten Merker wrote:
>
> > Talking about other compression schemes or providing multiple versions
> > of the same file will just confuse
On Fri, 2015-01-02 at 08:59 -0800, Vagrant Cascadian wrote:
> On 2015-01-02, Ian Campbell wrote:
> > On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote:
> >> On 2014-12-30, Ian Campbell wrote:
>
> >> I think the difference is one is a set of netboot images, and the other
> >> is a set of
Hi folks,
Karsten Merker (2015-01-02):
> Ok, I'll change the wording for V4. My intention was to provide a
> generic README that works regardless of which compression options
> one chooses in the makefile, so that switching from .gz to .xz
> would be simple without having to think of updating doc
On 2015-01-02, Ian Campbell wrote:
> On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote:
>> On 2014-12-30, Ian Campbell wrote:
>> I think the difference is one is a set of netboot images, and the other
>> is a set of hd-media images.
>
> But what is the difference between these two things
Karsten Merker (2015-01-02):
> > (Do your patches end up adding the correct Built-Using on u-boot?)
>
> No, they don't, but d-i does not do that for similar components
> on other platforms (syslinux/isolinux/grub) as well. Probably we
> should do that, but then it would have to be done for all
>
On Wed, 2014-12-31 at 01:59 +0100, Karsten Merker wrote:
> > 0001-Add-boot-arm-u-boot-image-config.patch
> >
> > Seems fine.
> >
> > 0002-Provide-u-boot-binaries-for-armhf-systems-without-u-.patch
>
> > I think this isn't actually publishing the u-boot binaries, but
> > r
On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote:
> On 2014-12-30, Ian Campbell wrote:
>
> > 0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch
> ...
> > It seems to be creating a copy of dtbs again, please lets try
> > and keep it to one set of these files
On 2014-12-30, Ian Campbell wrote:
> I should start by saying that I'm not personally particularly interested
> in this functionality, but I don't want to be a blocker for people who
> are so since I've been asked I'll give my 2pence...
Thanks for taking the time.
> I've been wondering if this i
On Sat, 2014-12-27 at 00:00 +0100, Karsten Merker wrote:
> attached is V2 of the patchset. Changes since V1:
I should start by saying that I'm not personally particularly interested
in this functionality, but I don't want to be a blocker for people who
are so since I've been asked I'll give my 2pe
Hi,
(re-looping debian-boot@.)
Karsten Merker (2014-12-30):
> KiBi is planning to release d-i beta 3 soon
> and I would really like to see the patches included there as they
> make running d-i on armhf systems a lot easier for end users and
> thereby hopefully will enable more installation-repor
On 2014-12-26, Karsten Merker wrote:
> On Tue, Dec 23, 2014 at 02:17:16PM -0800, Vagrant Cascadian wrote:
>> On 2014-12-23, Karsten Merker wrote:
>> I don't think it's possible yet to have the device-independent parts
>> working with *all* platforms (at least for Jessie), but we can get close
>> wi
Added debian-cd@.
Karsten Merker (2014-12-23):
> On Thu, Dec 18, 2014 at 07:28:45PM +0100, Karsten Merker wrote:
> > On Wed, Dec 03, 2014 at 03:10:37PM -0800, Vagrant Cascadian wrote:
> > > On 2014-12-03, Karsten Merker wrote:
> > > > several armhf systems do not have u-boot (or another firmware)
On 2014-12-23, Karsten Merker wrote:
> Attached is a set of patches to implement building bootable
> d-i images for armhf systems. It offers various options:
>
> - provide binary "u-boot-only" images for people who want to
> manually install u-boot and e.g. run the rest of the setup via
> tftp
On Thu, 2014-12-18 at 20:44 +0100, Karsten Merker wrote:
> On Thu, Dec 18, 2014 at 10:48:07AM -0800, Vagrant Cascadian wrote:
>
> > I don't know how realistic it is to provide concatenateable images with
> > the u-boot "bare" image as one file, and the kernel + initrd + dtb +
> > boot.scr as a sec
On 2014-12-18, Karsten Merker wrote:
> just to avoid double work: I have recently started working on implementing
> image building support (both for "bare" u-boot images as well as for "full"
> images with u-boot + kernel + initrd) and I hope to find some time over
> Christmas to finish a working p
> "Lennart" == Lennart Sorensen writes:
Hi,
>> So all:
>>
>> omap4
>> omap5
>> am335x
>> am43xx
>> am57x
> Does it work to have a partition table and to have the u-boot code raw
> at 128KiB? I was under the impression that didn't work, but did not
> try it. I should give it a tr
On Mon, Dec 08, 2014 at 04:07:58PM -0600, Robert Nelson wrote:
> u-boot.img? No, we need u-boot SPL (MLO) to setup the memory to load
> the final u-boot.img binary. (or just enable u-boot's falcon mode,
> but that's less generic as everything is setup in the MLO binary by
> default)
Well yes the
> Does it work to have a partition table and to have the u-boot code raw
> at 128KiB? I was under the impression that didn't work, but did not
> try it. I should give it a try sometime.
u-boot.img? No, we need u-boot SPL (MLO) to setup the memory to load
the final u-boot.img binary. (or just en
On Mon, Dec 08, 2014 at 12:27:29PM -0600, Robert Nelson wrote:
> Well from:
> http://www.ti.com/lit/pdf/swpu249
>
> SWPU249AB OMAP543x Technical Reference Manual
>
> (non public, so you have to register with ti, etc..)
>
> Page 5959:
>
>
> 28.3.7.6.4 Read Sector Procedure
> The contents of an
On Mon, Dec 8, 2014 at 11:30 AM, Lennart Sorensen
wrote:
> On Sat, Dec 06, 2014 at 01:07:35PM -0600, Robert Nelson wrote:
>> omap bootrom's with the introduction of the omap4 can be dd'ed liked
>> sunxi/i.mx5/5..
>>
>> dd if=MLO of=/dev/sdX count=1 seek=1 conv=notrunc bs=128k
>> dd if=u-boot.img o
On Sat, Dec 06, 2014 at 01:07:35PM -0600, Robert Nelson wrote:
> omap bootrom's with the introduction of the omap4 can be dd'ed liked
> sunxi/i.mx5/5..
>
> dd if=MLO of=/dev/sdX count=1 seek=1 conv=notrunc bs=128k
> dd if=u-boot.img of=/dev/sdX count=2 seek=1 conv=notrunc bs=384k
omap5 seems to h
On 2014-12-06, Karsten Merker wrote:
> On Wed, Dec 03, 2014 at 03:10:37PM -0800, Vagrant Cascadian wrote:
>
> [providing u-boot images for armhf platforms that do not have
> u-boot in non-volatile storage]
...
> I guess it would make sense to provide both the "naked" u-boot
> binaries for people w
On Sat, Dec 6, 2014 at 1:07 PM, Robert Nelson wrote:
> On Sat, Dec 6, 2014 at 12:46 PM, Karsten Merker wrote:
>> On Wed, Dec 03, 2014 at 03:10:37PM -0800, Vagrant Cascadian wrote:
>>
>> [providing u-boot images for armhf platforms that do not have
>> u-boot in non-volatile storage]
>>
>>> Simply
On Sat, Dec 6, 2014 at 12:46 PM, Karsten Merker wrote:
> On Wed, Dec 03, 2014 at 03:10:37PM -0800, Vagrant Cascadian wrote:
>
> [providing u-boot images for armhf platforms that do not have
> u-boot in non-volatile storage]
>
>> Simply extracting the relevent u-boot files doesn't seem like enough
On Wed, Dec 03, 2014 at 03:10:37PM -0800, Vagrant Cascadian wrote:
[providing u-boot images for armhf platforms that do not have
u-boot in non-volatile storage]
> Simply extracting the relevent u-boot files doesn't seem like enough to
> me. They still need to be installed at particular offsets t
On 2014-12-03, Karsten Merker wrote:
> several armhf systems do not have u-boot (or another firmware) in
> non-volatile (i.e. ROM/Flash) memory, but instead store their
> system firmware on a removable medium such as an SD card.
...
> Debian provides appropriate u-boot images for several supported
On Wed, 3 Dec 2014 23:09:17 +0100
Karsten Merker wrote:
> several armhf systems do not have u-boot (or another firmware) in
> non-volatile (i.e. ROM/Flash) memory, but instead store their
> system firmware on a removable medium such as an SD card. In
> many cases the user does not receive a suit
Hello,
several armhf systems do not have u-boot (or another firmware) in
non-volatile (i.e. ROM/Flash) memory, but instead store their
system firmware on a removable medium such as an SD card. In
many cases the user does not receive a suitable firmware medium
when buying the hardware, because the
36 matches
Mail list logo
