* Netboot full image loading AST2400
@ 2018-06-15 13:28 Aaron
2018-06-18 4:08 ` Andrew Jeffery
2018-06-19 2:17 ` Lei YU
0 siblings, 2 replies; 7+ messages in thread
From: Aaron @ 2018-06-15 13:28 UTC (permalink / raw)
To: openbmc
[-- Attachment #1: Type: text/plain, Size: 6751 bytes --]
Hi,
It seems like there would an easy way to do this for development/bringup,
asking instead of hacking on the code for a change.
Im bringing up a system by loading an image via u-boot across the network
into the upper section of ram, then booting from there. It relocates itself
to the reset vector and generally works well.
U-Boot 2016.07 (Jun 15 2018 - 20:42:28 +0900)
DRAM: 240 MiB
WARNING: Caches not enabled
Flash: 32 MiB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: aspeednic#0
Error: aspeednic#0 address not set.
Hit any key to stop autoboot: 0
ast# nv
Unknown command 'nv' - try 'help'
ast# env print
baudrate=115200
bootargs=console=ttyS4,115200n8 root=/dev/ram rw
bootcmd=bootm 20080000
bootdelay=2
ethact=aspeednic#0
spi_dma=yes
stderr=serial
stdin=serial
stdout=serial
verify=yes
Environment size: 204/65531 bytes
ast#
The initial stages are good, but 2nd stage loader assume files on MTD
instead of whats in RAM, thus crashes out / uses stale data. Wasted about
half a day wondering why my changes were having little to no effect.
Is there a best practices on this?
Thanks
Aaron
ast# bootd
FTGMAC100#0: link up, 1000bps full-duplex
Using FTGMAC100#0 device
TFTP from server 192.168.2.136; our IP address is 192.168.2.143
Filename 'image-current'.
Load address: 0x40a00000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
.
.
.
.
#################################################################
#################################################################
#################################################################
#################################################################
#######################################################
2.5 MiB/s
done
Bytes transferred = 33554432 (2000000 hex)
## Loading kernel from FIT Image at 40a80000 ...
Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
Trying 'kernel@1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x40a8012c
Data Size: 2331736 Bytes = 2.2 MiB
Architecture: ARM
OS: Linux
Load Address: 0x40008000
Entry Point: 0x40008000
Hash algo: sha1
Hash value: 6a7b891f8d5fed2d358b2ceb06034496979dcae8
Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 40a80000 ...
Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
Trying 'ramdisk@1' ramdisk subimage
Description: obmc-phosphor-initramfs
Type: RAMDisk Image
Compression: lzma compressed
Data Start: 0x40cbfa80
Data Size: 1874095 Bytes = 1.8 MiB
Architecture: ARM
OS: Linux
Load Address: unavailable
Entry Point: unavailable
Hash algo: sha1
Hash value: 788a33bc41ecf5667b87ee2e264c679ed2a42e51
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 40a80000 ...
Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
Trying 'fdt@aspeed-bmc-quanta-q71l.dtb' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x40cb9690
Data Size: 25390 Bytes = 24.8 KiB
Architecture: ARM
Hash algo: sha1
Hash value: 84ed7efe6232738984546b3ef27397ab251c3396
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x40cb9690
Loading Kernel Image ... OK
Loading Ramdisk to 4e9d1000, end 4eb9a8af ... OK
Loading Device Tree to 4e9c7000, end 4e9d032d ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] random: get_random_bytes called from start_kernel+0x3c/0x3f0
with crng_init=0
[ 0.000000] Linux version
4.13.16-aca92be80c008bceeb6fb62fd1d450b5be5d0a4f (oe-user@oe-host) (gcc
version 7.3.0 (GCC)) #10 Fri Jun 15 20:59:12 JST 2018
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] OF: fdt: Machine model: Quanta Q71L BMC
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 58912
[ 0.000000] Kernel command line: console=ttyS4,115200n8 root=/dev/ram rw
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072
bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Memory: 224832K/237568K available (5120K kernel code, 330K
rwdata, 1276K rodata, 1024K init, 109K bss, 12736K reserved, 0K
cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0x8f800000 - 0xff800000 (1792 MB)
.
.
<snip>
.
.
[ 4.641015] Segment Routing with IPv6
[ 4.643890] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 4.648315] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 4.654435] NET: Registered protocol family 17
[ 4.657830] 8021q: 802.1Q VLAN Support v1.8
[ 4.672023] hctosys: unable to open rtc device (rtc0)
[ 4.682642] Freeing unused kernel memory: 1024K
rofs = mtd4 squashfs rwfs = mtd5 jffs2
mount: mounting /dev/mtdblock4 on run/initramfs/ro failed: Invalid argument
[ 7.296855] jffs2: notice: (453) jffs2_build_xattr_subsystem: complete
building xattr subsystem, 53 of xdatum (40 unchecked, 13 orphan) and 189 of
xref (8 dead, 47 orphan) foun.
[ 7.336463] overlayfs: upper fs does not support tmpfile.
chroot: can't execute '/bin/sh': No such file or directory
Unable to confirm /sbin/init is an executable non-empty file
in merged file system mounted at /root.
Change Root test failed! Invoking emergency shell.
Enter password to try to manually fix.
After fixing run exit to continue this script, or reboot -f to retry, or
touch /takeover and exit to become PID 1 allowing editing of this script.
Give root password for maintenance
(or press Control-D to continue):
... and tries to load from MTD which has been purposely erased, and thus
complains.
[-- Attachment #2: Type: text/html, Size: 9944 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Netboot full image loading AST2400
2018-06-15 13:28 Netboot full image loading AST2400 Aaron
@ 2018-06-18 4:08 ` Andrew Jeffery
2018-06-18 4:43 ` Aaron
2018-06-19 2:17 ` Lei YU
1 sibling, 1 reply; 7+ messages in thread
From: Andrew Jeffery @ 2018-06-18 4:08 UTC (permalink / raw)
To: Aaron, openbmc
Hi Aaron,
On Fri, 15 Jun 2018, at 22:58, Aaron wrote:
> Hi,
>
> It seems like there would an easy way to do this for development/bringup,
> asking instead of hacking on the code for a change.
>
> Im bringing up a system by loading an image via u-boot across the network
> into the upper section of ram, then booting from there. It relocates itself
> to the reset vector and generally works well.
>
> U-Boot 2016.07 (Jun 15 2018 - 20:42:28 +0900)
>
> DRAM: 240 MiB
> WARNING: Caches not enabled
> Flash: 32 MiB
> *** Warning - bad CRC, using default environment
>
> In: serial
> Out: serial
> Err: serial
> Net: aspeednic#0
> Error: aspeednic#0 address not set.
>
> Hit any key to stop autoboot: 0
> ast# nv
> Unknown command 'nv' - try 'help'
> ast# env print
> baudrate=115200
> bootargs=console=ttyS4,115200n8 root=/dev/ram rw
> bootcmd=bootm 20080000
> bootdelay=2
> ethact=aspeednic#0
> spi_dma=yes
> stderr=serial
> stdin=serial
> stdout=serial
> verify=yes
>
> Environment size: 204/65531 bytes
> ast#
>
>
> The initial stages are good, but 2nd stage loader assume files on MTD
> instead of whats in RAM, thus crashes out / uses stale data. Wasted about
> half a day wondering why my changes were having little to no effect.
>
> Is there a best practices on this?
>
> Thanks
> Aaron
>
>
>
> ast# bootd
> FTGMAC100#0: link up, 1000bps full-duplex
> Using FTGMAC100#0 device
> TFTP from server 192.168.2.136; our IP address is 192.168.2.143
> Filename 'image-current'.
> Load address: 0x40a00000
> Loading: #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> .
> .
> .
> .
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #######################################################
> 2.5 MiB/s
> done
> Bytes transferred = 33554432 (2000000 hex)
> ## Loading kernel from FIT Image at 40a80000 ...
> Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
> Trying 'kernel@1' kernel subimage
> Description: Linux kernel
> Type: Kernel Image
> Compression: uncompressed
> Data Start: 0x40a8012c
> Data Size: 2331736 Bytes = 2.2 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x40008000
> Entry Point: 0x40008000
> Hash algo: sha1
> Hash value: 6a7b891f8d5fed2d358b2ceb06034496979dcae8
> Verifying Hash Integrity ... sha1+ OK
> ## Loading ramdisk from FIT Image at 40a80000 ...
> Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
> Trying 'ramdisk@1' ramdisk subimage
> Description: obmc-phosphor-initramfs
> Type: RAMDisk Image
> Compression: lzma compressed
> Data Start: 0x40cbfa80
> Data Size: 1874095 Bytes = 1.8 MiB
> Architecture: ARM
> OS: Linux
> Load Address: unavailable
> Entry Point: unavailable
> Hash algo: sha1
> Hash value: 788a33bc41ecf5667b87ee2e264c679ed2a42e51
> Verifying Hash Integrity ... sha1+ OK
> ## Loading fdt from FIT Image at 40a80000 ...
> Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
> Trying 'fdt@aspeed-bmc-quanta-q71l.dtb' fdt subimage
> Description: Flattened Device Tree blob
> Type: Flat Device Tree
> Compression: uncompressed
> Data Start: 0x40cb9690
> Data Size: 25390 Bytes = 24.8 KiB
> Architecture: ARM
> Hash algo: sha1
> Hash value: 84ed7efe6232738984546b3ef27397ab251c3396
> Verifying Hash Integrity ... sha1+ OK
> Booting using the fdt blob at 0x40cb9690
> Loading Kernel Image ... OK
> Loading Ramdisk to 4e9d1000, end 4eb9a8af ... OK
> Loading Device Tree to 4e9c7000, end 4e9d032d ... OK
>
> Starting kernel ...
>
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] random: get_random_bytes called from start_kernel+0x3c/0x3f0
> with crng_init=0
> [ 0.000000] Linux version
> 4.13.16-aca92be80c008bceeb6fb62fd1d450b5be5d0a4f (oe-user@oe-host) (gcc
> version 7.3.0 (GCC)) #10 Fri Jun 15 20:59:12 JST 2018
> [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> [ 0.000000] CPU: VIVT data cache, VIVT instruction cache
> [ 0.000000] OF: fdt: Machine model: Quanta Q71L BMC
> [ 0.000000] Memory policy: Data cache writeback
> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 58912
> [ 0.000000] Kernel command line: console=ttyS4,115200n8 root=/dev/ram rw
> [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
> [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072
> bytes)
> [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> [ 0.000000] Memory: 224832K/237568K available (5120K kernel code, 330K
> rwdata, 1276K rodata, 1024K init, 109K bss, 12736K reserved, 0K
> cma-reserved)
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> [ 0.000000] vmalloc : 0x8f800000 - 0xff800000 (1792 MB)
> .
> .
> <snip>
> .
> .
>
> [ 4.641015] Segment Routing with IPv6
> [ 4.643890] ip6_tables: (C) 2000-2006 Netfilter Core Team
> [ 4.648315] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> [ 4.654435] NET: Registered protocol family 17
> [ 4.657830] 8021q: 802.1Q VLAN Support v1.8
> [ 4.672023] hctosys: unable to open rtc device (rtc0)
> [ 4.682642] Freeing unused kernel memory: 1024K
> rofs = mtd4 squashfs rwfs = mtd5 jffs2
> mount: mounting /dev/mtdblock4 on run/initramfs/ro failed: Invalid argument
> [ 7.296855] jffs2: notice: (453) jffs2_build_xattr_subsystem: complete
> building xattr subsystem, 53 of xdatum (40 unchecked, 13 orphan) and 189 of
> xref (8 dead, 47 orphan) foun.
> [ 7.336463] overlayfs: upper fs does not support tmpfile.
> chroot: can't execute '/bin/sh': No such file or directory
>
> Unable to confirm /sbin/init is an executable non-empty file
> in merged file system mounted at /root.
>
> Change Root test failed! Invoking emergency shell.
> Enter password to try to manually fix.
> After fixing run exit to continue this script, or reboot -f to retry, or
> touch /takeover and exit to become PID 1 allowing editing of this script.
> Give root password for maintenance
> (or press Control-D to continue):
>
>
> ... and tries to load from MTD which has been purposely erased, and thus
> complains.
Have you tried building a netboot image? I think this commit is relevant:
https://gerrit.openbmc-project.xyz/#/c/1957/
Cheers,
Andrew
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Netboot full image loading AST2400
2018-06-18 4:08 ` Andrew Jeffery
@ 2018-06-18 4:43 ` Aaron
0 siblings, 0 replies; 7+ messages in thread
From: Aaron @ 2018-06-18 4:43 UTC (permalink / raw)
To: Andrew Jeffery; +Cc: openbmc
[-- Attachment #1: Type: text/plain, Size: 7833 bytes --]
Thanks! will give that a try.
Aaron
On 18 June 2018 at 13:08, Andrew Jeffery <andrew@aj.id.au> wrote:
> Hi Aaron,
>
> On Fri, 15 Jun 2018, at 22:58, Aaron wrote:
> > Hi,
> >
> > It seems like there would an easy way to do this for development/bringup,
> > asking instead of hacking on the code for a change.
> >
> > Im bringing up a system by loading an image via u-boot across the network
> > into the upper section of ram, then booting from there. It relocates
> itself
> > to the reset vector and generally works well.
> >
> > U-Boot 2016.07 (Jun 15 2018 - 20:42:28 +0900)
> >
> > DRAM: 240 MiB
> > WARNING: Caches not enabled
> > Flash: 32 MiB
> > *** Warning - bad CRC, using default environment
> >
> > In: serial
> > Out: serial
> > Err: serial
> > Net: aspeednic#0
> > Error: aspeednic#0 address not set.
> >
> > Hit any key to stop autoboot: 0
> > ast# nv
> > Unknown command 'nv' - try 'help'
> > ast# env print
> > baudrate=115200
> > bootargs=console=ttyS4,115200n8 root=/dev/ram rw
> > bootcmd=bootm 20080000
> > bootdelay=2
> > ethact=aspeednic#0
> > spi_dma=yes
> > stderr=serial
> > stdin=serial
> > stdout=serial
> > verify=yes
> >
> > Environment size: 204/65531 bytes
> > ast#
> >
> >
> > The initial stages are good, but 2nd stage loader assume files on MTD
> > instead of whats in RAM, thus crashes out / uses stale data. Wasted about
> > half a day wondering why my changes were having little to no effect.
> >
> > Is there a best practices on this?
> >
> > Thanks
> > Aaron
> >
> >
> >
> > ast# bootd
> > FTGMAC100#0: link up, 1000bps full-duplex
> > Using FTGMAC100#0 device
> > TFTP from server 192.168.2.136; our IP address is 192.168.2.143
> > Filename 'image-current'.
> > Load address: 0x40a00000
> > Loading: ############################################################
> #####
> > ############################################################
> #####
> > ############################################################
> #####
> > ############################################################
> #####
> > ############################################################
> #####
> > ############################################################
> #####
> > ############################################################
> #####
> > .
> > .
> > .
> > .
> > ############################################################
> #####
> > ############################################################
> #####
> > ############################################################
> #####
> > ############################################################
> #####
> > #######################################################
> > 2.5 MiB/s
> > done
> > Bytes transferred = 33554432 (2000000 hex)
> > ## Loading kernel from FIT Image at 40a80000 ...
> > Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
> > Trying 'kernel@1' kernel subimage
> > Description: Linux kernel
> > Type: Kernel Image
> > Compression: uncompressed
> > Data Start: 0x40a8012c
> > Data Size: 2331736 Bytes = 2.2 MiB
> > Architecture: ARM
> > OS: Linux
> > Load Address: 0x40008000
> > Entry Point: 0x40008000
> > Hash algo: sha1
> > Hash value: 6a7b891f8d5fed2d358b2ceb06034496979dcae8
> > Verifying Hash Integrity ... sha1+ OK
> > ## Loading ramdisk from FIT Image at 40a80000 ...
> > Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
> > Trying 'ramdisk@1' ramdisk subimage
> > Description: obmc-phosphor-initramfs
> > Type: RAMDisk Image
> > Compression: lzma compressed
> > Data Start: 0x40cbfa80
> > Data Size: 1874095 Bytes = 1.8 MiB
> > Architecture: ARM
> > OS: Linux
> > Load Address: unavailable
> > Entry Point: unavailable
> > Hash algo: sha1
> > Hash value: 788a33bc41ecf5667b87ee2e264c679ed2a42e51
> > Verifying Hash Integrity ... sha1+ OK
> > ## Loading fdt from FIT Image at 40a80000 ...
> > Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
> > Trying 'fdt@aspeed-bmc-quanta-q71l.dtb' fdt subimage
> > Description: Flattened Device Tree blob
> > Type: Flat Device Tree
> > Compression: uncompressed
> > Data Start: 0x40cb9690
> > Data Size: 25390 Bytes = 24.8 KiB
> > Architecture: ARM
> > Hash algo: sha1
> > Hash value: 84ed7efe6232738984546b3ef27397ab251c3396
> > Verifying Hash Integrity ... sha1+ OK
> > Booting using the fdt blob at 0x40cb9690
> > Loading Kernel Image ... OK
> > Loading Ramdisk to 4e9d1000, end 4eb9a8af ... OK
> > Loading Device Tree to 4e9c7000, end 4e9d032d ... OK
> >
> > Starting kernel ...
> >
> >
> > [ 0.000000] Booting Linux on physical CPU 0x0
> > [ 0.000000] random: get_random_bytes called from
> start_kernel+0x3c/0x3f0
> > with crng_init=0
> > [ 0.000000] Linux version
> > 4.13.16-aca92be80c008bceeb6fb62fd1d450b5be5d0a4f (oe-user@oe-host) (gcc
> > version 7.3.0 (GCC)) #10 Fri Jun 15 20:59:12 JST 2018
> > [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ),
> cr=0005317f
> > [ 0.000000] CPU: VIVT data cache, VIVT instruction cache
> > [ 0.000000] OF: fdt: Machine model: Quanta Q71L BMC
> > [ 0.000000] Memory policy: Data cache writeback
> > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> > Total pages: 58912
> > [ 0.000000] Kernel command line: console=ttyS4,115200n8 root=/dev/ram
> rw
> > [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
> > [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072
> > bytes)
> > [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536
> bytes)
> > [ 0.000000] Memory: 224832K/237568K available (5120K kernel code, 330K
> > rwdata, 1276K rodata, 1024K init, 109K bss, 12736K reserved, 0K
> > cma-reserved)
> > [ 0.000000] Virtual kernel memory layout:
> > [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> > [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> > [ 0.000000] vmalloc : 0x8f800000 - 0xff800000 (1792 MB)
> > .
> > .
> > <snip>
> > .
> > .
> >
> > [ 4.641015] Segment Routing with IPv6
> > [ 4.643890] ip6_tables: (C) 2000-2006 Netfilter Core Team
> > [ 4.648315] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> > [ 4.654435] NET: Registered protocol family 17
> > [ 4.657830] 8021q: 802.1Q VLAN Support v1.8
> > [ 4.672023] hctosys: unable to open rtc device (rtc0)
> > [ 4.682642] Freeing unused kernel memory: 1024K
> > rofs = mtd4 squashfs rwfs = mtd5 jffs2
> > mount: mounting /dev/mtdblock4 on run/initramfs/ro failed: Invalid
> argument
> > [ 7.296855] jffs2: notice: (453) jffs2_build_xattr_subsystem: complete
> > building xattr subsystem, 53 of xdatum (40 unchecked, 13 orphan) and 189
> of
> > xref (8 dead, 47 orphan) foun.
> > [ 7.336463] overlayfs: upper fs does not support tmpfile.
> > chroot: can't execute '/bin/sh': No such file or directory
> >
> > Unable to confirm /sbin/init is an executable non-empty file
> > in merged file system mounted at /root.
> >
> > Change Root test failed! Invoking emergency shell.
> > Enter password to try to manually fix.
> > After fixing run exit to continue this script, or reboot -f to retry, or
> > touch /takeover and exit to become PID 1 allowing editing of this script.
> > Give root password for maintenance
> > (or press Control-D to continue):
> >
> >
> > ... and tries to load from MTD which has been purposely erased, and thus
> > complains.
>
> Have you tried building a netboot image? I think this commit is relevant:
>
> https://gerrit.openbmc-project.xyz/#/c/1957/
>
> Cheers,
>
> Andrew
>
[-- Attachment #2: Type: text/html, Size: 9959 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Netboot full image loading AST2400
2018-06-15 13:28 Netboot full image loading AST2400 Aaron
2018-06-18 4:08 ` Andrew Jeffery
@ 2018-06-19 2:17 ` Lei YU
2018-06-19 18:44 ` Aaron
1 sibling, 1 reply; 7+ messages in thread
From: Lei YU @ 2018-06-19 2:17 UTC (permalink / raw)
To: aaron_ppus; +Cc: OpenBMC Maillist
> It seems like there would an easy way to do this for development/bringup, asking instead of hacking on the code for a change.
>
> Im bringing up a system by loading an image via u-boot across the network into the upper section of ram, then booting from there. It relocates itself to the reset vector and generally works well.
You could refer to
https://lists.ozlabs.org/pipermail/openbmc/2017-December/010264.html
for TFTP kernel + NFS rootfs boot.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Netboot full image loading AST2400
2018-06-19 2:17 ` Lei YU
@ 2018-06-19 18:44 ` Aaron
2018-07-05 8:34 ` Aaron
0 siblings, 1 reply; 7+ messages in thread
From: Aaron @ 2018-06-19 18:44 UTC (permalink / raw)
To: Lei YU; +Cc: OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
Nice thanks. Kind of curious why alot of the AST2400 BMC images limit RAM
to 210MB or so. Perhaps its so you can load the full image in the reserved
ram?
On 19 June 2018 at 11:17, Lei YU <mine260309@gmail.com> wrote:
> > It seems like there would an easy way to do this for
> development/bringup, asking instead of hacking on the code for a change.
> >
> > Im bringing up a system by loading an image via u-boot across the
> network into the upper section of ram, then booting from there. It
> relocates itself to the reset vector and generally works well.
>
> You could refer to
> https://lists.ozlabs.org/pipermail/openbmc/2017-December/010264.html
> for TFTP kernel + NFS rootfs boot.
>
[-- Attachment #2: Type: text/html, Size: 1082 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Netboot full image loading AST2400
2018-06-19 18:44 ` Aaron
@ 2018-07-05 8:34 ` Aaron
2018-07-10 22:12 ` Benjamin Fair
0 siblings, 1 reply; 7+ messages in thread
From: Aaron @ 2018-07-05 8:34 UTC (permalink / raw)
To: Lei YU; +Cc: OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]
After some hacking on obmc-init it turns out theres an even easier way to
do this via kernel boot commands.
Just need
1) set "openbmc-init-download-files" as kernel boot arg
2) create new env var to tftp over the ro image
env set openbmcinitdownloadurl tftp://192.168.2.136/image-rofs
3) copy from the deploy/images directory the image-rofs file to tftp root.
ast# env print
1c800b5b=0
baudrate=115200
bootargs=console=ttyS4,115200n8 root=/dev/ram rw openbmc-init-download-files
bootcmd=tftpboot 40a00000 image-current;bootm 40a80000;
bootdelay=2
ethact=FTGMAC100#0
ethaddr=00:24:EC:F0:55:6B
ipaddr=192.168.2.143
openbmcinitdownloadurl=tftp://192.168.2.136/image-rofs
serverip=192.168.2.136
spi_dma=yes
stderr=serial
stdin=serial
stdout=serial
verify=yes
Environment size: 411/65531 bytes
ast#
What I cant work out is how to get the eth0 IP set before init runs, so
hacked it into obmc-init for now.
Aaron
On 20 June 2018 at 03:44, Aaron <aaron_ppus@fmad.com> wrote:
> Nice thanks. Kind of curious why alot of the AST2400 BMC images limit RAM
> to 210MB or so. Perhaps its so you can load the full image in the reserved
> ram?
>
> On 19 June 2018 at 11:17, Lei YU <mine260309@gmail.com> wrote:
>
>> > It seems like there would an easy way to do this for
>> development/bringup, asking instead of hacking on the code for a change.
>> >
>> > Im bringing up a system by loading an image via u-boot across the
>> network into the upper section of ram, then booting from there. It
>> relocates itself to the reset vector and generally works well.
>>
>> You could refer to
>> https://lists.ozlabs.org/pipermail/openbmc/2017-December/010264.html
>> for TFTP kernel + NFS rootfs boot.
>>
>
>
[-- Attachment #2: Type: text/html, Size: 3253 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Netboot full image loading AST2400
2018-07-05 8:34 ` Aaron
@ 2018-07-10 22:12 ` Benjamin Fair
0 siblings, 0 replies; 7+ messages in thread
From: Benjamin Fair @ 2018-07-10 22:12 UTC (permalink / raw)
To: aaron_ppus; +Cc: mine260309, openbmc
On Thu, Jul 5, 2018 at 2:02 AM Aaron <aaron_ppus@fmad.com> wrote:
>
> What I cant work out is how to get the eth0 IP set before init runs, so hacked it into obmc-init for now.
>
> Aaron
>
You can try setting the ip=<address> kernel commandline option.
The full usage is documented here:
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-07-10 22:13 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-15 13:28 Netboot full image loading AST2400 Aaron
2018-06-18 4:08 ` Andrew Jeffery
2018-06-18 4:43 ` Aaron
2018-06-19 2:17 ` Lei YU
2018-06-19 18:44 ` Aaron
2018-07-05 8:34 ` Aaron
2018-07-10 22:12 ` Benjamin Fair
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).